Who is actually paying for your idle cluster?

Why the cloud bill can't tell you who spent it

An AWS, GCP, or Azure invoice bills by node: the instance type, the hours it ran, the region it ran in. Kubernetes doesn't bill anything; it schedules pods onto whatever node capacity is available and lets you set requests and limits per container. Those are two different accounting systems layered on top of each other, and nothing reconciles them automatically. The provider bill answers "what did the nodes cost," not "what did any given team, namespace, or workload actually spend." On a shared cluster, that second question is the one everyone actually wants answered.

This is why Kubernetes cost allocation is its own, harder problem than ordinary cloud cost monitoring: the unit you're billed for (a node, by the hour) and the unit you actually care about (a workload's fair share of that node) aren't the same unit, and the gap between them is where idle capacity hides.

Capacity ≠ allocatable ≠ requested ≠ used: the four numbers, and which one you pay for

A node's advertised capacity (say, 8 vCPUs) is never what's schedulable. The kubelet, the container runtime, the OS, and any DaemonSets running on every node all reserve a slice before a single application pod can be placed. What's left after that reservation is allocatable, and it's meaningfully smaller than capacity. From there, requested is the sum of every scheduled pod's CPU/memory requests: the amount the scheduler has promised, whether or not it's ever actually touched. And used is what those pods actually consume, measured continuously, which is very often a fraction of what was requested.

The bill is paid on capacity: every node, every hour, whether its allocatable slice is fully requested or empty. That's the whole reason this calculator exists: capacity is a fixed cost regardless of the other three numbers, and the gaps between capacity, requested, and used are the buckets it splits out below.

Requests vs. limits: the one is a bill, the other is a ceiling

A request is what the scheduler reserves on a pod's behalf. It's the number that determines whether a pod fits on a node at all, and it's the number this calculator's "requested" bucket is built from. A limit is a ceiling: the point at which the kubelet throttles CPU or OOM-kills the container, but it plays no part in scheduling and reserves nothing. Two pods with identical limits and wildly different requests get scheduled completely differently, and only one of them shows up in what a node can still fit.

That distinction matters for this page specifically because it's easy to assume a generous limit is "safe" and stop there. But a limit set high with no corresponding request just makes a node look more full than it is to a human eyeballing the manifest, while the scheduler only ever sees the request. Right-sizing that actually changes what a node can fit means changing requests, not limits.

Who pays for the idle? Showback vs. chargeback, and the honest trade-off of each

Direct cost is a team's share of what's actually requested, and it's rarely the argument. The argument is the idle pool: cluster idle plus system-reserved capacity, the truly shared, unattributable cost nobody's workload specifically caused. Showback (reporting the number without billing it) and chargeback (actually billing it) both have to pick a policy for splitting that pool, and every policy this page models has a real, honest downside. There's no neutral option.

Proportional splits the idle pool by each team's share of requests. It's the default because it scales with size, but it punishes the biggest team hardest in absolute dollars even when the idle isn't disproportionately theirs. Even split divides the idle pool equally regardless of team size, which is fairer to the biggest team but can be a rounding error for a huge team and a painful line item for the smallest one. Platform-absorbs puts the entire idle pool on the platform/infra team's line, which keeps product teams' numbers clean but buries the idle in a cost center that has no lever over the product teams' actual request sizes. It hides the incentive to right-size instead of creating one.

None of the three is "correct": the right pick depends on whether the org wants idle cost to change behavior (proportional or even split, aimed at the teams that can actually act on it) or just wants a clean chargeback number for product P&Ls (platform-absorbs, at the cost of ever fixing the underlying idle).

Showback vs. chargeback, defined →Score your own tag coverage →

Namespaces & labels: the tagging story for containers

Provider cost-allocation tags (an AWS cost allocation tag, a GCP label) live on the node or the resource. They don't know which pod, namespace, or team is running on that node at any given moment, especially once multiple workloads share it. Kubernetes has its own tagging layer: namespace, plus a `team`/`app`/`cost-center` label convention on pods. That's what actually maps spend to an owner inside the cluster, but it lives entirely outside what a provider's billing export can see.

That's the structural reason a provider bill and an in-cluster allocation view are two different systems that don't merge automatically: the provider knows the node's cost; only something reading inside the cluster (kubelet/cAdvisor metrics, namespace and label metadata) knows which workload that cost actually belongs to. A consistent labeling convention, enforced at manifest-review time rather than added after the fact, is what makes any allocation model attributable to a real owner instead of a guess. That includes the showback table above.

The levers, in the order that actually pays

Right-size requests first: it's the only lever with no infrastructure risk, and on most clusters it's also the biggest single bucket (workload idle routinely outweighs cluster idle on a cluster that hasn't been rightsized in a while). Rather than estimate that bucket with the sliders above, the Kubernetes Waste Analyzer reads your actual pod manifests and kubectl top output and names the specific workloads worth right-sizing first. Bin-pack and fix node shape second: once requests reflect real usage, a scheduler that's still spreading pods thin across too many nodes, or nodes shaped for the wrong resource ratio, leaves cluster idle on the table that right-sizing alone won't touch.

Autoscaling third: a cluster-autoscaler or Karpenter scale-down delay tuned too conservatively keeps nodes around long after load drops, which shows up as cluster idle that looks structural but is actually just a slow-to-react setting. Spot for the right workloads fourth: stateless, interruption-tolerant pods (batch, CI runners, fault-tolerant workers) are the cleanest fit for Spot's discount, and moving them off on-demand nodes frees the remaining on-demand footprint to be sized tighter.

Commitments on the stable floor fifth: once requests, packing, and autoscaling are tuned, whatever steady-state floor remains is what a Savings Plan or Reserved Instance should be sized against. And don't stop at compute: the storage and egress line items running through the same cluster are real costs hiding inside "the cluster" that none of the levers above touch. Think persistent volume claims, load balancer data processing, and cross-AZ pod-to-pod traffic.

Find what your own cluster is wasting →Model the commitment break-even →Price the data transfer hiding in your cluster →

What CostMon does (and doesn't do) here

CostMon reads the provider bill: your EKS, GKE, or AKS control-plane fee and node-group spend land in the same normalized daily view as every other provider you connect, with anomaly alerts on cluster cost drift the same way any other service's spend gets watched. That's the node-level, cross-provider half of the Kubernetes cost problem, and it's real coverage, not a teaser for a separate product.

CostMon does not run in-cluster, and it does not do pod- or namespace-level cost allocation. It can't see the requested-vs-used split this calculator models, because that data only exists inside the cluster's own metrics, not on a provider's billing export. That half of the problem needs the actual showback/chargeback numbers per namespace, computed continuously from live cluster data. For that, you want an in-cluster tool built for the job, like OpenCost or Kubecost.

How CostMon and Kubecost divide the work →