The number everyone remembers about EKS is $0.10 per hour. That’s the control plane fee AWS puts on the pricing page, it works out to about $73 a month, and it sounds almost free for a managed Kubernetes control plane. So people sign off on EKS expecting the cluster to cost the price of the EC2 nodes plus a rounding error.
Then the bill arrives and the cluster line alone is six times what they budgeted, before a single pod ran.
The $0.10/hr number isn’t wrong. It’s just one line item out of six or seven that EKS can charge in 2026, and the expensive ones are the ones nobody mentions until you’re already paying them. AWS shipped a pile of new billing dimensions in late 2025 — Provisioned Control Plane, managed Capabilities, Auto Mode surcharges — and the extended-support clock keeps quietly flipping clusters from $73 to $438 a month. Here’s every line item, what triggers it, and where the money actually leaks.
The advertised price versus the real bill
Strip it down and an EKS bill in 2026 has up to seven moving parts:
- The cluster (control plane) fee — standard or extended support
- Optional Provisioned Control Plane capacity
- Optional Capabilities (managed Argo CD, ACK, KRO)
- The EC2 or Fargate compute running your pods
- An Auto Mode management surcharge, if you use Auto Mode
- Data transfer and NAT gateway egress
- Load balancers fronting your services
Only the first one shows up in most people’s mental model. The advertised $0.10/hr covers the control plane and nothing else — not the nodes, not the networking, not the add-ons. Everything below the control plane is yours to pay for, and a couple of those lines can dwarf the control plane itself.
Let me go line by line, starting with the one that bites hardest.
Control plane: $73/mo until the EOL clock flips you to $438
A Kubernetes version gets 14 months of standard support in EKS from the day AWS releases it. During that window the control plane costs $0.10/hr — call it $73/mo per cluster.
When standard support ends, the version doesn’t get cut off. It rolls into a 12-month extended support window so you can keep running it. That convenience costs $0.60/hr. Same control plane, same cluster, six times the price — roughly $438/mo, every month, until you upgrade off the old version.
This is the single most common surprise on an EKS bill, and it’s brutal precisely because nothing changes on your end. You don’t add capacity. You don’t flip a setting. A date passes, AWS moves the version into extended support, and the per-cluster rate quintuples automatically. A team running 20 clusters that all drift past EOL together goes from about $1,460/mo to roughly $8,760/mo in control-plane fees alone — for clusters that are doing exactly what they did the month before.
The trap is that Kubernetes versions age fast. AWS ships a new minor version every few months, and 14 months of standard support sounds like plenty until you remember how upgrades actually go: someone has to test the workloads, fix the deprecated APIs, schedule the maintenance window, and nobody owns it. So clusters sit. The version goes EOL. The charge flips. And because $438/mo is buried in a Cost Explorer line that still just says “EKS,” it can run for quarters before anyone notices.
If you take one thing from this post: put your cluster Kubernetes versions on a calendar with their standard-support end dates, and treat the upgrade as a cost deadline, not a maintenance nice-to-have. Every month a cluster sits in extended support is $365 you set on fire versus the standard rate.
Auto Mode: the ~12% EC2 surcharge your Savings Plan won’t touch
EKS Auto Mode is AWS’s “we’ll run the data plane for you” option — it provisions, scales, and patches nodes so you don’t manage Karpenter, AMIs, or node groups yourself. It’s genuinely convenient. It also adds a management fee on top of every EC2 instance it launches.
That fee runs roughly 10–12% of the instance’s On-Demand price, depending on instance type, and it shows up as its own line item billed per second with a one-minute minimum. So a node that costs $1.00/hr On-Demand costs about $1.12/hr under Auto Mode.
Here’s the part that quietly wrecks the math. Savings Plans and Reserved Instances discount the EC2 instance portion — that’s their whole job. They do not discount the Auto Mode management fee. That fee is always charged at the On-Demand rate, no matter how deep your compute commitment goes.
Picture a team with a three-year Compute Savings Plan pulling ~40% off their EC2 bill. They turn on Auto Mode expecting the surcharge to ride along with the discount. It doesn’t. The 12% is calculated against full On-Demand pricing on instances they’re otherwise paying 60 cents on the dollar for, so the effective surcharge against their discounted compute is closer to 20%. On a $50,000/mo compute bill, that’s a $6,000/mo line that no amount of Savings Plan coverage will shrink.
Auto Mode can still be worth it — running Karpenter and node lifecycle yourself isn’t free either, it just costs engineer-hours instead of dollars. But price it honestly: the surcharge is calculated on undiscounted compute, and it’s permanent for as long as Auto Mode is on.
The new 2025 billing dimensions nobody budgeted for
At re:Invent-season 2025, AWS made two new families of EKS charges generally available. If you spun up your cluster before late 2025, these weren’t on the pricing page you read. They are now.
Provisioned Control Plane reserves dedicated control plane capacity instead of the shared, auto-scaling default. It’s an add-on, not a replacement — you pay the standard $0.10/hr cluster fee plus the provisioned tier on top. The tiers run XL at $1.65/hr, 2XL at $3.40/hr, 4XL at $6.90/hr, and 8XL at $13.90/hr. That 8XL tier is about $10,000/mo for the control plane alone.
You’d reach for this if you’re hammering the Kubernetes API — large AI/ML training fleets, multi-tenant SaaS with thousands of namespaces, anything where control-plane throttling actually hurts. For a normal web app it’s pure waste, and the danger is someone enabling it “to be safe” and adding a four-figure monthly line for headroom they’ll never use.
Capabilities are managed integrations that run on AWS-owned infrastructure so you don’t operate them yourself: Argo CD, ACK (AWS Controllers for Kubernetes), and KRO (Kubernetes Resource Orchestrator). Each has two-part billing — a base hourly rate just for being enabled, plus a per-resource usage charge:
- Argo CD: $0.02771/hr base ($20/mo) plus $0.00136 per Application per hour
- ACK: $0.004482/hr base plus $0.000045 per AWS resource per hour
- KRO: $0.004482/hr base plus $0.000045 per RGD instance per hour
These are small per unit, which is exactly why they sneak up on you. Managed Argo CD at $20/mo base sounds trivial — until the per-Application fee scales with how many apps you sync. A platform team running Argo CD across 500 Applications is paying the base plus $0.00136 × 500 × 730 ≈ $496/mo on top, for a tool they could self-host on a node they’re already paying for. Whether that’s worth it depends on how much you value not babysitting Argo CD upgrades, but at least now you can do the subtraction.
The networking costs everyone forgets
None of the above is your data plane’s actual traffic, and traffic is where EKS bills get genuinely hard to predict.
NAT gateways are the classic one. Every private-subnet node that pulls images, hits an external API, or talks to an AWS service over the internet routes through a NAT gateway, and you pay both an hourly charge (~$0.045/hr, $32/mo per gateway) and a per-GB data processing fee ($0.045/GB). Run a NAT gateway per AZ across three AZs for high availability and that’s ~$96/mo before a single byte moves. A chatty cluster pulling large container images on every scale-up event can run the per-GB processing into the hundreds per month on its own.
Cross-AZ data transfer is the sneakiest. Traffic between pods in different availability zones costs $0.01/GB in each direction. Kubernetes schedules pods wherever it likes by default, so a service mesh happily shuffling requests across three AZs is paying a cross-AZ tax on internal traffic that never leaves AWS. Topology-aware routing exists to keep traffic in-zone, but it’s off unless you configure it.
Load balancers add up too. Every Service of type LoadBalancer or every Ingress can spin up an ALB or NLB, each with its own hourly charge plus capacity-unit billing. Teams that expose dozens of services without an ingress consolidation strategy end up with a wall of load balancers, each quietly billing $16–25/mo plus usage.
Individually these are small. Together, on a busy multi-AZ cluster, networking and load balancing routinely add up to more than the control plane fee — and unlike the control plane, none of it appears under the “EKS” label in Cost Explorer, so it’s easy to not even attribute it to the cluster.
A cost-cutting checklist that actually moves the bill
Knowing the line items is half of it. Here’s where the money usually is, roughly in order of payoff:
Kill extended support first. Upgrade any cluster sitting in the extended-support window. It’s the highest-leverage move on the list — $365/mo per cluster recovered for a one-time upgrade. Automate version tracking so you never drift past EOL again.
Right-size before you optimize commitments. A Savings Plan on over-provisioned nodes just locks in waste at a discount. Get the node sizing and bin-packing right, then buy commitments against real usage.
Use Spot for anything interruptible. CI runners, batch jobs, dev environments, stateless web tiers with proper disruption budgets — Spot runs 60–90% cheaper than On-Demand. This is the biggest compute lever for most teams.
Price Auto Mode against your discount, not list. If you have heavy RI/Savings Plan coverage, the 12% surcharge on undiscounted compute might cost more than running Karpenter yourself. Do the subtraction before flipping it on.
Audit Capabilities and Provisioned Control Plane usage. These are new enough that they’re often enabled experimentally and forgotten. Anything you’re not actively using is a clean cut.
Fix the networking defaults. Consolidate behind an ingress controller instead of one load balancer per service. Turn on topology-aware routing to kill cross-AZ traffic. Audit NAT gateway data processing — a VPC endpoint for S3 or ECR can route image pulls and AWS API traffic off the NAT path entirely.
And the bigger question worth asking before any of this: should this workload be on EKS at all? For a handful of stateless services with spiky traffic, ECS on Fargate or even Lambda can come out cheaper once you count the control-plane fee, the networking, and the engineer-hours EKS demands. EKS earns its complexity when you have real Kubernetes needs — multi-cloud portability, a large microservice fleet, an existing platform team. For three containers and a database, you’re paying a Kubernetes tax for a problem you don’t have.
If you’re staring at an EKS bill right now, open Cost Explorer, group by usage type, and look specifically for the $0.60/hr control-plane line. That one query has paid for itself more often than any FinOps dashboard I’ve seen.
Pricing figures here reflect AWS’s published US-region rates as of June 2026 — check the official EKS pricing page for current numbers in your region before you budget against them.
Sources: