You went looking for "what does our EKS cluster cost" and the honest answer is that there is no single number to find. AWS Cost Explorer, filtered to Elastic Kubernetes Service, shows you the control-plane fee and nothing else — the EC2 instances or Fargate tasks doing the actual work of running your pods bill under their own service, on their own line, as if they had nothing to do with the cluster sitting on top of them. Add a couple of managed add-ons and some data transfer between availability zones, and "what does EKS cost" turns out to be a question with four or five separate answers that nobody has added together in one place.
What am I actually paying for when I run an EKS cluster?
Three layers, billed three different ways:
- The control plane — the managed Kubernetes API server, etcd, and scheduler AWS runs on your behalf. Billed per cluster, per hour, regardless of load.
- Worker capacity — the EC2 instances in your node groups, or the Fargate tasks running your pods if you use Fargate profiles instead. Billed exactly like EC2 or Fargate anywhere else in your account.
- Add-ons and networking — managed add-ons like the VPC CNI, EBS CSI driver, or CoreDNS run as pods and inherit the compute cost above them, but cross-AZ pod-to-pod traffic and any load balancers you attach add their own charges on top.
The first layer is the one that is unique to EKS and easy to miss, because it exists even before a single pod is scheduled. The other two are priced identically to running the same EC2 instances or Fargate tasks with no orchestrator at all — which is the part worth confirming before you assume Kubernetes itself made your compute more expensive.
What does the control plane cost, exactly?
AWS bills it per cluster, per hour, on top of anything you run inside it:
| What you pay for | Rate | Monthly (730 hrs) |
|---|---|---|
| Standard support (current K8s versions) | $0.10 / cluster-hour | $73.00 |
| Extended support (aged-out K8s versions) | $0.60 / cluster-hour | $438.00 |
These are the published per-cluster hourly rates at the time of writing. AWS changes prices, and extended-support eligibility depends on your Kubernetes minor version's own upstream support timeline — check the Amazon EKS pricing page before you commit to a number.
Two things about this fee catch people off guard. It is per cluster, not per node — a dev, staging, and prod cluster is the $73 (or $438) fee paid three times over, even if dev sits nearly empty most of the week. And it is not optional or reducible by usage — an idle cluster with zero running pods still bills the full hourly rate, because you are paying for the control plane existing, not for what it schedules.
Falling behind on Kubernetes version upgrades is the one lever on this fee that has nothing to do with workload size: once a version ages out of standard support, the same cluster jumps from $0.10 to $0.60 an hour automatically, a six-fold increase for identical usage. If you also run EKS Auto Mode, AWS layers a separate per-second compute charge on top of the underlying EC2 rate for that mode — billed independently of whichever EC2 purchase option (on-demand, Reserved, Savings Plan, or Spot) would otherwise apply — so confirm the Auto Mode line separately if you use it.
What do the worker nodes and pods actually cost?
This is the layer that usually dwarfs the control-plane fee, and it splits by how you run capacity.
EC2 managed node groups bill exactly like any other EC2 fleet — standard on-demand, Reserved Instance, Savings Plan, or Spot pricing for whatever instance type and region you chose, with no EKS premium added anywhere in the calculation. Fargate vs EC2: which is actually cheaper? covers the instance-hour meter in detail if you need the exact rates for your instance family.
Fargate profiles bill per pod, by vCPU-second and GB-second actually consumed, instead of by the node underneath it. At standard us-east-1 on-demand rates for Linux/X86 tasks:
| What you pay for | Rate |
|---|---|
| vCPU | $0.04048 per vCPU-hour |
| Memory | $0.004446 per GB-hour |
AWS's own worked example for EKS pods on Fargate: 10 pods, each 0.25 vCPU and 1 GB, running one hour a day for 30 days in US East (N. Virginia), totals $4.37 for the month. Each pod also gets 20 GB of ephemeral storage included before any extra storage charge applies. That per-pod-second billing is the appeal — a batch job or a low-traffic service that only runs a few hours a day pays for those hours, not for a node sitting warm all month waiting for it.
Fargate and EC2 rates vary by region, CPU architecture, and instance family, and AWS changes them. Check the Fargate pricing page and your account's own EC2 rates before pricing a migration either direction.
How do I find out what's actually driving my EKS bill?
Start with the control plane, since it is the only charge that shows up under the EKS service itself. Confirm which support tier each cluster is in and how much runway it has left:
aws eks describe-cluster --name my-cluster \
--query 'cluster.{Version:version,Status:status,PlatformVersion:platformVersion}' \
--output table
Then split the compute underneath it. In Cost Explorer, group by Usage Type rather than Service — the EKS service line only ever shows EKS-Hours:perCluster; the node and Fargate spend you actually want to see sits under EC2 and AWS Fargate usage types instead, and Cost Explorer will not merge them for you.
To see what is actually running inside a cluster before you go instance-by-instance in the console, list the nodes and their types directly:
kubectl get nodes -o custom-columns=NAME:.metadata.name,TYPE:.metadata.labels.node\\.kubernetes\\.io/instance-type,AGE:.metadata.creationTimestamp
A node group sized for a launch-day peak that never came back looks the same from inside kubectl as it does from the EC2 console: instances that have been running for months at low utilization, still billing the full instance-hour rate regardless of how few pods are actually scheduled onto them.
How do I cut EKS cost without breaking the cluster?
Consolidate clusters where you can. Every additional always-on cluster is another $73–438/month control-plane fee before it runs anything. A dev and staging environment that do not need to be provably identical infrastructure can often share one cluster, split by namespace, instead of paying the control-plane fee twice.
Right-size and autoscale node groups instead of running a fixed count. A managed node group set to a static size pays for that size around the clock. Cluster Autoscaler or Karpenter scale nodes to match actual pod demand, so a fleet that only needs full capacity during business hours is not paying full-capacity EC2 rates overnight and on weekends.
Move bursty or low-utilization workloads to Fargate profiles. A batch job, a cron-triggered task, or a low-traffic internal service that would otherwise justify keeping a warm EC2 node around for a handful of daily hours is usually cheaper billed per-pod-second on Fargate — the arithmetic above is the way to check before you migrate a workload either direction.
Stay current on Kubernetes minor versions. The six-fold jump from standard to extended support is entirely avoidable and has nothing to do with how the cluster is used — it is purely a function of whether upgrades happen on the schedule AWS publishes.
Reducing a node group's size or switching workloads to Fargate removes running capacity, and any
pod without a PodDisruptionBudget can be evicted with no guarantee of a clean shutdown. Set
disruption budgets and confirm graceful termination handles in-flight requests before you change
node group sizing on anything serving live traffic — do this in a maintenance window on a
non-critical service first if you have not done it before.
What else should I check while I'm in here?
The nodes behind an EKS node group are ordinary EC2 instances once you get past the Kubernetes labels, and they accumulate the same waste any EC2 fleet does. A node group provisioned for a traffic spike that never returned is an idle EC2 instance wearing a Kubernetes label; a node group running on a larger instance family than the pods scheduled onto it actually need is an oversized EC2 instance for the same reason a bare EC2 fleet would be. Neither shows up differently in a cost report just because a control plane happens to be scheduling work onto it.
If you are still deciding whether EKS was the right call in the first place, ECS vs EKS: which one costs less to operate breaks down the control-plane fee against ECS's lack of one, and Fargate vs EC2: which is actually cheaper? works through the per-second-versus-per-hour math in more depth than fits here.
More broadly, a container platform is one line among many on an AWS bill, and rarely the biggest one. Our start-to-finish accounting of where an AWS bill actually goes works through the fuller list in order of savings per minute spent.
How do I keep EKS cost from creeping back up?
Pricing one cluster by hand is an afternoon. Doing it for every cluster across every environment — checking which ones are aging into extended support, which node groups are sized for load that left months ago, which workloads would be cheaper on Fargate — is the part that quietly stops happening after launch week. That is what a scan is for. Parsivex checks every region, separates genuinely idle EC2 instances from merely oversized ones, and then keeps watching, so a node group that outgrows its workload does not sit there unnoticed until someone happens to open the bill. For what these findings mean once they show up in your report, see Idle EC2 instance and Oversized EC2 instance.