EKS extended support: $0.10 to $0.60 (2026)

An EKS cluster that falls out of standard support gets six times more expensive on a date AWS published years in advance, without an alarm, an email at the moment it happens, or any change in the cluster. Extended support is on by default, and once a cluster is in it you cannot turn it off.

How does EKS pricing work?

You pay per cluster per hour for the control plane, and separately for every node, volume and address you run underneath it. The Amazon EKS pricing page puts the control plane rate on the cluster's Kubernetes version:

AWS is careful that the second number is not additive on top of the first: "The $0.60 per cluster per hour is inclusive of the $0.10 per cluster per hour you pay for Amazon EKS clusters." The pricing table states the same thing as "Standard Kubernetes version support + $0.50 per cluster per hour". So the increment is $0.50 an hour, or $365 per cluster per month.

On a fleet of twenty clusters that is $7,300 a month, appearing on one day, attributable to nothing that changed. Under split cost allocation data it does not reach a pod either: SCAD splits node cost across pods, and the control plane fee is not node cost.

Does EKS cost money when the cluster is idle?

Yes. The control plane fee is per cluster per hour and has no usage component, so an empty cluster with zero nodes costs $73 a month on a supported version and $438 on an unsupported one. The pricing page is clear that everything else is billed separately: "You also pay for the resources you use to run your applications on Kubernetes worker nodes such as Amazon EC2 instances, Amazon EBS volumes, and public IPv4 addresses, as well as any cross AZ traffic from nodes to the Kubernetes control plane."

That last clause is a charge most people never attribute. Node-to-control-plane traffic crosses zones, and cross-AZ transfer is billed at $0.01 per GB in each direction. The public IPv4 clause is the other one: nodes in public subnets each hold an address at $0.005 an hour. Neither lands under the EKS service name, which is why cluster cost reported from Cost Explorer is always lower than cluster cost in reality.

How long does a Kubernetes version stay in standard support?

Fourteen months, then twelve more in extended support. The EKS Kubernetes version lifecycle page states it as: "A minor version is under standard support in Amazon EKS for the first 14 months after it's released. Once a version is past the end of standard support date, it enters extended support for the next 12 months."

Twenty-six months total. AWS's own worked example on the pricing page prices the whole run: "You pay $0.10 per hour during the first 14 months ... After 14 months, the Kubernetes version transitions to extended support. You now pay $0.60 per hour for the remaining 12 months. During the 26-month period, on average, you will pay $0.33 per hour to run this cluster."

The billing boundary is sharper than the calendar suggests. The same lifecycle page: "Billing for extended support starts at the beginning of the day that the version reaches end of standard support, in the UTC+0 timezone." Not the start of the next billing period. The day.

What happens if you do nothing?

Three things, in this order, and only the third is reversible in the way people expect.

1. Extended support is entered automatically. "Extended support is enabled by default" for "new clusters, and existing clusters". The default is the expensive path.
2. You cannot leave it by changing a setting. The cluster upgrade policy documentation is unambiguous: "Once your cluster has entered extended support, you cannot disable it. To change the version support policy setting, your cluster must be running on a Kubernetes version in standard support." The only exit is upgrading.
3. At the end of extended support AWS upgrades it for you. "If you haven't updated your cluster before the extended support period ends, your cluster is auto-upgraded to the oldest currently supported extended version."

There is a rollback window, and it is short. "Clusters upgraded through in-place upgrade can be rolled back to the previous minor version within 7 days of the upgrade completing", but "Clusters that were automatically upgraded at the end of extended support cannot be rolled back." Letting AWS do the upgrade forfeits the undo.

Which setting controls it?

One property, supportType, with two values, documented as:

Audit it across every cluster in every enabled Region. This is the check we run before anything else on a new account, because it is one API call and it prices a year of inaction:

for region in $(aws ec2 describe-regions --query 'Regions[].RegionName' --output text); do
  for c in $(aws eks list-clusters --region "$region" --query 'clusters[]' --output text); do
    aws eks describe-cluster --region "$region" --name "$c" \
      --query 'cluster.{name:name,version:version,support:upgradePolicy.supportType}' \
      --output text
  done
done

Where you decide to stay on the version, the setting is changed through the documented enable and disable procedure, and the per-version changes you are deferring are listed under standard support versions.

Setting STANDARD is not free of consequence: it trades a bill for an unscheduled upgrade. The honest framing is that it converts a silent cost into a scheduled operational task, which is usually the trade you want, but it is a trade. AWS recommends deciding before the deadline either way: "we strongly recommend enabling the extended support upgrade policy before the end of the standard support period ... Amazon EKS cannot guarantee that the change will take effect if an automatic upgrade has already been initiated."

Which versions are in extended support now?

As of the AWS release calendar, 1.36, 1.35 and 1.34 are in standard support, and 1.33, 1.32 and 1.31 are in extended support. Version 1.33 is the one to check first: it reached end of standard support on 29 July 2026, so any cluster still on it moved to the $0.60 rate that day.

Read the calendar on the AWS page rather than this one before making a decision. AWS notes that "Dates with only a month and a year are approximate and are updated with an exact date when it's known", so the far end of the table moves. That page also publishes an RSS feed of its own source changes, which is the cheapest possible way to be told when the schedule shifts.

How do you spot an extended support cluster in the CUR?

Extended support does not arrive as a new service. It arrives as a different rate on the same cluster-hours, so a month-over-month service total shows a step change with no usage change behind it. Group by usage type rather than by service, the same technique that resolves the EC2 - Other bucket, and compare the effective hourly rate rather than the total.

SELECT line_item_usage_type,
       SUM(line_item_usage_amount)   AS cluster_hours,
       SUM(line_item_unblended_cost) AS cost,
       SUM(line_item_unblended_cost) / NULLIF(SUM(line_item_usage_amount), 0) AS effective_rate
FROM   cur
WHERE  billing_period IN ('2026-06', '2026-07')
  AND  line_item_product_code = 'AmazonEKS'
GROUP  BY 1
ORDER  BY cost DESC;

An effective rate near 0.10 is a supported cluster. Near 0.60 is a cluster costing $365 a month more than the team running it believes. If the cluster does not appear in that query at all, it may not be an EKS cluster in the billing sense: self-managed and Connector-registered clusters carry no control plane fee and no version deadline, which is a saving and a support obligation at the same time.