InfraNullBook a readiness review →

Cost visibility

EKS extended support: the $0.60/hour you may not have budgeted.

EKS extended support is easy to miss in a startup budget because it does not require a new application or a larger node group. The Kubernetes version can be enough to change the control-plane rate. AWS lists standard support at $0.10 per cluster-hour and extended support at $0.60 per cluster-hour. That is six times the control-plane rate, not six times the total cost of running your application.

This article explains the arithmetic, the support calendar and how to decide whether extra time is worth the surcharge. Rates and dates were verified October 7, 2026 against AWS EKS pricing and the AWS Kubernetes version calendar. Always check those sources and your own bill before making a purchasing or upgrade decision.

What you are paying for

An EKS cluster has a managed Kubernetes control plane. Its charge is separate from the worker capacity and services your workloads use. Standard-support pricing is associated with a version in the standard-support period. Extended support keeps an eligible older version supported for a further period at the higher hourly rate.

Standard support lasts about 14 months and is followed by 12 months of extended support. This buys time to prepare, but it does not remove upgrade work. Your application dependencies, Kubernetes API usage, add-ons and nodes still need maintenance. A team that treats the extra year as a reason to ignore compatibility can reach the next deadline with a harder upgrade path.

Support periods are per Kubernetes version. They are not measured from the date you created your cluster. A recently created cluster on an older version does not receive a new full standard-support window. This is why an infrastructure inventory should record the actual version and its calendar dates rather than only cluster age.

The monthly estimate

Use 730 hours as a planning month. At $0.10 per hour, one cluster’s standard-support control plane is $73. At $0.60 per hour, its extended-support control plane is $438. The difference is $365. Five equivalent clusters would have a $1,825 monthly difference if they all move from the standard rate to the extended rate.

The calculation is clusters multiplied by hours multiplied by the applicable rate. A mixed fleet needs a separate calculation for each version group. For example, two standard-support clusters and one extended-support cluster produce a $584 control-plane estimate: $146 plus $438. At the standard rate, all three would total $219, so the difference is $365.

These are estimates, not invoice totals. Actual months have different hour counts, and clusters may exist for only part of a month. Compute instances, storage, networking, taxes and other charges are outside this model. An allocation tool such as OpenCost answers a different question about Kubernetes resource use; it does not erase or replace a control-plane line item.

Which versions need attention now?

As of October 8, 2026, EKS 1.33 is in extended support: standard support ended July 29, 2026, and extended support ends July 29, 2027. EKS 1.34 remains in standard support until December 2, 2026, with extended support ending December 2, 2027. Those dates put two different decisions in front of a team with a mixed fleet.

The supplied calendar baseline also places 1.31 and 1.32 in extended support and 1.35 and 1.36 in standard support. Dates that were not verified for this rebuild are intentionally left as “see AWS calendar” in the calculator. There is no safe reason to invent a date simply to fill a table.

EKS 1.30 needs a distinct warning: its verified extended-support end date was July 23, 2026. It should not be described as currently supported at the extended rate. If an inventory still says 1.30, check the actual cluster state and AWS communications. AWS can automatically upgrade clusters after extended support ends; an old spreadsheet may no longer describe what is running.

Find the entire fleet

Start with accounts and Regions, not the production dashboard alone. Include staging, developer environments, abandoned experiments and clusters provisioned by infrastructure automation. A control plane does not become free because no application workload is using it. Confirm ownership before deleting a cluster; storage, DNS or integrations may still depend on it.

For each cluster, record version, support policy, owner and the intended next step. Compare inventory with billing records so a pricing assumption can be checked against real charges. If spend is unexpectedly high, distinguish the version surcharge from changes in nodes, traffic or storage. Fixing the wrong line item can consume engineering time without changing the cost you intended to address.

Our EKS extended-support calculator lets you model version groups locally in the browser. It does not connect to AWS, infer your support policy or guarantee your bill. Its job is to make the control-plane exposure easy to discuss with the team that owns the cluster.

Decide what the extra time buys

Extended support can be a rational temporary choice when an upgrade blocker is understood. A critical controller might require a tested replacement, or the application team may need to validate a storage path. Compare the surcharge with the work and risk of the change. Record the reason for delaying, the person responsible and a date to revisit it.

A vague “we will upgrade later” is different from a funded plan. The extra period should have an exit criterion: incompatible APIs removed, add-ons tested, capacity ready, or recovery rehearsed. Without that criterion, the surcharge can become normal operating spend while the underlying engineering risk grows.

Also inspect the configured EKS support policy and the implications of reaching a support boundary. Do not assume AWS will preserve an old version forever or that an automatic update will match your preferred maintenance window. The version calendar belongs in the same planning process as other production changes.

Spend the assessment effort before the change

Budget for compatibility testing as well as the support surcharge: a version rollback cannot recover application data or undo every deployment change. Use the upgrade checklist’s recovery limits to define what your exit plan actually covers.

The EKS Production Readiness Review costs $1,500 and is read-only over an agreed one-week scope. It gives your team prioritized findings and a plan you can implement yourself. If you want help with the change, EKS upgrade work is quoted after the review. The objective is a deliberate decision about both engineering effort and recurring spend.

A clear next step

Know what needs attention.
Then decide what to change.

A one-week, read-only EKS Production Readiness Review. $1,500. A prioritized plan your team can use.