EKS extended support: what it costs and how to plan the upgrade
Amazon EKS supports each Kubernetes version for a fixed time. After that, you pay more per cluster, or the cluster is upgraded for you. This guide shows the price, the dates and the steps.
Updated
What EKS extended support is
Each Kubernetes minor version (for example 1.33) is under standard support in Amazon EKS for the first 14 months after its EKS release. After that it enters extended support for the next 12 months. In total, a version is supported for 26 months.
Extended support lets you stay on one Kubernetes version for longer. It costs extra per cluster hour.
In extended support, AWS keeps releasing security patches for the Kubernetes control plane. It also releases patches for the Amazon VPC CNI, kube-proxy and CoreDNS add-ons, and for the AWS-published EKS optimized AMIs (Amazon Linux, Bottlerocket and Windows) and EKS Fargate nodes. You keep access to technical support from AWS.
Extended support is not a way to avoid upgrades. The AWS docs say: plan to upgrade regularly, even if you use extended support.
What it costs
The EKS pricing page lists two prices per cluster per hour: $0.10 for a version in standard support, and $0.60 for a version in extended support. The extended price is the standard price plus $0.50. Check the pricing page for the current numbers before you plan.
Billing for extended support starts at the beginning of the day (UTC) on which the version reaches the end of standard support.
Example. Take one cluster and a month of 730 hours. This is an assumption we use for the example. Your bill depends on the real hours.
- Standard support: 730 h x $0.10 = $73.00 per cluster per month.
- Extended support: 730 h x $0.60 = $438.00 per cluster per month.
- Difference: 730 h x $0.50 = $365.00 per cluster per month.
- Ten clusters on an extended version: ten times the difference.
Which versions are in which phase
On 2026-10-31 the AWS docs list versions 1.34 to 1.37 in standard support, and versions 1.31, 1.32 and 1.33 in extended support. The docs give these dates (UTC):
- 1.31: standard support ended November 26, 2025. Extended support ends November 26, 2026.
- 1.32: standard support ended March 23, 2026. Extended support ends March 23, 2027.
- 1.33: standard support ended July 29, 2026. Extended support ends July 29, 2027.
- 1.34: standard support ends December 2, 2026. Extended support ends December 2, 2027.
aws eks describe-cluster-versions What happens when extended support ends
EKS does not let a control plane stay on a version after extended support ends. You can no longer create new clusters with that version. Existing control planes are upgraded by EKS to a supported version, in a gradual rollout after the end date.
EKS cannot tell you when this happens. The upgrade can come at any time after the end date, and you get no notice before it. The AWS docs recommend that you upgrade the control plane yourself, before this.
The automatic upgrade covers the control plane only. Self-managed nodes and managed node groups stay on the old version. EKS Auto Mode nodes may update by themselves. After the upgrade you must update the add-ons and the Amazon EC2 nodes by hand. A cluster that was upgraded this way cannot be rolled back.
How to turn extended support off
The cluster upgrade policy decides what happens at the end of standard support. It has two values. STANDARD means the cluster is upgraded automatically and you pay no extended support charge. EXTENDED means the cluster enters extended support and you pay the extended price. EXTENDED is the default for new and existing clusters.
Read the current value of a cluster:
aws eks describe-cluster \
--name <cluster-name> \
--query "cluster.upgradePolicy.supportType" How to turn it off, and the limits
Set the policy to STANDARD with this command. In the console, use Configuration, then Manage, then Kubernetes version settings, and choose Standard support.
There is one hard limit. You cannot disable extended support once the cluster has entered it. You can only change the policy while the cluster is on a version in standard support. So make this choice before the end of standard support.
The other direction also needs care. If you want extended support, AWS recommends you enable it before standard support ends. EKS cannot guarantee a late change if an automatic upgrade has already started.
If a cluster is already in extended support, the way to stop the charge is to upgrade it to a version in standard support.
aws eks update-cluster-config \
--name <cluster-name> \
--upgrade-policy supportType=STANDARD How to plan the upgrade
These steps follow the AWS guide to update a cluster. Do them in this order.
- Test first. Run your applications against the new version in a test cluster or a CI workflow before you touch production.
- Compare versions. Run kubectl version for the control plane and kubectl get nodes for the nodes. Managed nodes and Fargate nodes must be on the same minor version as the control plane before you upgrade the control plane.
- Check deprecated APIs. Use Amazon EKS upgrade insights (part of cluster insights) and the Kubernetes Deprecated API Migration Guide. Insights look for deprecated API use over a rolling 30 day window, so the status can take up to 30 days to update after you fix an issue.
- Upgrade the control plane one minor version at a time. To go from 1.31 to 1.33, first go to 1.32, then to 1.33. You cannot pause an upgrade after it starts.
- Upgrade the nodes to the same minor version as the control plane. Managed node groups and self-managed nodes are not upgraded with the control plane.
- Upgrade the Amazon VPC CNI, CoreDNS and kube-proxy add-ons, and other tools such as cluster-autoscaler. Then update kubectl so it is within one minor version of the control plane.
aws eks update-cluster-version --name <cluster-name> \
--kubernetes-version <version-number> --region <region-code> Sources
Pages read for this guide. Check them for changes before you act.