AWS costs: EKS control plane - $73/month before one pod runs

An Amazon EKS (Amazon Elastic Kubernetes Service) cluster costs $0.10 per cluster per hour for the control plane — about $73 a month — and that meter starts the moment you click "Create cluster," not when you deploy your first pod. You can spin up a cluster on a Friday afternoon, forget about it over a long weekend, and owe AWS for a Kubernetes control plane that has never once scheduled a container. The part almost nobody expects: this fee has nothing to do with usage. It doesn't scale with traffic, nodes, or workloads. It is rent for infrastructure sitting idle, and it runs whether you're using it or not.

What a $146 surprise bill actually looks like

Jake runs a two-location phone repair shop. A vendor building his repair-ticket app talked him into "just spinning up a Kubernetes cluster to see how it feels" before committing to anything. Jake created one test cluster on a Tuesday, decided he didn't like the console layout, created a second one the following week to "start clean," and never deleted the first. Three weeks later his AWS invoice had two line items he didn't recognize, totaling just over $146, for two clusters that had never run a single container between them.

What the control plane actually is, and why it isn't free

Ethan: "Think of Kubernetes as two separate things wearing one name. There's the control plane — the brain that decides what should run where, keeps track of every object in your cluster, and answers every kubectl command you type. And there are the worker nodes — the actual machines your containers run on. When you self-host Kubernetes, you build and patch that brain yourself: the API servers, etcd, the scheduler, all of it. It's arguably the most annoying part of running Kubernetes at all."

Amazon EKS is a managed service that lets you run Kubernetes applications without managing, securing, or scaling that control plane yourself. AWS runs the API server nodes and the etcd cluster for you, in a control plane that's dedicated to your account — not shared with other customers. That's what the $0.10 hourly fee buys: a highly-available, single-tenant Kubernetes brain that AWS patches, scales, and keeps online, independent of whether you've deployed anything to it yet.

Jake: "So even an empty cluster still needs three API servers running somewhere, being paid for by somebody."

Ethan: "Exactly. And 'somebody' is you, the second you hit create."

The two support tiers that decide your bill

Every EKS cluster has a per-cluster, per-hour fee based on the Kubernetes version it's running. A Kubernetes minor version is under standard support in EKS for the first 14 months after it's released, then automatically enters extended support for the next 12 months, letting you stay on that version longer at extra cost.

Standard support: $0.10/hour

This is the rate everyone quotes, and it's the one that applies as long as your cluster's Kubernetes minor version is within its first 14 months on EKS. $0.10 per cluster per hour works out to roughly $73 a month, or about $876 a year, per cluster — not per node, not per namespace. A cluster running three worker nodes and a cluster running three hundred worker nodes pay the identical control plane fee.

Extended support: $0.60/hour

Once a version passes 14 months on EKS, it moves into extended support automatically — this is enabled by default for all new and existing clusters unless you turn it off. Extended support costs $0.60 per cluster per hour, which is described as the $0.10 standard rate plus an additional $0.50 per cluster per hour. That's roughly $438 a month, a 6x jump from what you were paying the day before.

AWS's own worked example makes the average cost of ignoring an upgrade concrete: create a cluster the day a version is released, run it untouched for 26 months, and you'll pay $0.10/hour for the first 14 months and $0.60/hour for the remaining 12 — an average of $0.33 per cluster per hour across the full period. Staying current isn't just a security hygiene thing here; it's the single biggest lever on this particular line item.

Which Kubernetes version is your cluster on, and does it matter

As of this writing, the Kubernetes versions currently in standard support on EKS are 1.36, 1.35, and 1.34. Versions 1.33, 1.32, and 1.31 are in extended support — meaning any cluster still on one of those is already paying the $0.60/hour rate unless someone disabled extended support and let it auto-upgrade instead. The community releases a new Kubernetes minor version roughly once every four months, and EKS follows that upstream release and deprecation cycle, which is why the standard-support window keeps sliding forward under you if nobody's watching it.

You can check exactly where your own cluster sits with one command, run from a terminal with the AWS CLI installed and configured:

aws eks describe-cluster-versions

The JSON response includes an endOfStandardSupportDate field for each version and a status field that reads either STANDARD_SUPPORT or EXTENDED_SUPPORT. If you'd rather check inside the console, the same information is visible on the cluster's overview page under its Kubernetes version.

Everything that gets added on top of the base fee

The $73/month figure is the floor, not the ceiling. AWS added several optional layers to EKS pricing that stack on top of the base control plane fee, and each one is easy to enable without fully clocking what it costs.

EKS Provisioned Control Plane

This lets you pre-provision extra control plane capacity for demanding workloads — traffic spikes, very large clusters, or unpredictable bursts — instead of relying on the standard control plane's automatic scaling. It's billed hourly per scaling tier, in addition to your standard cluster fee, and you can switch tiers or drop back to standard at any time.

EKS Auto Mode

Auto Mode extends AWS management beyond the control plane to the worker node infrastructure itself — provisioning, scaling, and patching EC2 instances for you. You pay a per-second Auto Mode management charge on top of the regular EC2 instance price for every instance it launches. In AWS's own worked example, a mixed fleet of instances running $1,046.82/month in plain EC2 costs came out to an additional $125.62/month in Auto Mode charges — roughly a 12% surcharge on the compute itself. If you plan to run more than 150 Auto Mode nodes across your organization, AWS asks you to contact your account team for pricing, since standard rates stop applying past that point.

EKS Capabilities

Capabilities are managed integrations — currently Argo CD, AWS Controllers for Kubernetes (ACK), and Kubernetes Resource Orchestrator (KRO) — that run on AWS-owned infrastructure instead of inside your cluster. Each has two billing components: a base hourly rate just for having it switched on, and a per-resource hourly usage charge. In AWS's example covering 100 Argo CD applications, 1,000 ACK resources, and 1,000 KRO resource instances, all three together came to $211.70 a month — on top of the control plane fee, compute, and networking, for what's essentially GitOps tooling overhead.

EKS Hybrid Nodes

If you're extending EKS management to on-premises or edge hardware, Hybrid Nodes are billed per vCPU per hour, tiered by aggregate monthly usage — starting at $0.020 per vCPU-hour for the first 576,000 monthly vCPU-hours and stepping down from there as usage climbs. Billing starts the moment a node joins the cluster and stops the moment it's removed. Crucially, the $73/month control plane fee still applies on top of the Hybrid Nodes charge — it's a separate line item, not something Hybrid Nodes replaces.

The costs that actually dwarf the control plane fee

Ethan: "Here's the thing people get backwards: the $73 is the part everyone worries about, but it's usually the smallest number on the whole bill once you actually deploy something."

The control plane fee only covers the managed brain. You pay separately for every AWS resource your worker nodes and Kubernetes objects consume:

EC2 or Fargate compute

If you're running managed or self-managed node groups on EC2, you pay standard EC2 instance pricing for every worker node, plus EBS volume pricing for their storage. If you're using Fargate instead, pricing is calculated from the vCPU and memory resources used, starting from the moment you begin downloading your container image until the pod terminates, rounded up to the nearest second, with a one-minute minimum charge.

Public IPv4 addresses

Every in-use or idle public IPv4 address attached to your AWS account is billed at $0.005 per hour, whether it's actually doing anything or not. AWS explicitly names EKS worker nodes as one of the resource types this applies to. On its own that sounds trivial — about $3.60 a month per address — but a cluster with a handful of public-facing nodes, a couple of load balancers, and some idle Elastic IPs left over from earlier testing can quietly add $20–$40 a month that never shows up as an "EKS" line item on the bill.

NAT gateways

If your worker nodes sit in private subnets and reach the internet through a NAT gateway, that gateway is billed at $0.045 per hour it's provisioned, plus $0.045 per gigabyte of data it processes, on top of standard EC2 data transfer charges. A NAT gateway running continuously for a month costs roughly $32 in hourly charges alone, before a single byte of data processing is added on top.

Cross-AZ and load balancer traffic

Data sent between resources in different Availability Zones within the same region — including traffic between your nodes and the EKS control plane, or across a VPC peering connection — is charged at $0.01 per gigabyte in each direction. It's a small per-gigabyte number, but it's one more meter running continuously alongside the control plane fee.

How to actually stop the meter

Deleting an EKS cluster stops its control plane charges, but the order you do it in matters, and skipping steps is exactly how people end up with a "deleted" cluster that keeps generating charges from resources it left behind.

1. Delete Kubernetes-created services first. If you created any Kubernetes Service resources of type LoadBalancer, or Ingress resources through a controller like the AWS Load Balancer Controller, delete those from inside the cluster before touching the cluster itself. These provision real Classic, Network, or Application Load Balancers in your VPC that AWS doesn't automatically clean up if the cluster disappears first.
2. Delete managed node groups and Fargate profiles. A cluster can't be deleted while it still has managed node groups or Fargate profiles attached — AWS's own delete-cluster API will reject the request until those are gone.
3. Delete the cluster itself, using the same tool you used to create it — console, eksctl, or the AWS CLI's aws eks delete-cluster --name your-cluster-name — so any tooling-specific cleanup (like CloudFormation stacks eksctl creates) gets torn down alongside it.
4. Confirm it's gone, then audit what's left. A cluster in the DELETING state isn't billed while it's deleting, but once it's fully gone, check your VPC for orphaned load balancers, NAT gateways, EBS volumes, and Elastic IPs that Kubernetes provisioned on your behalf but that don't get removed automatically if you deleted things out of order.

That last step is where most leftover charges actually hide. A load balancer or NAT gateway created by a controller running inside the cluster is a real, independent AWS resource once it exists — deleting the cluster that spawned it doesn't retroactively delete it too.

Cheaper ways to run EKS without losing the managed control plane

Jake: "So is there a version of this where I don't just eat $73 a cluster forever?"

Ethan: "A few, but none of them make the control plane free. They just stop you paying for control planes you don't need."

Consolidate clusters instead of multiplying them

Every EKS cluster carries its own $73/month floor, regardless of size. Ten small clusters — one per team, or one per environment — cost $730 a month before any compute runs, purely from the cluster fee stacking. Kubernetes namespaces and IAM policies exist specifically so multiple applications, teams, or environments can safely share a single cluster instead of each getting its own control plane.

Stay on standard support deliberately

Since extended support is enabled by default, a cluster you simply forget to upgrade will silently start costing 6x more the day it crosses the 14-month mark. If your team can't commit to proactive upgrades, disabling extended support means an aging cluster gets auto-upgraded to a newer version at the end of standard support instead of quietly moving into the expensive tier — a cluster running an unfamiliar new version is a smaller problem than one racking up $438/month unnoticed.

Use Gateway VPC endpoints instead of routing everything through NAT

Traffic to Amazon S3 or DynamoDB that would otherwise flow through a NAT gateway — and get billed for both the hourly charge and the per-gigabyte data processing charge — can instead route through a Gateway-type VPC endpoint, which has no hourly or data processing charges of its own.

Delete unused Elastic IPs and idle clusters on a schedule

Both idle public IPv4 addresses and idle clusters bill at the same rate as ones in active use — there's no discount for "not doing anything with it." A habit of reviewing and removing dev or test clusters and unattached Elastic IPs at the end of each sprint is one of the simplest ways to keep this category of spend from creeping.

Setting up a budget alert so this never surprises you again

AWS Budgets is the tool built specifically to catch this: it lets you set a spending or usage threshold and get notified when you exceed it, or when you're forecasted to. Monitoring and notifications are free of charge; you only pay if you go further and add automated budget actions.

1. Open Billing and Cost Management, then Budgets. This is where every budget you create lives, alongside a Cost Explorer graph AWS builds automatically to show your current spend.
2. Choose "Create budget" and pick a template. The "Monthly cost budget" template is the recommended starting point for exactly this situation — it notifies you if you exceed, or are forecasted to exceed, a monthly amount you set. A "Zero spend budget" template is also worth knowing about if you want to be told the moment any charge appears on an account that's supposed to be idle.
3. Set your threshold and where alerts should go. Notifications can be tied to actual spend or forecasted spend, and sent by email or through an Amazon SNS topic.
4. Understand the lag before you rely on it. AWS Budgets data updates up to three times a day, typically 8–12 hours after the previous update, so there's a real delay between a charge landing and a notification reaching you — this is a monitoring safety net, not a hard spending cap.

Is EKS ever worth $73/month over ECS?

Amazon ECS is AWS's own container orchestrator, and unlike EKS, there's no separate per-cluster control plane fee for it — you pay for the EC2 instances or Fargate resources your tasks consume, and nothing extra for ECS itself. That makes the comparison genuinely simple on price: for a workload that doesn't need Kubernetes specifically, ECS is cheaper by exactly the amount of the EKS control plane fee, every month, for as long as the cluster exists.

What that $73 buys you over ECS is portability and the Kubernetes ecosystem itself — the same manifests, the same Helm charts, the same tooling that works on any other Kubernetes cluster, on any cloud. If your team already runs Kubernetes elsewhere, needs multi-cloud portability, or depends on Kubernetes-specific tooling that doesn't have an ECS equivalent, the fee buys real, specific value. If none of that applies and you just need containers running reliably on AWS, the honest answer is that ECS gets you there without this particular line item at all.

Edge cases: Outposts, hybrid environments, and multi-cluster setups

EKS local clusters on AWS Outposts carry the same standard-support cluster fee as any other EKS cluster, but they don't have an extended-support option at all — and importantly, this cluster fee is billed separately from, and is not included in, your Outposts capacity pricing. If you're running on Outposts and budgeting only against the Outposts invoice, the EKS cluster fee is easy to miss entirely.

For hybrid environments using EKS Hybrid Nodes to bring on-premises or edge hardware into an EKS cluster, remember the vCPU-hour charges for the hybrid nodes are additional to, not instead of, the standard control plane fee — AWS's own worked examples for both a data-center use case and a 50-site edge deployment show the $73-per-cluster figure baked directly into the total, alongside the per-vCPU hybrid node charges.

And for teams running several environments — dev, staging, production — on separate clusters, it's worth doing the multiplication explicitly rather than mentally: three clusters at $73/month each is $219/month in control plane fees alone, before any of the environments has a single workload deployed to it. That number only grows as teams spin up more environments, more regions, or per-feature preview clusters without a habit of tearing them back down.

There's no free tier for this one

Jake: "Is there a free-tier version of this, like the EC2 free hours?"

Ethan: "No, and I'd rather tell you that plainly than have you go looking for it and waste an afternoon. AWS's own EKS pricing page describes the service as having no minimum fees and no upfront commitments — but it never describes any free allotment of control plane hours, the way EC2 or S3 have historical free-tier hours or storage. If you create an EKS cluster, the meter starts. There's no way around that specific fee short of not creating the cluster, or deleting it when you're done."

That's a limitation worth sitting with before you create a cluster just to experiment. If you want to learn Kubernetes fundamentals without paying anything, tools that run a local, single-node Kubernetes cluster on your own laptop — entirely outside of AWS — will teach you the same concepts without a bill attached at all. Save the real EKS cluster for when you actually need AWS's managed infrastructure behind it.

Frequently asked questions

Does Amazon EKS have a free tier?

No. There's no free allotment of control plane hours for EKS the way EC2 or S3 offer free-tier usage. The $0.10 per cluster per hour standard rate applies from the moment you create a cluster.

Am I charged for an EKS cluster if no pods are running?

Yes. The control plane fee is charged for as long as the cluster exists, regardless of whether it's scheduling any pods, running any nodes, or serving any traffic. It's billed per cluster per hour, not per workload.

Is the $0.10 hourly fee per cluster or per node?

Per cluster. A cluster with three worker nodes and a cluster with three hundred worker nodes pay the exact same control plane fee — the node count has no bearing on this particular charge.

What happens if I never upgrade my cluster's Kubernetes version?

After 14 months on a version, your cluster automatically moves into extended support at $0.60 per cluster per hour unless you've disabled extended support. After a further 12 months (26 months total), the control plane is auto-upgraded to the next supported version, potentially at any time and without advance notice.

Can I avoid extended-support charges entirely?

Yes, by upgrading your cluster to a version that's still in standard support before it ages out. Alternatively, you can disable extended support, which means an aging cluster gets auto-upgraded at the end of standard support instead of moving into the paid extended tier — trading a version jump for avoiding the 6x cost increase.

How much do worker nodes cost on top of the control plane fee?

That depends entirely on the instance types and count you run. On EC2, you pay standard on-demand, reserved, or spot pricing for every node plus its EBS storage. On Fargate, you pay per vCPU and memory-second consumed by each pod, from image download until pod termination.

Is Fargate cheaper than EC2 nodes for EKS?

It depends on your workload's shape. Fargate bills per pod, per second, with no idle capacity to pay for, which suits spiky or infrequent workloads well. EC2 nodes are billed whether they're fully utilized or mostly idle, but can be far cheaper per unit of compute at steady, predictable utilization, especially with reserved pricing or savings plans.

How do I make sure a deleted cluster actually stops billing me?

Delete any Kubernetes-created load balancers and Ingress resources first, then delete managed node groups or Fargate profiles, then delete the cluster itself with the same tool you created it with, and finally audit your VPC for orphaned load balancers, NAT gateways, EBS volumes, and Elastic IPs the cluster left behind.

Why am I still being billed after I deleted my EKS cluster?

Almost always because a resource the cluster created — most commonly a load balancer from a Kubernetes Service or Ingress, or a NAT gateway — wasn't deleted before the cluster was, and it's now an orphaned, independent AWS resource still generating its own charges.

Does EKS Auto Mode cost more than managing nodes myself?

Yes, by design — it adds a management fee on top of your regular EC2 instance costs, which in AWS's own example worked out to roughly 12% of the underlying compute spend. What you get in exchange is AWS handling node provisioning, scaling, and patching that you'd otherwise manage yourself.

What's the cheapest way to run a small dev or test EKS cluster?

Share one cluster across dev and test workloads using namespaces instead of separate clusters per environment, use Fargate or a small number of spot EC2 nodes for the compute, route S3/DynamoDB traffic through free Gateway VPC endpoints instead of a NAT gateway, and delete the cluster entirely when it's not actively in use rather than leaving it idle.

Is ECS cheaper than EKS?

For the orchestrator itself, yes — ECS has no separate per-cluster control plane fee, while EKS charges $0.10–$0.60 per cluster per hour regardless of workload. The compute, storage, and networking costs underneath either service are otherwise comparable.

Do I pay separately for load balancers EKS creates?

Yes. A load balancer provisioned by a Kubernetes Service or Ingress resource is a real, independent Elastic Load Balancing resource, billed under standard ELB pricing, entirely separate from the EKS control plane fee.

How much do public IPv4 addresses on EKS nodes cost?

$0.005 per hour for each in-use or idle public IPv4 address associated with your account, which works out to roughly $3.60 per address per month. AWS explicitly includes EKS worker nodes among the resource types this charge applies to.

What is EKS Provisioned Control Plane, and do I need it?

It's an optional add-on that reserves dedicated control plane capacity, priced per scaling tier from $1.65 to $13.90 per cluster per hour on top of the standard fee. Most clusters don't need it — it exists for demanding workloads with predictable traffic spikes or very large-scale clusters where the standard control plane's automatic scaling isn't enough.

How can I get alerted before EKS costs spike?

Set up an AWS Budgets monthly cost budget, or a zero-spend budget on accounts that should have no activity at all. Monitoring and email or SNS notifications are free; just be aware budget data updates only a few times a day, so there's a real lag between a charge occurring and an alert reaching you.

Also Read:

• AWS costs: S3 request pricing - when storage is cheap but touching it is not
• AWS costs: S3 storage classes decided honestly - IA, Glacier, Intelligent-Tiering
• AWS costs: Glacier retrieval - the bill for wanting your data back
• AWS costs: RDS vs Aurora pricing - a small app, both ways
• AWS costs: DynamoDB on-demand vs provisioned - the crossover math
• AWS costs: ECS on EC2 vs Fargate - the real hourly difference

Revision note. Written September 2026, covering Amazon EKS's current control plane, extended support, Auto Mode, Provisioned Control Plane, Capabilities, and Hybrid Nodes pricing, along with the Kubernetes versions currently in standard and extended support on EKS. This will need updating whenever AWS moves the standard-support price point, changes which Kubernetes versions are current, or adjusts the extended-support surcharge. If you're staring at an AWS invoice you didn't expect right now, you're not the first person this has happened to, and it's fixable — take a breath, work through the checklist above, and it'll stop.Happy learning, see you on next post.!