Kubernetes 1.34 leaves support and all three clouds charge $438 a month
Moved into maintenance mode on August 27, 2026, Kubernetes 1.34 reaches end of life on October 27, at which point AWS, Azure and Google all bill $0.60 per cluster per hour — $438 a month — to keep patching it. Upgrade before the deadline: the surcharge buys no features, only the survival of an outdated control plane.
August 27, 2026. Kubernetes 1.34 enters maintenance mode: only critical security fixes are accepted from here on. October 27, 2026. That is the official end-of-life date, after which no patches will ship at all. $438. That is the monthly per-cluster figure AWS, Azure and Google Cloud each bill — independently — to keep patching a version the project has walked away from. Why it matters: the price convergence is not a coincidence. It is the market putting a number on the cost of an upgrade delay.
What end of life for 1.34 actually means
The 1.34 release page is blunt: the version entered maintenance mode on August 27, 2026, and its end of life lands on October 27, 2026. After that date, the open-source project stops patching it, full stop. No more CVE backports, no more bug fixes, nothing. A cluster still running 1.34 in November 2026 is running on a version the Kubernetes community has abandoned.
That does not mean the cluster stops working. It means every new vulnerability found in the API server, the kubelet or the 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 turned into a paid offering.
The August 2026 release timeline sets the urgency: 1.34.11, 1.35.8 and 1.36.4 all shipped patches on August 11, and 1.37.0 became the current release on August 26. A cluster still on 1.34 is now three minor versions behind, and its support clock started ticking the day the version shipped — not the day the team adopted it.
Why all three clouds landed on the same price
Open the pricing pages at the three hyperscalers and a strange pattern appears: all three converge on the same number once a cluster falls behind — $0.60 per cluster per hour, or $438 a month. It is not collusion; it is what happens when three competitors independently decide that lagging customers should fund the engineering cost of keeping old control planes alive.
| Provider | Standard 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/mo |
| Azure AKS | ~$0.10/cluster/hr (Standard) | ~$0.60/cluster/hr (Premium + LTS) | 1 year community + up to 2 years LTS | $438/mo |
| Google GKE | $0.10/cluster/hr | +$0.50/cluster/hr (Extended channel) | standard window + extended period | $438/mo |
On AWS, the switch is automatic: every EKS cluster pays $0.10 an hour during the roughly 14-month standard window, then rolls into the $0.60 extended tier with no opt-out. On Azure, the same idea is wrapped in a Premium tier that bundles Long Term Support, available only to clusters that opted in ahead of time. On Google, the Extended channel adds $0.50 an hour on top of the base fee; Standard and Rapid channel clusters dodge the surcharge but face forced upgrades on Google’s schedule rather than their own.
The bill for falling behind
Run the math on a single cluster left in extended support for a full year: $0.60 × 24 hours × 365 days works out to about $5,256, before a single dollar of EC2 compute, storage or engineering time. Extend it to a fleet: a platform team running 100 clusters that all missed the window pays roughly $525,600 a year in support fees alone.
Put that next to what CAST AI’s State of Kubernetes Optimization report found across tens of thousands of clusters: average CPU utilization of 8%, memory utilization of 20%, and CPU over-provisioning climbing from 40% to 69% year over year. In other words, enterprises already pay heavily for CPU they do not use — adding $438 per cluster per month for an outdated control plane is just stacking one waste on top of another.
The conclusion is hard to avoid: on pure dollars, it is almost always cheaper to upgrade. The extended tier buys no features and no performance — only continued patching of a version the rest of the ecosystem has already moved past.
Upgrade instead of paying
The real answer is not to budget for the surcharge, but to make sure you never hit it. Kubernetes ships roughly three minor releases a year and only keeps three in active support at any moment: any team that skips even one upgrade cycle lands a few months from an end-of-life deadline. Automating version tracking is therefore the highest-leverage move.
# Control plane (API server) version of the current context
kubectl get --raw /version
# List each node's kubelet version to spot clusters that are falling behind
kubectl get nodes -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.nodeInfo.kubeletVersion}{"\n"}{end}'Two hard constraints shape any upgrade path. First, the Kubernetes version skew policy: the kubelet may lag the control plane by no more than two minor versions, and the control plane may lead the kubelet by at most one. That rule alone rules out jumping straight from 1.34 to 1.37 — a three-version climb is actually three sequential upgrades, each with its own drain and rollback window. Second, API deprecations are removed on a fixed cadence: the deprecated beta APIs of 1.34 are gone by 1.37, so every hop needs a compatibility pass over the CRDs, operators and mutating webhooks the cluster actually runs before the first node is drained.
The cheap way to stay out of the $438 tier is to make upgrades boring. Treat each minor release as a routine, low-risk change rather than an event: run the compatibility audit in a staging cluster, pin operator versions, and upgrade the control plane ahead of the nodes so the skew policy never becomes the reason a release slips. Teams that automate this rarely think about end-of-life dates at all — they are already a minor or two ahead by the time the clock starts ticking.
The plan before October 27 is straightforward: inventory the clusters still on 1.34, verify CRD, operator and deployment-tool compatibility with the 1.37 target, then step through the upgrades one minor version at a time. A cluster three versions behind is not a frugal asset — it is a debt that eventually bills itself at $0.60 an hour.
Verdict
If your clusters still run 1.34, schedule the climb to 1.35, then 1.36, then 1.37 before October 27, 2026. Every cluster left past the deadline costs $438 a month, on any cloud, and the money buys no progress.
If a timely migration is impossible — an incompatible operator, a regulatory change freeze — opt into the extended tier knowingly: it is a bridge, not a destination. Treat it as a time-boxed transition expense with a firm exit date.
If you run a fleet, build an automated upgrade cadence and track end-of-life dates. The true cost of a version lag does not show up in the cluster; it shows up on the invoice — and all three clouds have already set the price.