Why Kubernetes Cost Allocation and Cloud Bills Don’t Match
A few months ago, I found myself looking at a Kubernetes cost report and a cloud invoice side by side. The numbers didn’t match.
Not because of a bug or a calculation error, but because they were answering different questions. Kubernetes cost allocation explains how infrastructure costs should be distributed across namespaces, workloads, and teams. Cloud billing systems explain what was actually charged. Most engineers expect those numbers to be reasonably close. In practice, the gap can be surprisingly large.
The deeper I looked, the more common the problem became.
Shared infrastructure, idle capacity, storage, networking, discounts, commitments, and provider-specific billing models all influence the final invoice. Meanwhile, Kubernetes allocation models focus on resource consumption and ownership. Both perspectives are valuable, but they rarely produce identical results. This creates a challenge for platform teams. Engineering teams use allocation data to identify waste and make optimization decisions. Finance teams rely on billing exports and invoices. Leadership expects a single source of truth. When the numbers don’t align, confidence in cost reporting starts to disappear.
The conversation quickly shifts from: “How much does this workload cost?”
to:
“Why doesn’t our Kubernetes cost report match our cloud bill?”
That question eventually led me to build Burn.
Burn is an open-source Kubernetes FinOps CLI designed to help teams understand cost allocation, identify waste, and investigate the gap between Kubernetes resource consumption and actual cloud billing data.
One of the design goals behind Burn was simplicity.
Most teams do not need another dashboard, another database, or another platform to maintain. Burn runs as a single binary and uses data that teams already have, including Kubernetes metrics from Prometheus and cloud billing exports. The goal is to reduce operational overhead while making cost analysis accessible to engineers.
Beyond allocation, Burn focuses on reconciliation. By comparing Kubernetes resource consumption with cloud billing data, teams can better understand where differences originate and gain confidence in the numbers used for optimization, forecasting, budgeting, and chargeback.
Another lesson I learned is that cost visibility is only useful when it reaches the people who need it. Engineers rarely spend their day inside FinOps dashboards. They already work in Slack, which is why Burn can also be used through Slack workflows, allowing teams to explore costs and investigate spending without leaving their existing collaboration environment.
As Kubernetes environments continue to grow, cost data becomes part of the platform itself. And just like reliability, observability, and security, trust in that data matters.
Because sooner or later, every platform team ends up asking the same question:
Why doesn’t the bill match the report? GitHub: https://github.com/tanrikuluozlem/burn
