EKS Extended Support Costs Six Times More Per Cluster. How I Upgrade Out of It

In April a client's AWS bill had a line I see on a lot of EKS accounts: $1,728 for the month in EKS extended support. Four clusters, development, CI, staging and production, all on Kubernetes 1.32, all past standard support.

Nothing was broken. That is why it had been left alone. But the fee was paying for the privilege of staying on an old version, and the version was not going to get younger.

What extended support actually costs

Amazon EKS supports each Kubernetes version for 14 months of standard support, then 12 months of extended support. In standard support a cluster costs $0.10 an hour. In extended support it costs $0.60 an hour. That is about $365 more per cluster per month, before anything else on the bill changes.

Extended support is turned on by default. You do not opt in. A cluster just crosses the date and the price changes.

Four clusters at $0.60 for a 30-day month is the $1,728 I saw. Getting them back into standard support saved about $1,440 a month.

The dates worth checking this quarter

From the AWS release calendar as of October 2026:

• Kubernetes 1.31, 1.32 and 1.33 are already in extended support.
• 1.31 extended support ends on November 26, 2026. After that, AWS upgrades the control plane for you, at a time it does not announce.
• 1.34 leaves standard support on December 2, 2026.

Check with aws eks describe-cluster-versions, or look at the version column in the EKS console. If a cluster is on 1.34 or older, plan the upgrade now.

Waiting for the automatic upgrade is the worst option

At the end of extended support, EKS upgrades the control plane only. Managed node groups and self-managed nodes stay on the old version. Your add-ons stay where they were. So you get a version jump you did not test, at a time you did not pick, with nodes and controllers that may not match.

An in-place upgrade you run yourself can be rolled back to the previous minor version within 7 days. A cluster that AWS upgraded at the end of extended support cannot be rolled back.

The sequence I use

I use the same order on every cluster and every version. Development first, then CI, then production.

1. Code first. Run the infrastructure plan and get it clean before touching anything. If the code and the cluster already disagree, an upgrade makes that worse.
2. Add-ons, one at a time. The node autoscaler, the load balancer and ingress controllers, the certificate manager, the storage drivers. Least customer-visible first. Check each one against the target Kubernetes version before you change it.
3. Control plane. One minor version at a time. EKS does not let you skip.
4. Nodes. Roll them one at a time behind disruption budgets.
5. Snapshot and review. I take a snapshot of cluster state before and after, and compare them. It catches things that a green dashboard does not.

On that engagement I ran this twice: 1.32 to 1.33 in late May on all four clusters, then 1.33 to 1.34 in mid-July on the three that were left, after the unused staging environment was removed. The node autoscaler went from 1.4 to 1.11 across the two upgrades. Years of skipped controller upgrades are usually the real work in an EKS upgrade, not the control plane.

What surprised me

Some things did not behave the way the documentation suggested.

• A 10% disruption budget on a small node pool rounds down to zero. Drifted nodes never rolled until I changed the budget. If a pool has fewer than ten nodes, use an absolute number.
• An expired cloud session looked like a code error. A short-lived session ran out halfway through an apply, and the error pointed at the Terraform, not the credentials. Start long applies with a fresh session.
• The autoscaler chart stopped shipping its CRDs. They had to be managed separately. Read the chart's upgrade notes, not only the app's.
• One permission the planning notes said was required was not. Check, do not copy.

Where the seconds of disruption came from

The production node roll covered 16 nodes, one at a time. Customers saw about 15 to 30 seconds of disruption, and it came from one place: a cache node moved to a new host while the application reconnected. The control plane upgrade itself was invisible.

That is the pattern I see most often. The cluster upgrades cleanly. The application has one dependency that does not reconnect fast. So before a production upgrade, find the stateful pieces (caches, queues, anything with a long-lived connection) and decide how each one will move. The full write-up is in Two EKS Upgrades with Seconds of Disruption.

Make the next one boring

Kubernetes ships a new minor version about every four months. If upgrades are a project, you will fall behind again within a year. What helped most was writing the sequence down and running it the same way each time, so the next upgrade is a checklist, not an investigation. By September all three clusters ran the same 1.34 patch release, with no version drift between environments.

Checklist

• List every cluster and its version. Mark anything in extended support or leaving standard support in the next 90 days.
• Get the infrastructure plan clean before you start.
• Upgrade add-ons one at a time, least visible first.
• Upgrade the control plane one minor version at a time.
• Roll nodes one at a time; use absolute disruption budgets on small pools.
• Find every stateful dependency and plan how it moves.
• Snapshot cluster state before and after, and compare.

If your clusters are in extended support or close to it, I can run the upgrade with you or review your plan. See Kubernetes and EKS consulting, or start with an AWS Cost and EKS Review if you want the upgrade path and the bill looked at together.

Related serviceKubernetes & Platform: Ship daily. Sleep nightly.