Kubernetes has solved a real engineering problem: it allows teams to deploy and scale containerized applications efficiently across a shared pool of compute resources. The cost management problem it creates is equally real — and much harder for finance teams: when many applications share the same cluster, the cloud bill shows cluster-level spend, not application-level spend.
An AWS bill might show $120,000/month for EKS node groups. Which applications generated that cost? Which teams own them? Is the cluster being used efficiently, or is it paying for resources that applications reserved but never used? The cloud bill alone cannot answer these questions.
Why Kubernetes costs are hard to see
In a traditional VM-based environment, the cost attribution model is relatively simple: each team runs EC2 instances in their own account or tagged with their name, and the bill tells you what each team spent. Cost flows from resource to owner in a nearly direct line.
Kubernetes breaks this model because multiple teams share the same underlying nodes. A cluster might run services from the payments team, the data platform team, and the customer-facing API team all on the same physical nodes. The EC2 bill shows the total cost of those nodes; Kubernetes itself knows which pods are running but doesn’t attach dollar values to them.
There are two distinct problems here:
The shared infrastructure problem. Node costs are cluster-level, not pod-level. When five teams share a cluster, who pays for the master nodes, the networking infrastructure, the monitoring agents, and the unused capacity that Kubernetes keeps available for autoscaling? These shared costs need to be allocated.
The request vs. actual problem. Kubernetes allows (and requires) applications to declare resource requests — “I need 2 vCPUs and 4 GB RAM.” The underlying node pays for the requested capacity whether it’s actually used or not. A pod that requests 4 GB of RAM and uses 400 MB is still occupying the node capacity it claimed. The efficiency gap between requested and actual resources is often significant and invisible to finance.
The tools for K8s cost visibility
Several approaches exist for attributing Kubernetes costs to teams and applications:
Namespace-based allocation with cost allocation tools. Kubernetes namespaces typically map to teams or products. Tools like Kubecost, OpenCost, or CAST AI can read cluster metrics (resource requests and actual usage by namespace) and allocate node costs proportionally. The result is a cost-per-namespace view that can be rolled up to team or product.
Label-based attribution. Kubernetes labels on deployments and pods can be used to define cost allocation. If every deployment has a team and product label, cost allocation tools can build cost views at that granularity. This requires consistent labeling discipline — the Kubernetes equivalent of cloud resource tagging.
Dedicated node groups per team. For organizations that want simpler attribution without third-party tooling, running separate node groups (or separate clusters) per team trades some efficiency for cost visibility. The EKS node group appears as a distinct resource in AWS Cost Explorer and can be tagged directly. This approach is less compute-efficient than shared clusters but significantly simpler for finance.
Showback or chargeback to namespace owners. Once you have per-namespace cost data, you can publish it as showback (visibility only, no actual budget impact) or chargeback (actual internal billing to the team’s budget). Most organizations start with showback to build familiarity with the numbers before implementing chargeback.
The efficiency metrics that matter to finance
Kubernetes introduces two efficiency gaps that don’t exist in simple VM environments:
Request efficiency — The ratio of actual CPU/memory usage to requested CPU/memory. A cluster with 40% request efficiency is paying for 2.5x the resources it actually needs. This gap is often large in new Kubernetes environments where teams set conservative resource requests and never revisit them.
Node utilization — The percentage of node capacity that’s allocated to pods (not sitting idle for autoscaling headroom). Most Kubernetes clusters run at 60–80% node utilization; the remainder is headroom. This is not waste — it’s necessary for responsive scaling — but it represents cost that should be understood and benchmarked.
Finance questions to ask about Kubernetes clusters:
- What is the average request efficiency for each cluster (actual usage / requested resources)?
- What percentage of cluster cost can be attributed to specific teams or applications?
- What is the cost trend for each namespace quarter-over-quarter?
- Is the cluster appropriately right-sized for actual workload patterns?
What finance should ask engineering to instrument
If your organization runs Kubernetes but doesn’t have per-team cost attribution, the right ask to engineering is:
Deploy an open-source cost attribution tool (OpenCost is free and widely supported) that exposes namespace-level cost metrics. This requires no changes to application code or cluster configuration — it reads existing Kubernetes metrics.
Enforce namespace labeling with team, product, and cost-center labels on all deployments. This creates the attribution data that feeds cost analysis.
Publish a monthly cost report by namespace to team leads and finance. Even a simple spreadsheet that shows each team’s estimated cluster cost by month creates the accountability feedback loop that drives optimization.
The specific tools and implementation will be owned by engineering. Finance’s role is to require that cost attribution exists, to review the output, and to escalate when namespaces represent unallocated or unexplained spend.
CostDefender surfaces EC2 cluster costs and helps finance understand the infrastructure footprint beneath Kubernetes deployments — part of the cloud cost picture that standard billing reports leave out.