EKS Latest Version: Support Calendar and Upgrade Readiness

As of 31 October 2026 the latest Kubernetes version on Amazon EKS is 1.37. Versions 1.37, 1.36, 1.35 and 1.34 are in standard support, 1.33, 1.32 and 1.31 are in extended support, and EKS 1.31 reaches the end of extended support on 26 November 2026, after which AWS upgrades the control plane for you. The dates below come from the Amazon EKS documentation and the Kubernetes releases page, both checked on 31 October 2026.

If your team owns the version calendar, this post is the checklist. If nobody does, that is the gap managed Kubernetes services exist to close.

Each version gets 14 months of standard support from its EKS release, then 12 months of extended support: 26 months in total. Extended support costs extra per cluster hour, and the AWS documentation says it is on by default, because the cluster upgrade policy is set to EXTENDED unless you change it. Source: Amazon EKS user guide, Kubernetes version lifecycle.

The upstream project is stricter. It patches only the three newest minor releases, for about a year each, so as of 31 October 2026 that is 1.37, 1.36 and 1.35. Kubernetes 1.34 reached upstream end of life on 27 October 2026. EKS backports applicable security patches to the versions it supports, so 1.34 stays patched on EKS until 2 December 2026 under standard support and 2 December 2027 under extended support. Source: kubernetes.io/releases.

AWS does not let a control plane stay on a version past the end of extended support. Existing clusters are upgraded to a supported version through a gradual rollout. AWS says it cannot give a time frame, and that you will not be notified before the upgrade happens.

Only the control plane moves. Managed node groups and self-managed nodes stay on the previous version, and cluster add-ons need a manual update afterwards. EKS Auto Mode nodes may update automatically. A cluster upgraded this way cannot be rolled back, whereas an in-place upgrade you run yourself can be rolled back within 7 days of completing.

The next dates that matter are 26 November 2026 for 1.31, 23 March 2027 for 1.32 and 29 July 2027 for 1.33. A cluster still on 1.31 has about four weeks.

No. Managed node groups create EC2 instances in your account that are not upgraded when the control plane is. Self-managed nodes and hybrid nodes are the same. Fargate pods pick up the new kubelet version only when you delete and redeploy them.

Kubernetes tolerates the gap up to a point. The version skew policy lets kubelets trail the API server by up to three minor versions, so 1.34 nodes work under a 1.37 control plane. But the project warns that kubelets persistently three minor versions behind must be upgraded before the control plane moves again, and AWS recommends matching versions. The API server also cannot skip minor versions, so a cluster on 1.31 that wants 1.37 needs six sequential upgrades.

Checks to run before any minor upgrade, in order.

1. Read the calendar from the API. aws eks describe-cluster-versions returns each version's status and its end of standard and extended support dates. Check each cluster's upgrade policy so extended support is a decision, not a default.
2. Scan for removed APIs. Check manifests, Helm releases and live objects against the target release. The Kubernetes deprecation guide lists removals per release, for example flowcontrol.apiserver.k8s.io/v1beta3 in 1.32.
3. Check add-ons. VPC CNI, kube-proxy, CoreDNS and your CSI drivers each support a range of Kubernetes versions.
4. Check operators and webhooks. Admission webhooks must handle the new API versions or use matchPolicy: Equivalent. Operators such as Strimzi, the RabbitMQ Cluster Operator and cert-manager publish their own support matrices.
5. Read the PodDisruptionBudgets on stateful workloads. Percentages round up, so maxUnavailable: 50% on three replicas allows two to be down. A readiness probe that only checks an open port lets a drain continue before a broker has rejoined its cluster.
6. Take a backup you have restored before. Velero for cluster state and volumes, plus application-level backups for brokers and databases.
7. Upgrade in order. Control plane first, then add-ons, then node groups one at a time with a pause for recovery. Remember the 7-day rollback window.

A team with platform engineers, a tested restore and stateless workloads can run this calendar itself. Upgrades go wrong on the stateful side: a drain that takes a three-member broker cluster below quorum, a volume that will not reattach, an operator that cannot reconcile after the API changed. Those failures are covered in messaging on Kubernetes: what breaks.

If you want a senior engineer on call while your team runs the upgrade, that is Kubernetes support. If you want the calendar, the upgrades and the pager to be someone else's job, that is managed Kubernetes services, in your account or on AceMQ infrastructure. Dates change, so check the AWS page before you plan: they were correct on 31 October 2026.

Sources: Amazon EKS Kubernetes versions, Kubernetes version skew policy, Kubernetes deprecated API migration guide and Kubernetes PodDisruptionBudget task.