The first time a platform team hands me a Kubernetes bill, it is almost always the same document: a single enormous EC2 or Compute Engine line, a smaller storage line, a load balancer line, and forty engineers who all believe someone else is responsible for it. The cloud provider bills you for nodes. Your organisation is structured around namespaces and services. Nothing in the invoice connects the two, and no amount of tagging will fix that, because the tag lives on the node and the node is shared.

This is the point in the series where the allocation discipline from Part 5 stops being sufficient on its own. Everywhere else in cloud, the billing boundary and the ownership boundary can be made to line up: one account per team, one tag per resource, one subscription per product. Kubernetes was built specifically to break that alignment. Its entire value proposition is that many workloads share one pool of machines and the scheduler decides who lands where. The efficiency you bought is exactly the thing that destroyed your cost attribution.

Why a cluster bill has no team names on it

Start with the vocabulary, because half the confusion in these conversations is people using the same words for different things. A cluster is a group of machines managed together. Each machine is a node, and the node is what your cloud provider charges you for. A pod is the smallest unit Kubernetes schedules, usually one or a few containers that run together. A namespace is a logical partition inside the cluster, and in most organisations it is the closest thing to a team boundary. The control plane is the management layer that decides which pod runs on which node, and on a managed service you pay a separate fee for it.

Now put those together and the problem is obvious. Your provider bills the node. The node hosts pods from six namespaces belonging to four teams, and the mix changes every time something is redeployed or the cluster autoscaler adds capacity. The billing record has no idea any of that happened. To get from a node invoice to a team invoice you need a second dataset, generated inside the cluster, that records which containers held which resources for how long. Then you multiply that record by the node price and you have an allocation. There is no shortcut and no tag that skips this step.

The reassuring part is that you do not have to invent the method. OpenCost, a CNCF project, publishes a vendor neutral specification for exactly this calculation, and it is the closest thing the industry has to an agreed answer. Every commercial Kubernetes cost tool implements some version of it. If you understand the spec, you can evaluate any of those tools in an afternoon and you can also build a rough version yourself from Prometheus metrics you probably already collect. Whether or not you buy something, learn the model first, because the arguments you are about to have with engineering teams are all arguments about the model rather than the tool.

Cluster fees you can read off a price list

Before the hard part, clear the easy part off the table. The managed control plane is the one Kubernetes cost you can look up, and it is usually small. Amazon EKS charges 0.10 USD per cluster per hour while your Kubernetes version is under standard support, which is the first 14 months after a version is released in EKS. After that the version enters extended support for a further 12 months and the fee becomes 0.60 USD per cluster per hour. Google Kubernetes Engine charges a cluster management fee and gives every billing account a monthly credit of 74.40 USD, enough for one free Autopilot or zonal Standard cluster. Azure Kubernetes Service has a Free tier with no cluster management fee and no service level agreement, and Standard and Premium tiers that charge a fee and carry an uptime commitment of 99.95 percent for the API server when the cluster uses availability zones.

EKS figures taken from the Amazon EKS pricing page in July 2026. Annual figures are the hourly rate multiplied by 8,760 hours. GKE and AKS publish their cluster fees on their own pricing pages and rates vary by region, so the exact current number should be read there rather than quoted from here.

Read that table and one number should bother you. Extended support is not a product you buy, it is a penalty you accrue by not upgrading. Nobody approves it, nobody sees a purchase order, and the fee simply appears when a version ages out. On a single cluster it is an extra 4,380 USD a year, which most organisations would never notice. On a fleet of a hundred clusters, which is common in a large platform estate, the same neglect is worth 437,000 USD a year in pure penalty for work that was already on the roadmap.

How a node cost becomes a team cost

The OpenCost specification breaks the problem into three buckets and the whole discipline follows from getting them straight. Total cluster cost equals cluster asset cost plus cluster overhead cost. Asset costs are the things you can observe inside the cluster: nodes, persistent volumes, attached disks, load balancers, network traffic. Overhead costs are what it takes to operate those assets, principally the cluster management fee from the table above. In accounting terms the spec calls assets your cost of goods sold and overhead your general and administrative expense, which is a useful frame when you are explaining this to finance.

Asset costs then split a second way, and this is the distinction most teams miss. Resource allocation costs accrue based on time provisioned regardless of use, such as an hourly rate per CPU core. Resource usage costs accrue per unit consumed, such as a charge per gigabyte egressed. The difference matters because only allocation costs can be idle. A byte you never sent costs nothing, but a core you reserved and never touched costs full price for every hour it sat there.

Distribute the asset costs to tenants and you land on the identity that should be printed on the wall of every platform team: total cluster cost equals workload cost plus cluster idle cost plus cluster overhead cost. Workload cost is what you can attribute to a specific container, pod or deployment. Idle cost is the portion of allocation cost that no workload claimed. Overhead is the management fee. Any Kubernetes cost report that does not show you all three separately is hiding something, and what it is hiding is almost always the idle number.

flowchart TD
  N[Node hourly price] --> R[Resource allocation costs, CPU and memory]
  N --> U[Resource usage costs, egress and requests]
  PV[(Persistent volumes and disks)] --> A[Cluster asset costs]
  R --> A
  U --> A
  F[Cluster management fee] --> O[Cluster overhead costs]
  A --> W[Workload costs, the greater of request and usage]
  A --> I[Cluster idle costs]
  W --> T[Team or product cost line]
  I --> P[Platform budget or proportional split]
  O --> P

Requests are the real currency

Here is the single rule that changes behaviour once engineers understand it. A resource request is the amount of CPU and memory a container asks the scheduler to reserve for it. A resource limit is the ceiling it is allowed to burst to. The scheduler makes its placement decisions on requests, which means requests, not actual consumption, determine how many nodes you need to run.

The specification follows that logic exactly. Workload cost is the greater of requested and used resources, evaluated per container. If a service requests four cores and burns one, it is billed for four, because the other three were reserved by the scheduler and no other pod could have them. If a service requests one core and somehow uses two through burst, it is billed for two. The formula punishes over requesting and refuses to reward under declaring, and it is calculated at the container level precisely because a container is the smallest thing that can reliably be said to have consumed anything.

This is why utilisation dashboards mislead in Kubernetes in a way they do not for plain virtual machines. A team can look at a graph showing their pods at 20 percent CPU and conclude they are running lean, when in fact they requested five times what they need and are being billed for all of it. The number to put in front of them is not utilisation, it is request efficiency: used divided by requested. That single ratio explains most of the difference between a cluster that costs what it should and one that costs three times as much. Notice also how cleanly this connects back to rightsizing in Part 11. In Kubernetes the rightsizing target is not the instance, it is the request in the deployment manifest, and it belongs to the application team rather than the platform team.

Idle cost and who should pay for it

Cluster idle cost is the difference between what the assets cost and what the workloads claimed, and idle percentage is that figure divided by total resource allocation cost. Usage based resources are excluded from the calculation, since a byte that was never transferred never sat idle. It is the most politically charged number in container FinOps because someone has to be charged for it and every candidate has a reasonable objection.

An illustrative 40 node cluster, arithmetic worked from the OpenCost allocation model. The rates are chosen for clean division rather than taken from a live price list.

The spec offers three ways to distribute shared and idle costs: uniformly across tenants, proportionate to each tenant’s consumption of asset costs, or by a custom metric such as bytes egressed. Uniform splitting is the easiest to implement and the hardest to defend, because a small team gets the same bill as one running half the cluster. The custom metric approach is elegant and almost nobody sustains it, since the metric needs maintaining and arguing about forever. Proportional distribution is what most organisations end up on and it is the right default.

But there is a prior question that matters more than the split method: should idle be distributed at all? My answer is that it depends on one thing only, which is whether the teams being charged can actually influence it. If application teams set their own requests and the cluster autoscaler adds and removes nodes in response, then idle is largely a consequence of their requests and charging it proportionally is fair and produces the right pressure. If the platform team fixes the node count, pre warms capacity for traffic spikes, or reserves headroom for failover, then idle is a platform decision and dumping it on application teams just produces a quarterly argument nobody wins.

flowchart TD
  A{Do teams set their own resource requests} -->|No, the platform sets them| B[Idle stays on the platform budget]
  A -->|Yes| C{Does the cluster autoscale on those requests}
  C -->|No, fixed node count| B
  C -->|Yes| D{Is idle above your published target}
  D -->|No| E[Distribute idle proportionally, it is small]
  D -->|Yes| F[Keep idle visible and unallocated this quarter]
  F --> G[Publish request efficiency per namespace]
  G --> H[Distribute idle once teams can act on it]
  E --> I[Revisit the target every quarter]

Costs a cluster hides from your allocation model

Even a correct allocation model misses money if you only feed it nodes. Persistent volumes belong to a pod and follow it around, and orphaned volumes from deleted workloads are one of the most common findings in a first container cost review. Load balancers created by a service object are billed as ordinary cloud resources, sit outside anything Kubernetes reports, and multiply quietly as teams add ingress. Network traffic between availability zones is charged, and the scheduler happily places chatty pods across zones because it optimises for resource fit rather than for your invoice. The Amazon EKS pricing page states the point plainly: alongside instances, volumes and IPv4 addresses, you also pay for cross availability zone traffic from your nodes to the Kubernetes control plane.

Autopilot style managed modes change the shape of this rather than removing it. In the pod based billing model on GKE Autopilot you are charged in one second increments for the CPU, memory and ephemeral storage that your running pods request, with no minimum duration. That is a genuinely better alignment between cost and declaration, and it makes the request the literal unit of billing rather than a proxy for it. It also means a badly set request now costs you directly and immediately, and that Autopilot committed use discounts do not apply to the cluster management fee or to Spot pods, so the commitment planning from Part 12 needs adjusting rather than reusing.

One last detail worth knowing because it produces confusing reports. The OpenCost model does not charge resources allocated to pods stuck in ImagePullBackOff, the state where a container image cannot be fetched. A cluster full of failing deployments will therefore show capacity consumed that no workload is being billed for, which lands in idle and looks like waste. It is waste, but the fix is a broken pipeline rather than a resource request, and it is worth checking before you send anyone a rightsizing recommendation.

Publish request efficiency before you publish a bill

The recommendation for this part is narrow and specific. Deploy something that implements the OpenCost model, whether that is OpenCost itself or a commercial tool built on it, and use it first to publish exactly two numbers per namespace: request efficiency, meaning used divided by requested, and cost of unclaimed capacity for the cluster as a whole. Put both in the weekly report you built in Part 7. Do not allocate a single dollar to a team until those numbers have been visible for a full quarter and the obvious offenders have had a chance to fix themselves.

When you do move to allocation, charge workload cost on the greater of request and usage, keep idle on the platform budget until teams demonstrably control it, and never distribute the cluster management fee, which is too small to be worth the arithmetic. And separately from all of it, put a calendar reminder on your Kubernetes version support dates, because that is the one container cost lever where the saving is certain, the effort is already planned work, and nobody has to be persuaded of anything.

Part 16 turns to serverless and managed service cost, where the allocation problem inverts: the provider hands you per invocation granularity and the difficulty becomes knowing whether that granularity is telling the truth about your unit economics. The allocation foundations came from Part 5, the storage and transfer charges that reappear inside every cluster were covered in Part 14, and every part is indexed on the Cloud FinOps guide.

One thing to do this week: pull the requested and used CPU for your three largest namespaces and calculate the ratio. If any of them is under 40 percent, you have found more money than a month of instance shopping would have produced.

References

• OpenCost Specification, the vendor neutral model for Kubernetes cost allocation
• Amazon EKS pricing, cluster fees and version support tiers
• Google Kubernetes Engine pricing, cluster management fee and free tier credit
• AKS Free, Standard and Premium pricing tiers, Microsoft Learn
• Calculating Container Costs, FinOps Foundation
• Resource requests and limits for pods and containers, Kubernetes documentation

Cluster fees, support windows and billing models were verified against AWS, Google and Microsoft documentation in July 2026 and change over time. The 40 node cluster and the 20,000 USD monthly split are arithmetic worked from the OpenCost model rather than figures from a live account.

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts