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.
| Provider | Supported | Behind | Mechanism |
|---|---|---|---|
| Amazon EKS | $0.10 / cluster-hr | $0.60 / cluster-hr | Automatic on entering extended support |
| Google GKE | $0.10 / cluster-hr | $0.60 / cluster-hr | Base fee plus a $0.50 extended-period fee |
| Azure AKS | $0.10 / cluster-hr | $0.60 / cluster-hr | Long 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 regionsfor 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.
- EKS — extended support runs up to 12 months past standard. When it ends, AWS upgrades the cluster for you.
- GKE — the extended channel gets you up to 24 months on a minor release, then the same thing happens.
- AKS — LTS gives two years, and it's tied to remaining on the Premium tier.
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:
- The cluster is being decommissioned. Three months of extended support on something you're deleting in Q4 is cheaper than any migration.
- You're mid-acquisition or mid-freeze. $365/month to defer a risky change through a period where you can't safely roll back is a reasonable trade.
- The blocker is genuinely someone else's. If a vendor operator won't serve the current CRD version until their next release, buying the gap is the only option you have.
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 upgrade | An 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
- Prices change. These are the published rates as of August 2026, and all three providers have adjusted Kubernetes pricing before. Check the vendor page before you put a number in a deck.
- This is control plane only. Nodes, storage, load balancers, and egress are billed identically either way. The 6× applies to a line item that is often a rounding error next to compute — which is exactly why it goes unnoticed, but also means "our cluster costs 6× more" would be wrong.
- Support windows aren't uniform. Standard support length varies by provider and has shifted over time. Enumerate versions and check each against the current lifecycle table rather than assuming a fixed number of months.
- The fee doesn't tell you what will break. It tells you the deadline is real and costs money. Finding the actual blockers is a separate exercise — we wrote that one up here.
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