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, and the region. Kubernetes bills nothing. It schedules pods onto available node capacity and lets you set requests and limits per container. These are two different accounting systems, and nothing reconciles them automatically. The provider bill tells you what the nodes cost. It does not tell you what a given team, namespace, or workload spent. On a shared cluster, people want that second answer.

This is why Kubernetes cost allocation is harder than ordinary cloud cost monitoring. You are billed for a node, by the hour. You care about a workload's fair share of that node. These are not the same unit. Idle capacity hides in the gap between them.

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 on every node each reserve a slice. This happens before the scheduler places a single application pod. What is left after that reservation is allocatable, and it is smaller than capacity. Requested is the sum of the CPU and memory requests of every scheduled pod. It is the amount the scheduler has promised, whether or not a pod touches it. Used is what those pods consume, measured continuously. It is often a fraction of what pods requested.

The bill is paid on capacity: every node, every hour, whether its allocatable slice is fully requested or empty. This is why the calculator exists. Capacity is a fixed cost, whatever the other three numbers are. The gaps between capacity, requested, and used are the buckets the calculator 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. At that point the kubelet throttles CPU or OOM-kills the container. A limit plays no part in scheduling and reserves nothing. Two pods can have identical limits and very different requests. The scheduler places them differently, and only the request changes 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 high limit with no matching request makes a node look fuller than it is to a person reading the manifest. The scheduler sees only the request. Right-sizing that changes what a node can fit means changing requests, not limits.

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

Direct cost is a team's share of what it requested. It is rarely the argument. The argument is the idle pool: cluster idle plus system-reserved capacity. This shared cost has no single owner. Showback reports the number without billing it. Chargeback bills it. Both need a policy to split the pool, and every policy this page models has a downside. No option is neutral.

Proportional splits the idle pool by each team's share of requests. It is the default because it scales with size. It hits the biggest team hardest in dollars, even when the idle is not mostly theirs. Even split divides the idle pool equally, whatever the team size. It is fairer to the biggest team. It can be a rounding error for a large team and a painful line item for the smallest. Platform-absorbs puts the whole idle pool on the platform team's line. Product-team numbers stay clean. But the idle sits in a cost center with no control over product-team request sizes. This hides the incentive to right-size instead of creating one.

None of the three is "correct." The right pick depends on your goal. To change behavior, choose proportional or even split, aimed at the teams that can act on the idle. For a clean chargeback number on product P&Ls, choose platform-absorbs. The cost is that the underlying idle may never get fixed.

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 layer maps spend to an owner inside the cluster. A provider's billing export cannot see it.

This is why a provider bill and an in-cluster allocation view are two systems that do not merge automatically. The provider knows the node's cost. Only a tool inside the cluster knows which workload owns that cost. It reads kubelet and cAdvisor metrics and namespace and label metadata. A consistent labeling convention makes any allocation model point to a real owner instead of a guess. Enforce it at manifest review, not after the fact. That includes the showback table above.

The levers, in the order that pays

Right-size requests first. It is the only lever with no infrastructure risk. On most clusters it is also the biggest bucket. On a cluster that has not been right-sized in a while, workload idle often outweighs cluster idle. To measure that bucket, use the Kubernetes Waste Analyzer instead of the sliders above. It reads your pod manifests and kubectl top output and names the workloads to right-size first. Bin-pack and fix node shape second. Once requests match real usage, a scheduler may still spread pods across too many nodes. Nodes may also have the wrong resource ratio. Both leave cluster idle that right-sizing does not touch.

Autoscaling third. A scale-down delay in the cluster autoscaler or Karpenter can be too long. Nodes then stay up long after load drops. This shows as cluster idle that looks structural but is a slow setting. Spot for the right workloads fourth. Stateless pods that tolerate interruption fit Spot best. Examples are batch jobs, CI runners, and fault-tolerant workers. Moving them off on-demand nodes lets you size the remaining on-demand footprint tighter.

Commitments on the stable floor fifth. Tune requests, packing, and autoscaling first. Then size a Savings Plan or Reserved Instance against the steady-state floor that remains. Do not stop at compute. Storage and egress line items run through the same cluster. They are real costs inside "the cluster", and none of the levers above touch them. 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 appear in the same normalized daily view as every other provider you connect. Anomaly alerts watch cluster cost drift like any other service. This covers the node-level, cross-provider half of the Kubernetes cost problem.

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 showback and chargeback numbers per namespace, computed continuously from live cluster data. For that, use an in-cluster tool such as OpenCost or Kubecost.

How CostMon and Kubecost divide the work →