Kubernetes 1.34 stopped taking anything but critical security patches on August 27, 2026. Its upstream end-of-life date lands on October 27, 2026, and that deadline is turning into an expensive problem for any team still running production clusters on it. Dig into the pricing pages at Amazon, Microsoft, and Google and a strange pattern shows up: all three converge on the same number once a cluster falls behind, $0.60 per cluster per hour, or $438 a month. That is not a coincidence born of collusion. It is what happens when three competing clouds independently decide that lagging customers should subsidize the engineering cost of keeping old control planes alive.
The timing matters because Kubernetes 1.34 end of life hits right as Kubernetes 1.37 ships as the new current release, on August 26, 2026, according to the official Kubernetes release calendar. Any cluster still on 1.34 past October 27 is now three minor versions behind, and depending on which cloud it runs on, it is either quietly accruing extended-support fees, waiting on a forced upgrade, or running unsupported and exposed. This piece breaks down what each of the big three managed Kubernetes services actually charges once a cluster ages out, what a fresh cloud-waste report says about how badly enterprises are managing this already, and what it means for anyone budgeting a Kubernetes estate for 2027.
What Kubernetes 1.34 End of Life Actually Means
Kubernetes’ own release page for 1.34 lays out the mechanics plainly: the release entered maintenance mode on August 27, 2026, meaning only critical security fixes are accepted from that point forward, and the end-of-life date for 1.34 is October 27, 2026. After that date, the open-source project stops patching it entirely. No more CVE backports, no more bug fixes, nothing. A cluster running 1.34 in November 2026 is running on a version that the Kubernetes community has walked away from.
That does not mean the cluster stops working. It means every new vulnerability discovered in the API server, kubelet, or controller manager after that date goes unpatched upstream, unless a managed cloud service steps in with its own backport. That is exactly the gap AWS, Azure, and Google Cloud have each built a paid tier around. Kubernetes typically keeps three minor versions in active support at any given time, which is why 1.35, 1.36, and 1.37 are all still receiving fixes while 1.34 ages out. The project ships roughly three minor releases a year, so any team that skips even one upgrade cycle can find itself staring at an EOL deadline within months.
The 2026 Kubernetes Release Timeline, Version by Version
Tracking exactly where each active branch sits matters for planning an upgrade path. Kubernetes.io’s release and patch pages show four minor versions with activity in August 2026 alone: 1.34.11, 1.35.8, and 1.36.4 all shipped patches on August 11, and 1.37.0 became the new current release on August 26. The table below lays out the state of play as of the first week of September.
| Version | Latest Patch (Aug 2026) | Status as of Sept 3, 2026 | End of Life / Support Ends |
|---|---|---|---|
| 1.34 | 1.34.11 (Aug 11, 2026) | Maintenance mode since Aug 27, 2026 | Oct 27, 2026 |
| 1.35 | 1.35.8 (Aug 11, 2026) | Active support | Not yet published |
| 1.36 | 1.36.4 (Aug 11, 2026) | Active support | Jun 28, 2027 |
| 1.37 | 1.37.0 (Aug 26, 2026) | Current release | Oct 28, 2027 |
Note the gap: 1.34 gets roughly eight months less runway than 1.37 will get. That asymmetry is normal for Kubernetes’ rolling support model, but it catches teams off guard every single cycle because the EOL clock starts the moment a version ships, not the moment a team adopts it. A cluster that went live on 1.34 in March 2026 only got about seven months of full upstream support before the maintenance-mode clock started ticking.
Why Cloud Providers Charge Extra for Old Kubernetes Versions
Once upstream support ends, someone still has to backport security fixes for the customers who have not upgraded. That work does not happen for free, and all three major clouds have built a metered fee around it rather than eating the cost or forcing an immediate hard cutover. The pitch from each vendor is similar: pay a premium, keep running the old control plane, and get patched CVEs without touching your workloads. The alternative, an unplanned forced migration, is often more disruptive to a business than a few hundred dollars a month per cluster.
What is notable is how closely the three vendors landed on the same price after building their programs independently and years apart. AWS launched EKS extended support first, with pricing that took effect on its April 2024 billing cycle according to AWS’s own containers blog. Google followed with GKE extended support tied to its Extended release channel. Microsoft folded Azure’s version of the same idea into a Premium AKS tier that bundles Long Term Support. Different packaging, same $0.60-an-hour number.
AWS EKS: The $438-a-Month Extended Support Tier
Amazon’s EKS pricing page spells out a two-tier structure. Every cluster pays $0.10 per cluster per hour during standard Kubernetes version support, which AWS provides for roughly 14 months after a version ships. Once that window closes, the cluster automatically rolls into extended support at $0.60 per cluster per hour, a jump AWS’s own containers blog confirms was effective starting with the April 2024 billing cycle and still applies in 2026. There is no opt-out grace period. The move to the higher tier happens automatically the moment the standard window closes, unless the cluster has already been upgraded to a still-supported version.
Run the math on a single cluster left in extended support for a full year: $0.60 times 24 hours times 365 days comes out to roughly $5,256, on top of whatever the underlying EC2 nodes cost. Scale that across a fleet and the number stops looking like a rounding error. A platform team running 100 clusters that all miss the upgrade window is looking at roughly $525,600 a year in support fees alone, before counting a single dollar of compute, storage, or engineering time spent managing the sprawl.
Azure AKS: Long Term Support Wears a Different Name, Same Price Tag
Microsoft structures the same idea around service tiers instead of a binary standard-versus-extended switch. AKS ships a free tier with no control-plane SLA, a Standard tier priced around $0.10 per cluster per hour, and a Premium tier that bundles Long Term Support. Azure’s own pricing page states that LTS is only available on clusters running the Premium tier, and that LTS-enabled clusters are billed at $438 per cluster per month, which works out to the same $0.60-per-hour rate AWS charges. Microsoft’s documentation on supported Kubernetes versions describes the underlying policy as one year of community-aligned support plus an additional year of Microsoft-backed LTS, giving AKS customers up to two extra years of coverage on a version that upstream Kubernetes has already abandoned, for a price.
The practical difference from EKS is that AKS customers have to opt into Premium/LTS ahead of time rather than getting auto-enrolled after the fact. That is arguably friendlier, since it forces a deliberate cost decision instead of a surprise line item, but it also means teams that do not plan ahead can find themselves without an LTS safety net once their Standard-tier cluster’s Kubernetes version goes end of life.
Google GKE: Extended Channel Support Lands at the Same Number
Google’s version threads together its release-channel system with a metered add-on fee. Every GKE cluster already pays a flat $0.10-per-cluster-per-hour management fee, documented on Google’s official pricing page, regardless of size or topology, after a small monthly credit. Google Cloud’s blog post announcing GKE extended support spells out what happens next: clusters running in the Extended release channel are free to use during a version’s normal support window, but once that version enters its extended support period, Google adds an extra $0.50 per cluster per hour on top of the base fee. Add the two together and a GKE cluster running an end-of-life version in the Extended channel also lands at $0.60 per cluster per hour, the identical figure AWS and Azure charge.
Google frames this as an option rather than an automatic penalty. Standard and Rapid channel clusters get force-upgraded on a schedule instead, so a team that never opts into the Extended channel will not see this specific charge, but it will face mandatory version bumps on Google’s timeline rather than its own. Both mechanisms exist to solve the same underlying business problem: somebody has to pay for old-version support, and Google has decided that somebody is either the customer’s wallet or the customer’s change-management calendar.
Side-by-Side: EKS vs AKS vs GKE Support Economics
| Provider | Standard Support Fee | Extended/LTS Fee | Support Window | Effective Extended Cost |
|---|---|---|---|---|
| AWS EKS | $0.10/cluster/hr | $0.60/cluster/hr (auto-applied) | ~14 months standard + 12 months extended | $438/month |
| Azure AKS | ~$0.10/cluster/hr (Standard tier) | ~$0.60/cluster/hr (Premium tier w/ LTS) | 1 year community + up to 2 years LTS | $438/month |
| Google GKE | $0.10/cluster/hr (flat mgmt fee) | $0.60/cluster/hr ($0.10 base + $0.50 extended) | Standard window, then Extended channel period | $438/month |
The takeaway from that table is not that one cloud is cheaper. It is that all three landed on functionally identical economics despite building their programs on different schedules and with different opt-in mechanics. AWS auto-enrolls a lagging cluster into extended support. Azure requires a Premium-tier decision made in advance. Google splits the difference with a channel choice plus a conditional fee. Whichever door a team walks through, the toll is the same $438 a month per cluster once a version goes end of life and a cloud, not the open-source project, becomes the sole source of security patches.
The Cloud Waste Nobody Is Watching: CAST AI’s 2026 Findings
Version-lag fees are only part of the picture. CAST AI’s 2026 State of Kubernetes Optimization Report, which the company says analyzed tens of thousands of clusters across AWS, Azure, and Google Cloud, found that average CPU utilization across those clusters fell to 8%, down from 10% the year before. Memory utilization dropped from 23% to 20% over the same period. This is the first year CAST AI added GPU utilization to the report, and the number it found was 5% across AI and machine learning workloads, according to the company’s press release.
The over-provisioning side of the same report is arguably more alarming than the utilization numbers alone. CPU over-provisioning jumped from 40% to 69% year over year, and memory over-provisioning sat at 79%, per CAST AI’s own blog post on the findings. Put plainly, most Kubernetes clusters in production today are allocated many times more compute than the workloads running on them actually use, and the gap widened rather than closed in the past year despite years of FinOps tooling investment across the industry. SDxCentral’s coverage of the report summarized the trend bluntly: Kubernetes efficiency is going backwards as AI drives GPU waste, even as GPU capacity has become the single most expensive line item on many cloud bills.
Put version-lag fees next to that waste data and a fuller picture forms. Teams paying $438 a month per cluster in extended-support fees are, in many cases, the same teams running clusters at single-digit CPU utilization. The version-lifecycle problem and the resource-waste problem share a root cause: nobody on the platform team has enough bandwidth, or enough automated tooling, to keep pace with both upgrade cycles and rightsizing at the same time.
Historical Context: How Kubernetes Support Windows Got Here
Kubernetes did not always have this much structure around end of life. In the project’s early years, support windows were looser and managed clouds mostly absorbed the cost of keeping old versions alive as a customer-retention expense rather than a line item. That changed as Kubernetes adoption scaled into the tens of thousands of clusters per major cloud customer, the same order of magnitude CAST AI cites in its 2026 report. At that scale, absorbing indefinite legacy-version support stopped being a rounding error for AWS, Azure, and Google and started being a real infrastructure cost.
AWS was first to formalize a paid extended-support tier, rolling it out ahead of its April 2024 billing cycle per the company’s containers blog. Google and Microsoft followed with their own structurally similar programs over the following two years. By the time Kubernetes 1.34 reached maintenance mode in August 2026, all three clouds had a mature, well-documented paid path for lagging clusters, a sign that version-lifecycle monetization has moved from an experiment to a permanent, expected part of the managed-Kubernetes business model.
Market Impact: What This Means for Multi-Cloud Kubernetes Strategy
For platform teams running Kubernetes across more than one cloud, the convergence on $0.60 an hour removes a variable that used to complicate vendor comparisons. A team can no longer pick a cloud based on the assumption that one vendor is meaningfully cheaper to fall behind on. Enterprise cloud spend research from usage.ai puts AWS, Azure, and GCP together at roughly 68% of global enterprise cloud spending as of Q1 2026, with Azure alone accounting for about 25% of that spend, underlining how much budget now flows through these three providers’ Kubernetes offerings specifically. When the fallback cost structure is identical across the three biggest players, the decision of which cloud to run Kubernetes on shifts back toward compute pricing, network egress, and existing platform investment, not fear of a cheaper EOL penalty on a competing cloud.
It also changes the internal argument platform engineers can make to finance teams. Instead of “cloud X is expensive to fall behind on,” the pitch becomes “falling behind is expensive everywhere, so fund the upgrade automation.” That is a more defensible budget request, and it lines up with why the FinOps and platform-engineering tooling markets built around Kubernetes upgrade automation, including CAST AI itself, Kubecost, and others, have kept growing even as raw compute prices have been relatively flat.
How to Check What Version Your Clusters Are Actually Running
Before budgeting for extended support anywhere, the first step is simply confirming which clusters are exposed. The commands below work against any standards-compliant Kubernetes cluster, whether it runs on EKS, AKS, GKE, or self-managed infrastructure.
# Check the control plane and node versions for the current context
kubectl version --short
# List every node and its kubelet version in one pass
kubectl get nodes -o custom-columns=NAME:.metadata.name,VERSION:.status.nodeInfo.kubeletVersion
# For EKS specifically, list cluster versions across an account/region
aws eks list-clusters --query 'clusters[]' --output text | \
xargs -I{} aws eks describe-cluster --name {} --query 'cluster.[name,version]' --output text
# For AKS, list cluster versions across a subscription
az aks list --query '[].{Name:name, Version:kubernetesVersion}' --output table
# For GKE, list cluster versions across a project
gcloud container clusters list --format='table(name,currentMasterVersion)'Any cluster reporting 1.34.x or older in that output is either already inside a paid extended-support window or will be within weeks. Anything on 1.35 or newer still has upstream community coverage, but on a shrinking clock given Kubernetes’ roughly four-month minor-release cadence.
Predictions: Where Kubernetes Version Economics Go From Here
- The $0.60-an-hour ceiling holds through 2027. With three major vendors independently converged on the same price, none has strong incentive to undercut the others and start a race to the bottom on extended-support margin.
- More clouds will auto-enroll rather than require opt-in. AWS’s automatic rollover into extended support is operationally simpler for the vendor to bill and harder for customers to avoid, which makes it the more profitable pattern for providers to copy.
- Third-party upgrade-automation tooling grows faster than raw Kubernetes spend. Given CAST AI’s own data showing utilization getting worse rather than better, expect continued investment in automated rightsizing and upgrade orchestration products aimed squarely at avoiding both extended-support fees and idle-capacity waste.
- GPU-aware cost tooling becomes a standard feature, not an add-on. With GPU utilization sitting at just 5% per CAST AI’s 2026 findings, expect Kubernetes cost platforms to treat GPU rightsizing as a headline capability rather than an afterthought bolted onto CPU/memory tooling.
- Regulated industries push for longer default support windows. Enterprises in finance and healthcare, which move slowest on infrastructure upgrades, are the most likely constituency to lobby cloud vendors and the Kubernetes project itself for longer standard-support windows before extended fees kick in.
What Teams Should Do Before the Next EOL Deadline
The practical response to all of this is not complicated, even if executing it consistently is hard. Audit cluster versions on a recurring schedule rather than only when a deadline is imminent. Build the Kubernetes minor-version upgrade cadence into the same planning cycle as capacity and cost reviews, since the CAST AI data shows those two problems, stale versions and over-provisioned capacity, tend to show up on the same clusters. And treat the extended-support fee not as a fallback safety net to budget for by default, but as a signal that the upgrade process itself needs to move faster than the roughly four-month gap between Kubernetes minor releases.
Kubernetes 1.34’s October 27 end-of-life date is not a one-time event. Kubernetes 1.35 will hit its own maintenance-mode milestone within months of 1.34’s, and 1.36 not long after that. The clouds have already built the billing infrastructure to monetize whichever version falls behind next. The only variable left for platform teams to control is how many clusters are still sitting on an EOL version when that bill arrives.
Frequently Asked Questions
When does Kubernetes 1.34 reach end of life?
Kubernetes 1.34 entered maintenance mode on August 27, 2026, and its official end-of-life date, when the upstream project stops issuing any patches at all, is October 27, 2026, according to the Kubernetes project’s own release page.
How much does AWS charge for EKS extended support?
AWS charges $0.10 per cluster per hour during standard support and $0.60 per cluster per hour once a cluster automatically rolls into extended support, which works out to roughly $438 per cluster per month, per AWS’s official EKS pricing page.
Does Azure AKS have an extended support fee like EKS?
Yes. Azure bundles the equivalent protection into a Premium AKS tier with Long Term Support, billed at $438 per cluster per month according to Microsoft’s official AKS pricing page, the same effective rate as AWS’s extended-support tier.
Does Google Cloud charge extra for old Kubernetes versions on GKE?
Yes, for clusters on the Extended release channel. Once a version enters its extended support period, Google adds $0.50 per cluster per hour on top of the standard $0.10 per cluster per hour management fee, for a combined $0.60 per hour, according to Google Cloud’s official blog post on GKE extended support.
What happens if I just stay on Kubernetes 1.34 without paying for extended support?
The cluster keeps running, but after October 27, 2026, no new upstream security patches will be backported to it unless the managed cloud service applies its own fixes as part of a paid extended-support tier. Running an unpatched, end-of-life version in production is a growing exposure the longer it continues.
How often does Kubernetes release a new minor version?
Kubernetes has shipped roughly three minor releases a year in recent cycles. The gap between the 1.37.0 release on August 26, 2026, and the prior 1.36 release was about four months, which is consistent with the project’s typical cadence.
What is causing Kubernetes clusters to run so underutilized in 2026?
CAST AI’s 2026 State of Kubernetes Optimization Report found average CPU utilization at just 8% and memory utilization at 20% across the tens of thousands of clusters it analyzed, with CPU over-provisioning jumping from 40% to 69% year over year. The report attributes the trend to teams over-allocating capacity, particularly for AI and GPU workloads, faster than they are rightsizing it.
Is it cheaper to just upgrade instead of paying for extended support?
In almost every case, yes, on a pure dollar basis. A single cluster left in extended support for a year costs roughly $5,256 in fees alone across any of the three major clouds, money that buys no new features or performance, only continued patching of a version the rest of the ecosystem has already moved past.
