EKS extended support: the price of not owning upgrades

If 100 Amazon EKS clusters sat on extended support for a year, the surcharge alone would come to $438,000. That is just the control plane fee, before we start counting a single node, load balancer, or gigabyte of storage.

That figure comes from a fleet we actually helped to support. Over several years, a multi-cloud platform we built for a client grew across AWS, Azure, and VMware on premises, and over 100 of these clusters ran on EKS. None of those EKS clusters ever reached extended support, because each one was upgraded before its Kubernetes version left standard support.

If you run any clusters on Kubernetes 1.34, the surcharge starts on 2nd December 2026. That is the day 1.34 leaves EKS standard support, and every 1.34 cluster still on the default upgrade policy moves into extended support.

The way we see it, the surcharge is really a charge for upgrade work which nobody on the team owns, even though it shows up on the AWS bill and is easy to treat as a pricing problem for whoever watches cloud spend.

Every EKS version runs on a 26-month clock

Each Kubernetes version on EKS goes through the same lifecycle:

• 14 months of standard support,
• 12 months of extended support,
• and then an upgrade by AWS, whether you are ready or not.

Standard support costs $0.10 per cluster per hour. Extended support costs $0.60, made up of the standard $0.10 plus a $0.50 surcharge, and AWS has billed it since April 2024 (EKS pricing, version lifecycle). We’ve touched on this clock before in Kubernetes is complex on purpose, but we did not put a number on it then.

The surcharge works out at $4,380 if a cluster remains on extended support for 1 year. It is charged per cluster, so a development cluster running three workload pods pays exactly the same surcharge as production. To paint a picture, let’s say you have ten clusters (which is not many once you count development, staging, and production in a couple of regions); that comes to $43,800 per annum.

Kubernetes ships about three minor versions a year, so staying inside standard support means upgrading every cluster at pretty much that pace.

Your upgrade policy probably chose extended support for you

Every EKS cluster has an upgrade policy, and unless someone has changed it, it is set to extended support.

AWS added the upgrade policy in July 2024, which has two settings:

• EXTENDED: when the version reaches the end of standard support, the cluster moves into extended support, starts paying the surcharge, and keeps its version for up to another 12 months.
• STANDARD: when the version reaches the end of standard support, AWS goes straight to upgrading the control plane to the next version, and the bill stays at $0.10 an hour.

Neither setting does the upgrade work

Both settings only decide what happens to the control plane itself. Either way, your nodes (unless they run on EKS Auto Mode), your add-ons, and any manifests written for the old version are still your team’s job.

Paying for extended support does buy you a year, but the backlog will keep growing while you wait. EKS only lets you upgrade the control plane one minor version at a time, and AWS expects every managed node group to match the control plane before the next control plane upgrade starts.

A cluster which sits out its year of extended support comes out of it several versions behind, so the year you saved turns into a run of back-to-back upgrades: control plane, node groups, and add-ons, then the next version, and so on.

On the other hand, letting AWS upgrade the control plane under STANDARD avoids the surcharge, but the upgrade happens on AWS’s date. Managed node groups and self-managed nodes stay on the old version until you upgrade them, and they keep working in the meantime, because upstream lets a kubelet run up to three minor versions behind the API server; nothing fails on the day to tell you they are behind.

Add-ons such as the VPC CNI and CoreDNS are updated separately, and anything which still uses an API the new version removed will simply stop working.

We kept over 100 EKS clusters inside standard support

We treat Kubernetes upgrades as recurring, scheduled work with an owner, so the end of standard support is never the thing that starts an upgrade.

Roughly every six months, we start a new upgrade cycle that takes each cluster up to two Kubernetes versions forward, one at a time. The prep work starts with the cycle, and the upgrades follow once the target version is available everywhere in a multi-cloud platform. Batching two versions halves the number of upgrade windows to schedule, and because each version gets 14 months of standard support, a cluster two versions behind the newest release still has around six months of standard support left.

To be fair, the target version is also not ours alone to choose. We keep every cluster on the same Kubernetes version wherever it runs, so a new version has to be supported on AKS and by RKE before any cluster moves to it, and the prep work carries on while we wait for them.

We check deprecated APIs and add-ons before every upgrade

Before each upgrade, we check the Kubernetes deprecation guide for the APIs deprecated or removed in the versions we are moving to, scan every cluster on the platform for anything still using them, and tell the teams affected what will break before we upgrade. That notice means teams can change their manifests in their own time, as opposed to finding out from a failed deploy after the upgrade.

A scan of the live objects can come back clean while a team’s manifests still use a removed version, because the API server will serve an object at any version it still supports, whichever version it was applied with. So finding what a team really wrote means checking the manifests in their Git repositories and Helm charts.

Alongside the API scan, we audit the add-ons and platform services in use on each cluster, and check whether the target version needs them upgraded too, since none of them moves with the control plane.

Development clusters, and production clusters which do not face customers, move first. These are generally the easiest to rebuild or recover, so any problem with a new version shows up where it does the least harm.

At the time, the EKS clusters ran managed node groups, whose rolling updates fail with a PodEvictionFailure if a node has not drained within 15 minutes. A single over-strict pod disruption budget is enough to cause that, and we also had pods stuck terminating because their persistent volumes would not unmount, which holds up the drain just the same.

Someone has to own the schedule

Whichever upgrade policy your clusters have, the surcharge only stays off the bill when a named team owns upgrades and has the time to do them.

The surcharge is only the part of the price of not owning upgrades that shows up on a bill. A cluster is a stack of components with support windows of their own (the add-ons, the ingress controller, the service mesh, the operators, and the Helm charts that install them), and each one supports only a range of Kubernetes versions.

Keeping a fleet current is a lot like spinning plates, because it only takes one of those components falling too far behind to hold up the upgrade of everything that depends on it.

For most organisations, upgrades belong to the Platform team, where in sprints they tend to lose out to feature work until a deadline forces the issue.

Across a large fleet, most of the effort goes into everything around the schedule: running the cycle across every cluster and platform, testing each version before it reaches production, working through the changes with every team affected, and fixing whatever each upgrade turns up.

How can LiveWyer help?

LiveWyer is a cloud native consultancy that builds and runs Kubernetes platforms. We were London’s first Kubernetes consultancy, and since 2015 our engineers have designed and operated platforms on AWS, Google Cloud Platform, Azure, and on premises, as well as moving teams off VMware and modernising older applications into containers.

If your fleet is already behind, or your platform team does not have the time to keep up, before 2nd December you need to know:

• which of your clusters are on 1.34, and which are already paying the extended support surcharge,
• what the next Kubernetes versions will mean for your manifests, add-ons, and platform services,
• and who on your team owns the upgrade schedule from here.

The quickest way to start is to talk to our engineers. After a short intro call, we run a two-hour workshop on your EKS fleet with our senior engineers, looking at where each cluster sits in its support window and what stands between it and the next two versions. We send you a written summary of the trade-offs and recommended next steps afterwards, and we cover the cost of the workshop.

If the workshop points to a wider platform change, our Cloud Platform Engineering pilot builds it around one of your own applications in three weeks.

If you would rather hand the work over, our engineers can join your platform team and take on the upgrades with you.

Frequently asked questions