Kubernetes Extended Support Cost: The 2026 Bill for Falling a Version Behind

Most teams meet the Kubernetes extended support cost through a billing anomaly alert, not a calendar reminder. Nothing breaks when it starts. The control plane keeps serving, pods keep scheduling, and the per-cluster management fee goes from $0.10 an hour to $0.60 an hour on the first day of the month it applies. That is a sixfold increase on every cluster, switched on by default, with no action required from you. We have walked into fleets that had been paying it across 30 clusters for most of a year without a single person noticing. Here is what it costs, and the two or three times we would pay it on purpose.

The surcharge has the same shape on every cloud

AWS and Google charge the identical number. Amazon EKS lists $0.10 per cluster per hour on standard support and $0.60 per cluster per hour on extended support, which it describes as the standard fee plus a $0.50 per cluster per hour surcharge. Google's extended support announcement puts the GKE extended support period cluster management fee at $0.50 per cluster per hour on top of the same $0.10 base.

Azure prices the same idea differently. AKS gives one year of community support followed by one year of long-term support, and LTS is only available if you move the cluster to the Premium cluster management tier and set the support plan explicitly. There is no separately named surcharge, so the number you compare against is the Premium tier rate for your region on the AKS pricing page.

| Cloud | Standard window | Extended window | How you opt in | What it costs | |---|---|---|---|---| | Amazon EKS | 14 months from EKS release | 12 months | On by default (supportType: EXTENDED) | $0.60/cluster/hour, up from $0.10 | | Google GKE | About 14 months | About 10 months | Enroll the cluster in the Extended release channel | $0.50/cluster/hour on top of the $0.10 base | | Azure AKS | About 12 months community support | About 12 months LTS | Premium tier plus AKSLongTermSupport | Premium tier rate, see the pricing page |

Two of those three bill you whether or not you chose it. EKS in particular sets the upgrade policy to EXTENDED on any cluster created outside the console, which covers Terraform, eksctl and the API, and says so in its own docs. The default behaviour of an unattended cluster is to start charging six times as much and keep running.

The date that bills you is not the date you are watching

Engineering teams track the upstream Kubernetes end-of-life date. Finance gets billed on the managed service date, and the two are months apart.

Kubernetes 1.34 reaches upstream end of life on 27 October 2026. On EKS, the same version keeps standard support until 2 December 2026. Five weeks of difference, and the wrong one is in most runbooks. AWS is explicit that billing for extended support starts at the beginning of the day the version reaches end of standard support, in UTC+0.

| EKS version | EKS release | End of standard support | End of extended support | |---|---|---|---| | 1.36 | 2 June 2026 | 2 August 2027 | 2 August 2028 | | 1.35 | 27 January 2026 | 27 March 2027 | 27 March 2028 | | 1.34 | 2 October 2025 | 2 December 2026 | 2 December 2027 | | 1.33 | 29 May 2025 | 29 July 2026 | 29 July 2027 | | 1.32 | 23 January 2025 | 23 March 2026 | 23 March 2027 | | 1.31 | 26 September 2024 | 26 November 2025 | 26 November 2026 |

Source: Amazon EKS Kubernetes release calendar.

Read the 1.33 row again. Standard support ended on 29 July 2026. Anyone still on EKS 1.33 at the end of September has been paying the surcharge for two months, roughly 1,500 hours, which is about $740 of pure surcharge per cluster before anyone opened a ticket. The 1.31 row is worse in a different way: extended support ends on 26 November 2026, and after that AWS upgrades the control plane on its own schedule with no notification.

Work out your exposure in one command

You do not need a FinOps tool for this. Two AWS CLI calls give you the whole picture.

# Every cluster in the current region, with its version and upgrade policy.
aws eks list-clusters --query 'clusters[]' --output text \
  | tr '\t' '\n' \
  | while read -r c; do
      printf '%s\t%s\t%s\n' "$c" \
        "$(aws eks describe-cluster --name "$c" --query 'cluster.version' --output text)" \
        "$(aws eks describe-cluster --name "$c" --query 'cluster.upgradePolicy.supportType' --output text)"
    done

# The support dates for every version EKS currently offers.
aws eks describe-cluster-versions \
  --query 'clusterVersions[].[clusterVersion,versionStatus,endOfStandardSupportDate,endOfExtendedSupportDate]' \
  --output table

The versionStatus field comes back as STANDARD_SUPPORT, EXTENDED_SUPPORT or UNSUPPORTED. The older status field is deprecated in the CLI reference, so do not build a report on it. Any cluster whose version shows EXTENDED_SUPPORT is on the higher rate right now. Multiply and you have the number to take to your VP: $0.50 per hour times 8,760 hours is $4,380 per cluster per year. A 20-cluster fleet sitting one version too far back costs $87,600 a year in surcharge alone, and produces nothing for the money.

Run the same exercise on the workload side of the bill and the two numbers usually rhyme. Our Kubernetes cost optimization framework covers the node and request-sizing half of this, which is normally larger. The lifecycle surcharge is the half nobody has an owner for.

What the surcharge buys, and what it quietly does not

Extended support on EKS is a real product rather than a penalty box. AWS ships control plane security patches, patched VPC CNI, kube-proxy and CoreDNS add-ons, and patched EKS-optimized AMIs for Amazon Linux, Bottlerocket and Windows, plus Fargate node updates, and you keep technical support. If you are paying, you are getting something.

What you are not getting is a way out at the end. AWS states that when extended support ends, the automatic upgrade covers only the Kubernetes control plane, and that self-managed nodes and EKS managed node groups stay on the previous version. So the failure mode is not a cluster going dark. It is a control plane that jumps a minor version at a time AWS chooses while your kubelets sit where they were, and somebody discovers the version skew during an unrelated incident. Google is blunter about the same moment. At the end of extended support, GKE "upgrades all clusters still running the now-unsupported minor version, regardless of blocking issues".

There is one more clause worth reading before you plan around extended support as a safety net. Once an EKS cluster has entered extended support, you cannot turn it off. To change supportType back to STANDARD, the cluster has to be running a version that is in standard support, which is the thing you were trying to avoid doing.

When we would actually pay for it

Default-on billing is not a decision, and "we have been busy" is not a reason. There are three situations where we tell clients to pay the surcharge deliberately and stop feeling bad about it.

A named blocker with a dated fix. You are on 1.33, a controller in your critical path has not shipped 1.34 support, and the vendor has given you a release month. Pay for the months between now and that month. Do not buy the full 12. The upgrade blockers we see most often are admission webhooks and networking, both of which have their own migration work: see our notes on migrating mutating webhooks to admission policies and the kube-proxy IPVS to nftables migration.

A freeze window you genuinely cannot move. A SOC 2 observation period or a peak trading season is not the time to change a control plane. Paying $4,380 for a year of one cluster to avoid a change-control fight during an audit is cheap next to the audit. If that is your situation, our SOC 2 implementation guide explains which evidence the freeze is protecting.

A cluster with a retirement date. If the cluster is being decommissioned in four months, four months of surcharge is 2,920 hours at $0.50, or $1,460. Two engineer-weeks of upgrade work on a cluster that will not exist by spring costs more than that and buys nothing.

Everything else is drift. If the reason your cluster is on an old version is that nobody scheduled the upgrade, you are not buying flexibility. You are paying a subscription to postpone a decision.

One operational detail if you do choose to pay: set the policy before the version leaves standard support. AWS warns that you can enable extended support afterwards, but it cannot guarantee the change takes effect if an automatic upgrade has already started.

The cadence that keeps you off the line item

Kubernetes ships a minor version roughly every four months, which is about three a year. EKS gives you 14 months of standard support. The arithmetic is forgiving: you can skip a release, land on every second one, and still never touch the surcharge, as long as you do not drift past two versions behind.

Our rule for client fleets is that a new minor version goes into non-production within 30 days of the managed service offering it, and into production within 90. That is two planned upgrade windows a year, each about three weeks of calendar time and a few engineer-days of actual work. The teams who hit this rule spend less total effort than the teams who upgrade once every 18 months, because each jump is one version instead of three and the deprecations are still fresh.

| Quarter | What runs | Why | |---|---|---| | Q1 | Inventory: versions, upgrade policies, support dates | Catches clusters already on the surcharge | | Q2 | Upgrade window one, non-prod then prod | Lands the version released in the previous quarter | | Q3 | Blocker review: webhooks, CNI, ingress, node runtime | Finds the things that make Q4 slip | | Q4 | Upgrade window two, non-prod then prod | Enters the new year inside standard support |

Node-side work lives on the same calendar and is usually the part that slips, because the control plane upgrade is a button and the nodes are not. Our containerd 1.7 end of life migration guide covers that half of the upgrade in detail.

What it looks like across a fleet

| Fleet | Clusters on extended support | Annual surcharge | What we would do | |---|---|---|---| | Single product team | 3 (dev, staging, prod) | $13,140 | Upgrade. The surcharge is roughly a month of one engineer | | Mid-size platform | 20 | $87,600 | Upgrade the 17 that have no blocker, pay on 3 with dated fixes | | Regulated enterprise | 60 | $262,800 | Fund a dedicated upgrade track. This number pays for it twice |

The third row is the one that changes conversations. At 60 clusters, the surcharge on its own funds two full-time engineers whose entire job is keeping the fleet current, and they would still have budget left. We have used exactly that argument to get upgrade work staffed at companies where it had been deferred for three planning cycles. If you want the broader version of that argument, our post on building a FinOps practice puts it in the context of the rest of the bill.

When to Get Help

Three signs it is worth bringing someone in. You do not know how many of your clusters are on the surcharge today. You have a version-skew situation between a control plane and its node groups. Or you have a blocker, usually a webhook, an ingress controller or a CNI plugin, that has stalled upgrades for more than two release cycles.

We do this work as a fixed-scope engagement: inventory the fleet, price the current exposure, clear the blockers, and hand back a cadence your team can run without us. If any of that sounds like your fleet, talk to us.