← All posts

Falling behind costs 6×.

Three clouds, three separate pricing teams, one identical answer: staying on a version past its standard support window costs exactly six times as much. That is not a coincidence, and it is the number that gets an upgrade funded.

3 August 2026· 7 min read· Runtimez
kubernetes finops eks upgrades

Getting an upgrade prioritized is rarely a technical argument. It's a budget argument, and most platform teams don't realize they already have the number.

Every major managed Kubernetes provider now charges a premium once your cluster falls past its standard support window. What's remarkable is that all three landed on the same figure, independently, without matching each other's announcements.

ProviderSupportedBehindMechanism
Amazon EKS$0.10 / cluster-hr$0.60 / cluster-hrAutomatic on entering extended support
Google GKE$0.10 / cluster-hr$0.60 / cluster-hrBase fee plus a $0.50 extended-period fee
Azure AKS$0.10 / cluster-hr$0.60 / cluster-hrLong Term Support requires the Premium tier

Same base rate. Same penalty rate. Same multiple. The mechanisms differ — AWS moves you automatically, Azure makes you opt into a pricing tier — but the arithmetic is identical.

$0.50 per cluster-hour is $365 a month, or $4,380 a year, per cluster. Not per node. Not per workload. Per cluster, whether it's running four hundred pods or four.

That last part is what makes the number bite. A control-plane fee doesn't scale with how much value the cluster produces — so your idle staging cluster on an old version costs exactly as much to leave behind as production does.

Price your own fleet

The exposure is linear in cluster count, and almost every team undercounts. Enumerate rather than estimate.

EKS — every cluster and version, all regions
for r in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  for c in $(aws eks list-clusters --region "$r" --query 'clusters[]' --output text); do
    printf '%s\t%s\t%s\n' "$r" "$c" \
      "$(aws eks describe-cluster --region "$r" --name "$c" \
           --query 'cluster.version' --output text)"
  done
done

Recent AWS CLI versions also expose the support state directly, which saves you cross-referencing a lifecycle table:

aws eks describe-cluster --name my-cluster \
  --query 'cluster.upgradePolicy.supportType' --output text
# STANDARD | EXTENDED
GKE and AKS
gcloud container clusters list \
  --format='table(name,location,currentMasterVersion,releaseChannel)'

az aks list -o tsv \
  --query '[].[name,resourceGroup,kubernetesVersion,sku.tier]'

Count every row, not just the production ones. In most orgs the real number is two to three times what people say when asked from memory — dev clusters, a per-team sandbox, the one someone spun up for a spike in 2024 and never deleted. Those are all billing at the same rate.

Ten clusters behind a version line is $43,800 a year. That is a headcount-adjacent number, and it is being spent to not do work.

The fee is the smaller cost

Here's the part that gets left out of the finance conversation: extended support is a fixed-length runway, not an indefinite option.

So the money buys time, and then the time runs out. What you're actually purchasing at $4,380 a year is the right to keep choosing your own maintenance window — and that right expires. Past the cap, the upgrade still happens, on the provider's calendar, at the provider's hour, with your team finding out what broke afterwards rather than before.

Every upgrade blocker you haven't found by then is discovered in production, on a Tuesday, by an alert.

The fee isn't a penalty for being on an old version. It's a countdown timer with a price tag attached, and paying it doesn't stop the clock.

When paying is the right call

It sometimes is, and the argument is weaker if you pretend otherwise:

What's not defensible is paying it by default, for a year, because nobody costed the alternative. That's the common case.

Turning the number into a decision

The comparison that actually lands in a planning meeting:

Cost
Deferring, 10 clusters, 12 months$43,800 plus a forced upgrade at the end
Doing the upgradeAn audit, then a bounded number of engineer-days on real blockers

You don't need a precise estimate for the second row to win the argument. You need the first row to exist as a line item, which today it usually doesn't — extended support charges land inside the same control-plane cost line as everything else, so nobody has ever seen it broken out.

Break it out. Put it next to the engineering estimate. The decision generally makes itself after that.

Where this breaks down

Disclosure: we build Runtimez, which tracks end-of-support deadlines across a fleet and puts the deferral cost next to the blockers causing it. The pricing above is public and the commands are three CLI calls — you don't need us to run this calculation, and you should run it before your next planning cycle either way.

See the intersection on your own clusters

One read-only Helm install · first report in under an hour · secrets and images never leave your cluster.

Questions? hello@runtimez.io