The $438 cluster nobody approved

There is a line in the EKS version lifecycle documentation that costs teams more money than any misconfigured autoscaler I have seen:

Extended support is enabled by default.

If a cluster is running a Kubernetes version that has aged out of standard support, AWS does not stop it, warn you at the terminal, or ask anybody to approve anything. The control plane keeps running exactly as before, and the hourly rate goes up six times.

Nobody signs off on it. That is the whole problem.

What it actually costs

An EKS control plane on standard support is $0.10 per cluster per hour. On extended support it is $0.60 per cluster per hour.

The difference is about $365 a month per cluster, for an identical control plane.

Most teams do not run one cluster. Dev, staging and production on the same aged version is roughly $1,100 a month, or $13,000 a year, to postpone an upgrade.

The timeline that catches people

Each Kubernetes minor version gets:

• 14 months of standard support from its EKS release date
• 12 months of extended support after that

So a version has a 26-month life on EKS. The second half of it costs 6× the first.

Billing for extended support starts at the beginning of the day the version reaches end of standard support, UTC. There is no grace period and no partial month — the meter changes rate overnight.

At the end of the 26 months, AWS auto-upgrades your control plane. You get no notification before that happens, and it can occur at any time after the end date. Your nodes are not upgraded with it, so a cluster that gets auto-upgraded ends up with a control plane ahead of its node groups.

Check whether you are paying it right now

This takes one command:

aws eks describe-cluster-versions \
  --query 'clusterVersions[].{version:clusterVersion,status:status,
           standardEnds:endOfStandardSupportDate}' \
  --output table

Anything with status: EXTENDED_SUPPORT is billing at $0.60/hr.

Then check what your own clusters are running:

for c in $(aws eks list-clusters --query 'clusters[]' --output text); do
  v=$(aws eks describe-cluster --name "$c" --query 'cluster.version' --output text)
  p=$(aws eks describe-cluster --name "$c" \
        --query 'cluster.upgradePolicy.supportType' --output text)
  echo "$c  version=$v  policy=$p"
done

Two things to read in that output:

• version — cross-reference against the extended support list above.
• policy — EXTENDED means the cluster will silently roll into paid support when its version ages out. STANDARD means it will be auto-upgraded at end of standard support instead.

Both defaults are EXTENDED. On every new cluster, and on every existing one.

The two ways out

Upgrade. Obviously. This is the right answer and it is the one people defer, usually because the last upgrade was unpleasant and nobody has budgeted for the next one. Worth noting that the upgrade pays for itself immediately — at $365/month/cluster saved, even a week of engineering time clears the bar in a couple of months.

Or change the upgrade policy, if you would rather be force-upgraded than billed:

aws eks update-cluster-config \
  --name my-cluster \
  --upgrade-policy supportType=STANDARD

Be careful with this one. Setting STANDARD means AWS auto-upgrades the control plane when standard support ends, on its schedule rather than yours. That is fine for a dev cluster. It is a genuinely bad idea for production, where you want to choose the maintenance window and test the version against your workloads first.

The honest framing: EXTENDED is paying AWS to let you choose your own upgrade date. That is not a scam — it is a real option with a real price. The failure is not knowing you bought it.

Make it visible

The reason this bill grows is that nobody sees it. Two things fix that permanently.

Alarm on the version, not on the cost. By the time a cost anomaly fires, you have been paying for weeks. Check support status on a schedule and alert when a cluster is within 60 days of end of standard support — that is roughly when AWS starts sending Health Dashboard notices, and it is enough runway to plan a real upgrade.

Put the upgrade policy in your Terraform, explicitly, so the default never applies silently:

resource "aws_eks_cluster" "this" {
  name     = "production"
  version  = "1.36"
 
  upgrade_policy {
    support_type = "EXTENDED"
  }
}

Writing it out does not change the behaviour. It changes who knows about it — the next person reading the module sees a deliberate choice instead of inheriting a default they never saw.

What I would do differently

I used to treat version upgrades as a reliability task, scheduled against risk. Deferring one felt free, because the cluster kept working.

It is not free, and framing it as a reliability decision hides that. An upgrade deferred past end of standard support is a $365 per month per cluster decision, and it should be argued on those terms with whoever owns the budget. "We should upgrade because it is good practice" loses to a feature deadline every time. "We are paying $1,100 a month not to do this" does not.

Go run the two commands. It is five minutes, and the answer is either reassuring or worth four figures a month.

References

• Amazon EKS pricing — standard and extended support rates
• Understand the Kubernetes version lifecycle on EKS — support windows, the release calendar and the extended support FAQ
• Disable EKS extended support — changing the cluster upgrade policy