Build1 publisherNot yet confirmed elsewhere3 min readPublished
EKS, GKE and AKS each retire Kubernetes 1.34 on a different date with a different penalty
Kubernetes 1.34 loses upstream patches on October 27, but AKS stops patching it on November 30 and EKS starts billing it at six times the rate on December 2. Teams need an upgrade plan for each provider, because the managed dates decide what a 1.34 cluster costs and whether it still gets fixes.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- EKS gives every Kubernetes version 14 months of standard support and 12 of extended support, then upgrades the control plane to the oldest version it still supports.
- EKS 1.31 clusters reach the end of extended support on November 26, 2026, after which their control planes can be upgraded at any time.
- GKE ends standard support for 1.34 on January 25, 2027, and its Extended channel keeps the version until November 25, 2027.
- The September 23 releases, including 1.34.12, fix CVE-2026-2270, which lets a user who can write StatefulSets and ControllerRevisions in one namespace get a Pod created in another.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- cost EKS charges the increase per cluster-hour, so organisations running many small 1.34 clusters pay the most for leaving the upgrade past December 2.
- exposure Self-managed 1.34 clusters on kubeadm, k3s or RKE2 become exposed to every CVE disclosed after October 27 unless their distribution backports a fix.
- decision Disabling EKS extended support for 1.34 avoids the higher rate but lets EKS pick the upgrade date, at the end of standard support.
On a managed cluster, October 27 by itself changes very little, according to a post on dev.to that compiles the providers' dates [1]. The upstream date controls patch releases. Kubernetes 1.34 entered maintenance mode on August 27, and the project ships no 1.34 patch releases after October 27. One more monthly release is targeted for October 13 [6]. After that, coverage depends on the provider. EKS says it backports security patches to every version it still supports, extended support included [14]. AKS platform support explicitly does not apply security patches [5].
For EKS 1.34, December 2 changes the bill. Extended support is enabled by default, so the cluster keeps running and moves from $0.10 to $0.60 per cluster-hour [16]. That is six times the standard rate [22]. Extended support for 1.34 runs 365 days, to December 2, 2027. The extra $0.50 an hour over 8,760 hours comes to $4,380 per cluster [23]. The silent control-plane upgrade in the EKS docs reaches 1.34 only when that extended year ends [2][7].
The first version due for that upgrade is 1.31. EKS documentation says automatic updates "can happen at any time after the end of extended support date," and "You won't receive any notification before the update." [8] Only the control plane moves. Self-managed nodes and managed node groups stay on 1.31, Auto Mode nodes may update on their own, add-ons stay on their pinned versions, and the cluster cannot be rolled back [10]. The version skew policy allows a 1.32 control plane over 1.31 nodes, so the cluster runs. The post's author added, "but it's a state you never tested." [10]
The landing version has its own deadline. 1.32 leaves extended support on March 23, 2027 [15]. A 1.31 cluster moved on the first eligible day has 117 days before that next deadline, and one moved later has fewer [24].
AKS does the least on the day. On November 30, an AKS 1.34 cluster keeps serving traffic and keeps scaling [5]. Its LTS option runs to November 2027 [4]. The post does not give LTS pricing.
GKE upgrades the control plane on its own schedule, and later for clusters on the Extended channel [11]. The author, who wrote that they spent years at Google working with GKE customers [21], gave the provider's side: "An unpatched control plane is a liability for the provider as much as for you, which is why every provider eventually moves it for you." [18]
EKS publishes its dates through the CLI. `aws eks describe-cluster` returns each cluster's version and `upgradePolicy.supportType`. `aws eks describe-cluster-versions` returns `endOfStandardSupportDate` and `endOfExtendedSupportDate` per version [19]. Upgrade insights refresh every 24 hours and check for deprecated APIs [20]. As of September 29, EKS did not yet offer 1.37 [17].
What to watch
- Whether the 1.34 patch release targeted for October 13 ships before the upstream cutoff, since it is the last one the project plans.
- EKS adding Kubernetes 1.37, which it did not offer as of September 29, would change the upgrade targets available to 1.34 clusters.
- Reports of EKS 1.31 control planes being moved after November 26, given the docs allow it at any time and without notification.