EKS 1.31 extended support ends 26 November 2026 and 1.34 standard support ends 2 December - avoid a forced control plane upgrade

#The calendar

From the EKS Kubernetes version table:

What happens at each date:

• End of standard support: clusters with the upgrade policy EXTENDED (the default) move to extended support, which costs more per cluster hour. Clusters with policy STANDARD are auto-upgraded.
• End of extended support: EKS auto-upgrades the control plane only, at an unspecified time after the date and without a further notice. Managed node groups and self-managed nodes stay on the old version. Clusters auto-upgraded this way can't be rolled back.

So a 1.31 cluster still running on 26 November will get a 1.32 control plane at some point, with old nodes and possibly incompatible add-ons.

#1. Find clusters and their status

for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  for c in $(aws eks list-clusters --region "$r" --query clusters --output text); do
    aws eks describe-cluster --region "$r" --name "$c" \
      --query "cluster.[name,version,upgradePolicy.supportType,platformVersion]" --output text |
      sed "s/^/$r\t/"
  done
done

aws eks describe-cluster-versions \
  --query "clusterVersions[].[clusterVersion,status,endOfStandardSupportDate,endOfExtendedSupportDate]" --output table

#2. Check what will break

Each minor upgrade can remove APIs. Before upgrading:

# EKS upgrade insights (deprecated API usage, add-on compatibility, node skew)
aws eks list-insights --cluster-name prod-eu --region eu-west-1 \
  --query "insights[].[name,insightStatus.status]" --output table

Also check:

• Add-ons: VPC CNI, CoreDNS, kube-proxy and the EBS/EFS CSI drivers must have versions compatible with the target. aws eks describe-addon-versions --kubernetes-version 1.32 --addon-name vpc-cni.
• Helm charts and operators (ingress controllers, cert-manager, service mesh, GPU operator) for their supported Kubernetes ranges.
• Node skew: nodes can lag the control plane, but plan to bring them up within the same change window.

#3. Upgrade one minor version at a time

You can't jump versions. A 1.31 cluster going to 1.34 is three upgrades: 1.32, 1.33, 1.34. For each:

aws eks update-cluster-version --name prod-eu --kubernetes-version 1.32
aws eks wait cluster-active --name prod-eu

# add-ons
aws eks update-addon --cluster-name prod-eu --addon-name vpc-cni --addon-version <compatible>
aws eks update-addon --cluster-name prod-eu --addon-name coredns --addon-version <compatible>
aws eks update-addon --cluster-name prod-eu --addon-name kube-proxy --addon-version <compatible>

# managed node group
aws eks update-nodegroup-version --cluster-name prod-eu --nodegroup-name ng-general

Fargate pods pick up the new kubelet only when they're recreated; restart those deployments. Karpenter-managed nodes follow the AMI selection in the node class.

In-place control plane upgrades you start yourself can be rolled back within 7 days. Use that safety net by not leaving it to the auto-upgrade.

Tip

If you're three versions behind, consider a blue/green cluster: create a new cluster on the current version, deploy workloads through GitOps, and move traffic. It's often faster and safer than three in-place upgrades.

#4. Decide on extended support deliberately

Extended support is a planning buffer, not a destination. For clusters you intend to keep current, set the upgrade policy to STANDARD so they never silently drift into extended pricing:

aws eks update-cluster-config --name dev-eu --upgrade-policy supportType=STANDARD

Note that STANDARD means auto-upgrade at the end of standard support, so pair it with a reliable upgrade routine.

#Checklist

• All clusters listed with version and upgrade policy
• 1.31 clusters upgraded before 26 November 2026
• 1.34 clusters scheduled before 2 December 2026 (or knowingly moved to extended support)
• Upgrade insights clean; add-ons and charts compatible
• Nodes and Fargate workloads upgraded after each control plane step
• Upgrade policy set deliberately per cluster

#Sources

• Amazon EKS: Understand the Kubernetes version lifecycle on EKS