The tool above keeps its inputs deliberately short, because a Kubernetes bill is driven by a handful of numbers and only two of them really move it: how many worker nodes you run, and what you pay per node per hour. Everything else adjusts the total by a few percent. Here is what sits behind each input, and where the money usually hides.
What is Kubernetes cost optimization?
Kubernetes cost optimization is closing the gap between what your cluster requests and what your workloads actually use: right-sizing CPU and memory requests, consolidating nodes, moving fault-tolerant work to Spot capacity, and matching storage classes to the data on them. Industry telemetry consistently finds most containers use under half their requested memory — which is why this calculator asks about utilization before anything else.
What actually drives your Kubernetes bill
A Kubernetes cluster is, underneath, a pool of virtual machines. You pay the cloud's ordinary compute rate for every worker node around the clock, whether the pods scheduled on it are busy or idle. That is why the calculator asks for your real cost per node per hour instead of shipping a built-in price: instance rates vary by region and family and change every time a new generation lands, so a hardcoded figure is wrong the day it is written. An m5.xlarge in us-east-1 runs about $0.192/hr today; look yours up and paste it in. If the model itself is new to you, what is Kubernetes covers the concepts first.
The managed control plane is the second, smaller line item. EKS, AKS Standard and GKE Standard each bill roughly $73 a month per cluster for the API server, scheduler and etcd the provider runs for you. On its own it barely registers, but it multiplies: a cluster per team or per environment quietly pays that fee many times over, and so does the overhead that rides on each one. Whether you should pay it at all, or self-host and absorb the operational load instead, is the managed vs self-hosted Kubernetes decision.
Then there is system overhead: the kubelet's own reservations, metrics agents, log shippers, a service mesh, ingress controllers, CSI drivers and admission webhooks all take CPU and memory before your application gets any. Fifteen to twenty percent of node capacity is a normal tax; a heavy mesh or an over-eager observability stack pushes it higher. That is the overhead slider — set it to what your platform team actually reserves.
Two costs the node arithmetic does not capture will still show up on your invoice. Cross-zone and egress traffic is the first: chatty microservices spread across availability zones pay a per-gigabyte rate on every hop, and it hides inside data transfer rather than next to compute. GPUs are the second, and they are a category of their own — a single idle accelerator pool can outweigh the rest of the cluster combined, which is why we treat GPU cost for LLM inference as its own problem.
Why clusters are almost always over-provisioned
The structural reason clusters cost more than they should is that pods request more than they use. A team sets CPU and memory requests high to be safe, the scheduler faithfully reserves that capacity, and nodes fill up on paper while running half-idle in fact. Production clusters at 20 to 35 percent real CPU utilization against 80 percent-plus reserved are ordinary, not exceptional. You pay for the reservation, never the usage.
Layered on top is the quiet stuff: non-production clusters running 24x7 for an eight-hour workday, replica counts set once and never revisited, autoscalers that scale up eagerly and down timidly, and workloads nobody has decommissioned. None of it looks like waste on any single dashboard, which is exactly why it survives budget review after budget review. It is the Kubernetes-shaped version of the same pattern our cloud waste calculator estimates across an entire cloud bill.
The levers that actually cut it
In rough order of payback: right-size pod requests to reflect real usage so the scheduler can bin-pack more pods onto fewer nodes; move anything stateless or fault-tolerant onto spot or preemptible capacity — the single biggest line-item saving, and the one the coverage slider models; consolidate the per-team clusters where control-plane and overhead multipliers are compounding; scale non-production to zero outside working hours; and put cross-zone traffic and GPU scheduling under real scrutiny. On AWS specifically, layering commitment coverage on top of this is covered in AWS cost optimization.
A lot of this cost is baked in during the move onto Kubernetes in the first place; the three we see most often are in three Kubernetes migration mistakes. If you would rather have someone map your cluster spend against real utilization and hand back a ranked list of fixes, that is what our Kubernetes engineering and cloud billing and FinOps work does. Treat the number above as a starting point — the audit replaces it with yours.
How much does an EKS cluster cost per month?
An EKS cluster costs $0.10 per cluster per hour for the managed control plane — $73 a month at the 730-hour month this calculator uses — plus your worker nodes at ordinary EC2 rates. In the worked example above (20 × m5.xlarge, 30% spot, 15% overhead) the cluster lands near $2.7K a month and the control plane is under 3% of it. A cluster left on a Kubernetes version past standard support pays $0.60 per cluster per hour instead.
Two EKS-specific lines to watch. EKS Auto Mode adds a management fee on top of the EC2 instance price, billed per second with a one-minute minimum and varying by instance type, so a fleet on Auto Mode costs more per node-hour than the same fleet on self-managed node groups. And commitments do not touch the cluster fee: AWS applies Compute and EC2 Instance Savings Plans to the EC2 instances inside an EKS cluster, but not to the Amazon EKS charges. Size those commitments with the Reserved Instance and Savings Plan calculator.
How much does a GKE cluster cost per month?
A GKE cluster costs $0.10 per cluster per hour in cluster management fee — about $73 a month at 730 hours — plus nodes billed at Compute Engine rates on Standard, or per-pod vCPU and memory requests on Autopilot. Google credits $74.40 a month per billing account, which makes your first zonal Standard or Autopilot cluster fee-free; regional clusters and every additional cluster pay the fee in full.
The fee is flat regardless of mode, size or topology, so Autopilot is not "free control plane" so much as "one free cluster per billing account" — which is why the calculator zeroes the fee for a single Autopilot cluster and why the second one should be budgeted at $73. Clusters on the Extended release channel that pass the end of standard support pay an additional $0.50 per cluster per hour, $0.60 in total. Google backs the control plane with a 99.95% SLA for Autopilot and regional Standard clusters and 99.5% for zonal Standard, which is the real reason to pay for a regional cluster rather than a zonal one.
How much does an AKS cluster cost per month?
An AKS cluster on the Free tier costs nothing for the control plane; you pay only for the node VMs, disks and load balancers underneath. The Standard tier, which adds a financially backed API-server SLA, is $0.10 per cluster per hour, about $73 a month. Premium adds two-year long-term support at $0.60 per cluster per hour, roughly $438 a month.
Microsoft recommends the Free tier for clusters under ten nodes and non-production use: it carries no financially backed uptime SLA. Standard's SLA is 99.95% API-server availability with availability zones and 99.9% without, which is the tier the calculator models when you pick AKS. The pattern is the same on all three clouds: the control plane is a rounding error on one production cluster and a real line item on the tenth, and whether to run it yourself instead is the managed vs self-hosted question.
EKS vs GKE vs AKS: control-plane pricing at a glance
Vendor list prices, checked August 2026; node, storage and egress charges come on top in every column. Every platform charges the same $0.10 an hour for a supported control plane and six times that for a cluster nobody upgraded, so the cheapest control plane on any cloud is the one on a current Kubernetes version. If upgrades are what your team keeps deferring, that is the part of cluster operations our Kubernetes consulting takes over first.