What Happens When Your EKS Version Reaches End of Support?

When an Amazon EKS version reaches the end of standard support, your cluster automatically moves to extended support, and the control plane fee rises from $0.10 to $0.60 per cluster per hour. When extended support ends 12 months later, AWS upgrades the control plane for you, on its schedule, whether your workloads are ready or not. Two deadlines are close: EKS 1.31 extended support ends on November 26, 2026, and EKS 1.34 standard support ends on December 2, 2026.

The safest path is to upgrade on your own schedule, one minor version at a time, after checking for deprecated APIs, outdated add-ons, and node changes. The rest of this guide covers how.

How Does EKS Version Support Work?

Each Kubernetes version on EKS gets 14 months of standard support from its EKS release, followed by 12 months of extended support. That's a little over two years in total, and Kubernetes ships a new minor version roughly every four months, so a cluster that isn't upgraded regularly falls behind quickly.

Here's where the versions most teams are running stand as of October 2026:

AWS publishes the full schedule in its Kubernetes version lifecycle documentation. It's worth noticing how many versions are already in extended support: if you're on 1.31, 1.32, or 1.33, you're paying the higher rate today.

What Happens When Support Ends?

At the end of standard support

Your cluster keeps running. AWS moves it into extended support automatically and starts charging the higher rate that day. The control plane fee goes from $0.10 to $0.60 per cluster per hour. That's an extra $0.50 an hour, or about $4,380 per cluster per year, before counting anything else.

For one cluster, that's an annoyance. For an organization with a dozen clusters across development, staging, and production, it's a line item someone in finance will ask about.

If you'd rather not enter extended support at all, EKS lets you set a cluster's upgrade policy to standard support only. The cluster is then upgraded automatically at the end of standard support instead of moving to the higher rate.

At the end of extended support

AWS upgrades the control plane to the oldest supported version, through a gradual rollout on its schedule. Two things make this risky:

• Only the control plane is upgraded. Your nodes stay on their current version. Kubernetes supports nodes running up to three minor versions behind the control plane, for example 1.29 nodes with a 1.32 control plane. An automatic upgrade moves the control plane forward one version, so if your nodes are already at that limit, they end up outside it, in a combination Kubernetes doesn't test or support. Clusters that reach the end of extended support are often the ones whose nodes have fallen furthest behind, so check node versions well before the deadline. And unlike an upgrade you start yourself, an automatic upgrade at the end of extended support can't be rolled back. Your nodes stay where they were, so you can end up with a control plane and nodes further apart in version than you planned.
• Nobody checks your workloads first. If your manifests or Helm charts use an API that was removed in the new version, those deploys start failing after the upgrade, and you find out during an incident instead of a planned window.

An automatic upgrade is a safety net, and it's a poor substitute for a planned one.

What Changes Along the Upgrade Path?

EKS upgrades go one minor version at a time, so getting from 1.31 to a current version means several upgrades in a row. A few changes along the way catch teams off guard:

• Amazon Linux 2 nodes stop at 1.32. EKS 1.32 is the last version with EKS-optimized Amazon Linux 2 AMIs. From 1.33 on, you'll need Amazon Linux 2023 or Bottlerocket nodes. If your node groups still run AL2, the operating system migration is part of the version upgrade, and it's often the biggest piece of work.
• containerd 1.x support ends after 1.35. Kubernetes 1.35 is the last release that supports containerd 1.x, so nodes need containerd 2.x before you can move past it. Anything that depends on containerd configuration, such as registry mirrors or custom runtime settings, should be tested on the new runtime first.
• APIs get removed. Most Kubernetes releases remove some deprecated API versions. A manifest or Helm chart that still uses one will fail to apply after the upgrade, even though the workload already running keeps going.
• Newer releases expect cgroup v2. Recent Kubernetes versions are steadily tightening support for cgroup v1. Amazon Linux 2023 and Bottlerocket both use cgroup v2, which is another reason the node migration matters.

AWS lists version-specific changes in its release notes for each version. Read the notes for every version you'll pass through, not just the last one.

How Do I Upgrade EKS Safely?

1. Take inventory. List every cluster with its EKS version, node operating system, node groups, and installed add-ons. Upgrades usually go wrong in the cluster nobody remembered.
2. Find deprecated APIs before they find you. Scan your manifests, Helm releases, and live cluster for API versions that are deprecated or removed in your target version. Fairwinds's open source tool Pluto does exactly this.
3. Check your add-ons and charts. Core EKS add-ons like the VPC CNI, CoreDNS, and kube-proxy need the versions AWS recommends for each Kubernetes version, and third-party Helm charts often have version requirements too. Fairwinds's open source Nova finds outdated Helm charts and container images.
4. Plan the node migration. If you're still on Amazon Linux 2, decide between Amazon Linux 2023 and Bottlerocket, and test your workloads on the new nodes and containerd 2.x before the version upgrade forces the change.
5. Upgrade outside production first. For each minor version, work in this order:
• Check the VPC CNI. Confirm your Amazon VPC CNI version supports the target Kubernetes version, and update it first if it doesn't.
• Upgrade the control plane.
• Update the remaining add-ons. Move kube-proxy, CoreDNS, and other add-ons, such as the EBS CSI driver, to the versions AWS recommends for the new Kubernetes version.
• Roll the worker nodes. Replace or cycle nodes with PodDisruptionBudgets in place, so draining nodes doesn't drop your applications below the availability they need.
• Repeat. EKS upgrades one minor version at a time, and managed nodes must match the control plane before the next upgrade, so finish the full cycle before starting the next one.
6. Make it a habit. With a new Kubernetes version every four months or so, teams that upgrade on a regular schedule spend far less time on each upgrade than teams that wait for a deadline.

How We Roll Out an Upgrade at Fairwinds

At Fairwinds, we review Kubernetes release notes and changelogs to identify deprecated APIs, breaking changes, and new or updated features. We then test the upgrade in our internal test clusters to identify potential issues before applying it to customer environments.

Preparation and Testing: Before an upgrade begins, we review release notes, check for deprecated APIs and breaking changes, verify add-on compatibility, and test the new version and nodes. Once everything is ready, the upgrade duration depends largely on the cluster's size and the number of worker nodes that need to be replaced.

We bring years of experience managing Kubernetes clusters across different versions, cloud providers, cluster sizes, and self-managed environments.

One key difference is our approach to testing. Many teams use an existing non-production cluster to test upgrades, which can disrupt other teams' workflows. We maintain dedicated test clusters for different cloud providers, allowing us to test new versions, explore potential failure scenarios, and validate changes without blocking other teams.

Our testing covers a variety of scenarios to identify compatibility issues and potential problems before upgrades reach customer environments. This experience and preparation help us identify risks early and make customer upgrades more predictable.

Customer Communication and Rollout: We announce planned cluster upgrades in advance so customers know what to expect. We deploy the changes to non-production clusters first, roll the nodes, and allow the changes to bake for at least one week. If everything works as expected, we proceed with production upgrades.

Validation and Monitoring: Throughout the rollout, we verify node readiness, workload health, networking, autoscaling, and monitoring. We closely monitor clusters after the upgrade and notify customers when the upgrade is complete.

Where Fairwinds Fits

Pluto and Nova are free and open source, and they cover the two checks teams most often skip. If you want those checks running continuously across every cluster, along with policy and cost visibility, Fairwinds Insights brings them together in one place.

At Fairwinds, we deploy and test the same add-ons our customers use in our dedicated test environments. This allows us to identify deprecated APIs and compatibility issues during our release review and testing processes, before changes reach customer clusters.

Our approach helps us catch problems early rather than discover them during a customer upgrade.

We've worked with customers running older Kubernetes versions across managed services like EKS, GKE, and AKS, as well as self-managed Kubernetes clusters managed with tools like kOps.

Running outdated Kubernetes versions can expose organizations to known vulnerabilities and make clusters increasingly difficult to maintain. Since everything is connected with other components of the cluster, the longer they are delayed, it gets harder and harder to upgrade without breaking anything. Teams often postpone upgrades because they require careful planning, thorough testing, and coordination across multiple teams. However, delaying upgrades can eventually turn a planned maintenance task into an emergency. A Python application dependency may require a newer version of an add-on or Kubernetes itself, forcing teams to resolve multiple interconnected compatibility issues under tight deadlines. What could have been a controlled, well-tested upgrade becomes a high-pressure effort to fix several problems at once.

Beyond reducing security risks and maintenance complexity, staying current also has financial benefits for EKS customers. AWS charges about $4,380 per cluster per year for extended support compared with standard support. Regular upgrades help organizations avoid these additional charges while reducing compatibility issues and long-term maintenance overhead.

If you'd rather have an experienced team handle this for you, Fairwinds provides EKS managed services, including planned upgrades that stay ahead of the support calendar.

Frequently Asked Questions

What does EKS extended support cost?

The control plane fee rises from $0.10 to $0.60 per cluster per hour, an extra $0.50 an hour or about $4,380 per cluster per year. Worker node costs don't change.

Can I skip versions when upgrading EKS?

For most clusters, no. If you run Managed Node Groups, Karpenter, or self-managed EC2 instances, AWS upgrades only the control plane—rolling your node AMIs and updating add-ons is entirely your responsibility. The only exception is if your cluster runs EKS Auto Mode, where AWS manages both the control plane and compute infrastructure, including automated node operating system patching and kubelet updates.

Will AWS upgrade my nodes automatically?

No. When extended support ends, AWS upgrades the control plane only. Managed node groups, self-managed nodes, and add-ons are still yours to upgrade.

Can I avoid extended support charges entirely?

Yes. Upgrade before standard support ends, or set the cluster's upgrade policy to standard support only, so it upgrades automatically at the end of standard support instead of entering extended support.

How often should we upgrade EKS?

Kubernetes releases a new minor version about every four months. Upgrading on a similar cadence keeps each upgrade small and keeps you in standard support.

How do I know when my EKS version reaches the end of support?

AWS publishes standard and extended support dates for each EKS Kubernetes version. Check the Amazon EKS Kubernetes versions documentation to find your version's support deadlines. You can also check your cluster's current version in the AWS console or with the kubectl version command. Plan your upgrade ahead of the standard support deadline to avoid extended-support charges.