Kubernetes idle cost is the part of the node price no workload claims: the nodes run and cost money, but the sum of requests and usage stays below what the nodes provide. A cluster with nodes always has this remainder, because nodes come in whole machines; the only questions are how large it is, who sees it and who is charged for it. This page separates asset idle from idle inside workloads, places system overhead and headroom, describes the three ways of distributing idle across teams, and works through what each way does to a team's number. What belongs to no team afterwards is unallocated cost; the table of which column each provider has for it is in Kubernetes cost allocation.
How it works
The OpenCost specification defines a cluster's idle cost as the part of its resource allocation costs not allocated to any workload, and states two equations: asset costs, the nodes, disks and load balancers, equal workload costs plus idle costs, and total cluster costs equal workload costs plus idle plus overhead such as the cluster fee. Idle can be computed per asset, per cluster and per resource; its share of the whole is the cluster's idle percentage. Only time-based costs have idle; what is billed by usage, say requests to a load balancer, never idles.
Two kinds of idle belong to different people. Asset idle is the capacity of a node no pod requests: allocatable minus the sum of requests, valued at the price per vCPU-hour and per GiB-hour that what a pod costs derives from the node price. It arises from packing waste, from the node autoscaler's minimum sizes and waiting periods, and from headroom kept on purpose; its owner is the cluster operator. Workload idle is the gap between request and usage inside a pod: the pod is valued at its request but uses less. It already sits in the number of the team that set the request, and only that team can lower it. Only asset idle is therefore distributed; workload idle is a question of efficiency (Kubernetes efficiency).
System overhead stays apart from idle: the capacity every node holds back for the kubelet, the container runtime and the operating system, which never becomes allocatable, plus the system pods in kube-system. That is not idle but shared operation and belongs to shared cluster costs. Headroom, capacity kept free on purpose for load peaks, is idle with a purpose; it is kept visible as a line of its own (capacity planning and headroom) and not treated as an accident.
There are three ways to distribute asset idle across teams. No distribution: idle stays a line of its own with the cluster operator, and teams see only what they requested. Proportional: each team carries idle in proportion to its workload cost, which is how the OpenCost API distributes with shareIdle, per resource and optionally per cluster or per node, and how AWS spreads an instance's unused capacity over the pods that ran on it. Even: each team carries the same amount regardless of what it requested. The OpenCost specification names a custom metric, such as network egress, as a third method for shared costs; for idle it rarely makes sense.
AWS
Split cost allocation data spreads an instance's unused capacity proportionally over its pods and shows it in the column split_line_item_unused_cost, apart from the pod's own share, so the distribution stays visible and can be reversed.
Azure
AKS cost analysis shows idle charges per cluster and namespace as a category of its own beside system charges and unallocated charges, and does not distribute them.
Google Cloud
GKE cost allocation writes unrequested node capacity in the billing export under the namespace kube:unallocated and the system reservation under kube:system-overhead; Autopilot has no idle, because it bills requests.
What it means for your cost
The method decides how a team can influence its number. Without distribution, idle is the operator's problem, and only the operator has the levers: node sizes, autoscalers, pools. Proportionally, a team pays more idle when it requests more and sees a reason to lower requests, even though that does not change the idle itself, only its split. Evenly, a small team pays the same amount as a large one, and no team can change its number through requests. Which method applies is an allocation rule with a date; a switch mid-year makes the team numbers incomparable.
In every case idle first stays visible as a line of its own, per cluster and period, before it is distributed. Only that line shows whether it comes from packing waste, minimum sizes or headroom, and only the operator lowers it: smaller or better fitting nodes, consolidation, lower minimum sizes, spot for the part that stays free anyway. Idle distributed across teams leaves the view without leaving the bill.
Where it goes wrong
- Idle distributed, cause invisible. Symptom: no team can say why its number rose. Cause: idle is distributed proportionally without the per-cluster line staying visible beside it.
- Idle share falls, bill does not. Symptom: after raising requests the reported idle drops. Cause: asset idle has turned into workload idle; the nodes and their price are unchanged.
- Headroom reported as waste. Symptom: the idle share is read as the operator's failure. Cause: headroom kept on purpose is not separated from the rest of the idle as its own line.
- System overhead counted as idle. Symptom: the reported idle exceeds what the nodes have free. Cause: the reservation for the kubelet and the operating system is counted although it was never allocatable.
- Team numbers incomparable. Symptom: a team pays twice the idle in June as in May at the same usage. Cause: the distribution method changed, or a team left the cluster and the rest carries its share.
- Usage-billed lines with idle. Symptom: load balancer requests or egress appear as idle. Cause: only time-based costs have idle; usage-based lines belong to shared costs.
Example
List price read on 2026-10-21 from the AWS price list for Frankfurt (eu-central-1): an m6i.xlarge (4 vCPU, 16 GiB) costs USD 0.23 per hour on demand under Linux. With the AWS 9:1 ratio that gives USD 0.0398 per vCPU-hour and USD 0.00442 per GiB-hour (the arithmetic is under what a pod costs).
Three teams share the node. Team A requests 1.5 vCPU and 4 GiB: 1.5 × 0.0398 + 4 × 0.00442 = USD 0.0774 per hour. Teams B and C request 0.5 vCPU and 2 GiB each: USD 0.0287 per hour each. Together USD 0.1349; asset idle is 0.23 − 0.1349 = USD 0.0951 per hour, 41 percent of the node. Without distribution, team A pays USD 56.50 in a 730-hour month and the idle line reads USD 69.42. Distributed evenly, each team carries USD 0.0317 per hour more: team A USD 79.65, team B USD 44.14. Proportionally, team A carries 0.0774/0.1349 = 57 percent of the idle: 0.0774 + 0.0546 = USD 0.1320 per hour, USD 96.36 a month; team B 0.0287 + 0.0203 = USD 0.0490, USD 35.77 a month. Same bill, same requests: team B's number lands anywhere between USD 20.95 and USD 44.14 depending on the method.
Sources
Read on 2026-10-21. OpenCost specification and OpenCost API, AWS split cost allocation data, Microsoft AKS cost analysis, Google Cloud GKE cost allocation, Kubernetes reserving compute resources for system daemons, AWS Price List bulk API, offer AmazonEC2, eu-central-1.