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 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.