Kubernetes pod cost is the pod's share of the hourly price of the node it runs on, measured per resource as the greater of its resource requests and its actual usage. No cloud provider bills a pod: AWS, Azure and Google Cloud bill nodes, and only an allocation rule turns a node price into a price per pod. This page describes the rule OpenCost and GKE Autopilot use, what limits and QoS classes change about it, how a node's price is split between CPU and memory, and why the gap between request and usage remains as idle cost. Spreading the result across teams is Kubernetes cost allocation; where the numbers come from is Kubernetes cost data.

How it works

A pod asks for CPU and memory through its resource requests. The scheduler reserves that amount on a node whether the container uses it or not; a node is full once the sum of requests reaches its allocatable capacity. A limit caps what the container may use at most; it reserves nothing. Requests and limits set the QoS class: Guaranteed when every container has a limit equal to its request for both CPU and memory, Burstable when at least one request or limit is set, BestEffort when none is. The class governs eviction under memory pressure and changes nothing about the node's price.

The OpenCost specification defines a workload's cost per resource as max(request, usage): whoever reserves pays the reservation, whoever uses more than requested pays the usage. Limits do not appear in the formula. The specification first prices the cluster's assets (nodes, disks, load balancers), then decomposes each node: workload costs plus idle costs equal asset costs, and with overhead such as the cluster fee the total cost of the cluster.

That needs a price per vCPU-hour and per GiB-hour for the node, which no provider publishes; only the price of the whole machine is public. The specification recommends a fixed ratio between the resource prices, scaled to the node's price. AWS uses a 9:1 ratio between a vCPU-hour and a GB-hour for split cost allocation data, derived from Fargate's prices. The price of one vCPU-hour is then the node price times the CPU weights' share of all weights, divided by the number of vCPUs; memory likewise. The input, per the specification, is the node's fully amortised net cost, not its on-demand list price, when a commitment or a spot price applies to it.

The node's amortised net priceper hour, the only public figureSplit by a fixed weight betweenCPU and memory, scaled to thenode's priceA price per vCPU-hourand per GiB-hourA pod's cost: the greater ofrequest and usage per resource,times that price; limits playno partWorkload costs plus idle equalthe node's cost; with the clusterfee and overhead, the cluster's total
The node's price is split by a fixed weight into vCPU and GiB prices, each pod pays the greater of request and usage, and the remainder is the node's idle

AWS

On Amazon EKS with EC2 nodes the pod price exists only through this calculation; the AWS bill knows the instance alone. Split cost allocation data in the Cost and Usage Report does the calculation, spreading the amortised instance cost by requests or, with metrics from Container Insights or Amazon Managed Service for Prometheus, by the greater of request and usage. On AWS Fargate there is no node: AWS bills each pod's requested vCPU and memory per second, and max(request, usage) collapses to request, because a Fargate pod cannot grow past its requests.

Azure

AKS bills nodes as virtual machines. AKS cost analysis breaks them down by namespace and shows idle, system and service charges separately; the cost per pod comes from the requests.

Google Cloud

GKE Autopilot is the one case where the provider itself bills per pod: CPU, memory and ephemeral storage from the requests of every scheduled pod, per second, with no node price in the general-purpose compute class. Autopilot fills in missing requests and raises small ones to the minimum and the permitted CPU-to-memory ratio. In GKE Standard the node calculation applies, and GKE cost allocation in the billing export spreads by requests.

What it means for your cost

The convention decides which behaviour a team pays for. Under max(request, usage) an oversized request costs money because the reservation is paid, and an undersized request costs money too as soon as usage exceeds it. A team therefore lowers its pod cost only by moving requests towards measured usage. What remains between the sum of the pod costs and the node's price is the node's idle; it belongs to nobody at first, and idle and unallocated cluster cost describes how it is distributed.

the requestthe usageA pod's request againstits measured usageWhich is larger?The reservation is paid:the gap to usage is costfor capacity doing nothingThe usage is paid: the podgrew past what it reservedPod cost falls only when requestsmove towards measured usageWhat remains below the node'sprice is the node's idle,nobody's at first
Under the convention an oversized request pays the reservation and an undersized one the usage, so a team lowers its pod cost only by moving requests towards measured usage

First, BestEffort pods without requests receive zero cost under pure request-based allocation although they occupy capacity; the usage half of max(request, usage) catches that, but needs usage metrics. Second, the pod price is derived from the node price: a cheaper node pool lowers every pod on it, a spot node likewise. Third, limits do not change the price; they only decide whether a container is throttled or killed, and GKE Autopilot bills the request anyway. A price per pod is therefore an allocation rule with a date, not an invoice line.

Where it goes wrong

  • A pod without requests costs nothing. Symptom: a namespace full of pods shows almost no cost. Cause: the pods are BestEffort and the allocation counts requests only; their usage lands in the node's idle.
  • Requests lowered, pod cost unchanged. Symptom: after rightsizing the requests, the sum per pod barely moves. Cause: usage was above the new request, and max(request, usage) now counts the usage.
  • Team totals move with load. Symptom: a team's cost rises during peaks although the node count is flat. Cause: the usage half of the formula follows the peaks; only the split changes, not the bill.
  • Autopilot dearer than the manifest. Symptom: a pod is billed for more vCPU or memory than its manifest declares. Cause: Autopilot raises requests to the minimum and the permitted ratio, and bills pods stuck in error loops too.
  • List price instead of amortised cost. Symptom: the sum of pod costs exceeds what the bill shows for the nodes. Cause: the allocation uses the on-demand price although a Savings Plan or a reservation covers the nodes.

Example

List price read on 2026-10-21 from the AWS price list for Frankfurt (eu-central-1): an m6i.large instance (2 vCPU, 8 GiB) costs USD 0.115 per hour on demand under Linux, USD 83.95 for a 730-hour month. With the AWS 9:1 ratio the 2 vCPU weigh 18 units and the 8 GiB weigh 8, 26 in all. The CPU share is 18/26 × 0.115 = USD 0.0796 per hour, so USD 0.0398 per vCPU-hour; the memory share is 8/26 × 0.115 = USD 0.0354 per hour, so USD 0.00442 per GiB-hour.

A pod requesting 500 millicores and 1 GiB that uses 200 millicores and 600 MiB is valued under max(request, usage) at 0.5 vCPU and 1 GiB: 0.5 × 0.0398 + 1 × 0.00442 = USD 0.0243 per hour, USD 17.76 a month. A second pod requesting 250 millicores and 512 MiB that uses 800 millicores is valued at 0.8 vCPU and 0.5 GiB: 0.8 × 0.0398 + 0.5 × 0.00442 = USD 0.0341 per hour, USD 24.86 a month. Together the two claim USD 0.0584 of the node's USD 0.115 per hour; the remaining USD 0.0566 is idle until more pods fill it. In GKE Autopilot in Frankfurt (europe-west3) the same first pod costs, by the price list read on 2026-10-21, 0.5 × 0.0573 + 1 × 0.0063421 = USD 0.0350 per hour, USD 25.54 a month, with no node and no idle.

Sources

Read on 2026-10-21. OpenCost specification, Kubernetes resource management for pods and containers and pod quality of service classes, AWS split cost allocation data, AWS Fargate pricing, AWS Price List bulk API, offer AmazonEC2, eu-central-1, Microsoft AKS cost analysis, Google Cloud resource requests in Autopilot, GKE cost allocation and GKE pricing.