Kubernetes monitoring cost model explained

Your cloud provider bills you for node-hours, but your teams consume CPU millicores and memory bytes. They also consume cross-AZ packets. Kubernetes packs workloads from a dozen teams onto shared nodes, so the invoice arrives with no pod, namespace, or team dimension. A CNCF FinOps microsurvey found Kubernetes increased cloud spend for 49% of respondents, with 70% naming overprovisioning as the leading cause (InfoQ). First, define the allocation model and its resource inputs, then examine shared-cost and optimization mechanics. Next, compare the tools and their observability overhead before looking at emerging workloads.

What is a Kubernetes monitoring cost model

A Kubernetes monitoring cost model is the set of rules that translates cluster resource consumption into dollars and attributes those dollars to pods, namespaces, workloads, and teams. Cloud billing cannot do this on its own because its native unit is the node or VM, and every provider's Kubernetes attribution feature carries documented gaps:

• AWS: Split cost allocation data bills at the pod level, but it is available only in the Cost and Usage Report and CUR 2.0, not in Cost Explorer, with up to 24 hours of latency. Pods without resource requests receive no split cost data in the default mode.
• Azure: AKS cost analysis stops at cluster and namespace views. Pod-level and deployment-level views are an open feature request in the AKS GitHub repository.
• GCP: GKE cost allocation appears only in the BigQuery detailed billing export, allocates by resource requests rather than actual consumption, and lags up to 3 days.

None of the three is real-time, and none reconciles in-cluster consumption with what teams used. Cost model tools compensate by joining in-cluster Prometheus metrics with cloud billing exports.

How a Kubernetes cost model works

The core loop samples per-container resource metrics at short intervals and multiplies consumption by the node's unit price. It then aggregates the result upward. The OpenCost specification formalizes this: Total Cluster Costs = Workload Costs + Cluster Idle Costs + Cluster Overhead Costs. OpenCost calculates workload cost at the container level as max(request, usage), then aggregates it. Splitting a node's price between CPU and memory needs a weighting; AWS derives a 9:1 CPU-to-memory ratio from Fargate pricing.

Key cost metrics: CPU, memory, storage, network

The model measures each resource type differently, per the OpenCost specification:

• CPU: The model bills the greater of requested and used cores or millicores.
• Memory: The model bills the greater of requested and used memory, in bytes or gigabytes.
• Storage: The model prices the capacity of persistent volume claim requests.
• Network: The model counts ingress or egress across zones, regions, or the internet, plus load balancer count and connection volume.

Per-pod and per-namespace breakdowns come from aggregation: the OpenCost Allocation API rolls container-level costs up by cluster, node, namespace, controller, service, pod, or any label or annotation.

Requests vs. limits vs. actual usage

Requests reserve capacity at scheduling time. Limits cap what a container can consume at runtime. Usage is what the container actually consumed. The cloud-native allocation paths default to requests: GCP allocates by requests only, and AWS's default measurement mode skips pods with no requests entirely. Because workload cost is the greater of request and usage, an overstated request bills at full price even while the container sits idle, which makes the request-to-usage gap the core input to any cost model.

Idle and over-provisioned resource costs

The request-to-usage gap is where most Kubernetes money goes. CAST AI's 2026 optimization report, drawn from telemetry across tens of thousands of clusters (vendor-stated), measured average CPU utilization at 8% and memory at 20%, with CPU overprovisioning at 69%. Datadog's 2024 State of Cloud Costs (also vendor-stated) found 83% of container costs tied to idle resources: 54% cluster idle plus 29% workload idle.

Sysdig's 2023 usage report adds a dollar estimate: 69% of requested CPU went unused, and organizations with more than 1,000 nodes carried an estimated $10 million per year in reducible waste. One caution when reading these reports: "utilization" denominators differ (used over provisioned versus used over requested), so compare figures within a report, never across reports. The model isolates this waste explicitly: Cluster Idle Cost = Cluster Asset Costs − Workload Costs.

Network egress and cross-AZ traffic costs

Standard resource metrics miss network billing paths entirely, and the rates differ sharply by provider. AWS charges $0.01/GB in each direction for cross-AZ traffic, and the CUR writes two line items per transfer, so a single flow costs $0.02/GB in total. NAT Gateway processing adds another $0.045/GB. Azure makes cross-AZ traffic free. GCP charges $0.01/GiB each direction cross-zone and bills traffic to external IPv4 addresses as leaving the zone regardless of destination.

Cloud billing does not map any of these charges to pods. Attribution requires flow-level instrumentation: Kubecost ships a ConnTrack-based DaemonSet that classifies traffic as internet, cross-region, or cross-zone egress, and OpenCost's network-costs component does the same join, falling back to container network transmit counters with default rates of $0.01/$0.02/$0.09 per GiB when the component is absent. With resource and network costs computed, the harder half of the problem is deciding who pays for them.

Cost allocation and shared resource splitting

Attribution assigns computed costs to owners. First, teams map workloads to owners and divide costs that no single team owns. Then finance decides how to record the allocated costs against team budgets.

Allocation by namespace, workload, and pod

Labels and annotations are the mechanism that makes team and service attribution possible; every cost tool aggregates by them. The cloud-native paths have hard limits: AWS has supported Kubernetes labels as cost allocation tags since October 27, 2025, capped at 50 labels per pod with excess labels discarded, while GCP drops every label from the billing export for pods carrying more than 50. Enforce team and service labels through admission policy. Add environment as a separate required label rather than letting labels accumulate.

Splitting shared cluster costs

System namespaces, shared load balancers, multi-tenant persistent volumes, and node overhead belong to no single team. Node overhead alone is material: The New Stack measured that it "can reach over 20% on the smallest node types, are generally in the 5–10% range for 'medium' size nodes" (The New Stack).

The FinOps Foundation's shared-costs working group defines three splitting methods:

• Even split: Teams divide the total amount evenly across targets.
• Fixed proportional: Teams set ratios infrequently from past spend.
• Variable proportional: Teams recompute ratios from a live metric such as vCPU hours or direct charges.

The same working group notes that "mature organizations tend to proportionally distribute shared costs among business units based on their direct charges on a monthly basis."

The FinOps Foundation and FOCUS maintainers are standardizing this process. FOCUS 1.3, ratified December 11, 2025, added allocation-specific columns exposing split-cost methodology. FOCUS maintainers designed FOCUS 1.4's AllocatedMethodDetails column to document how teams divided shared usage records, specifically for shared Kubernetes clusters.

Showback vs. chargeback

The FinOps Foundation defines showback as reporting "used for awareness and visibility" that is "not typically entered into financial systems," while chargeback "sends expenses to a product or department P&L" (FinOps terminology). The framework's guidance on choosing: "Showback is always required in any FinOps practice, but chargeback is dependent on organizational accounting policies". Start with showback, and move to chargeback only once allocation quality survives scrutiny and finance agrees to book the numbers, because a chargeback built on disputed splits erodes trust in the whole model. With allocation settled, the practical question becomes what a cost monitoring tool needs to do.

Key features and capabilities of cost monitoring tools

A cost model produces numbers; a useful tool wraps those numbers in capabilities that change behavior:

• Allocation granularity: The tool reports per-pod, per-namespace, and per-label breakdowns rather than cluster totals.
• Rightsizing recommendations: The tool derives request corrections from measured usage.
• Anomaly detection and budget alerting: The tool ties spike detection to owning teams.
• Forecasting: The tool projects spend from consumption trends.
• Multi-cloud billing ingestion: The tool reconciles in-cluster metrics against AWS, Azure, and GCP invoices.

Rightsizing and autoscaling as cost control

Monitoring data closes the request-to-usage gap through manual request corrections or automation. Each autoscaling layer handles a different part of that correction loop:

• VPA: The Vertical Pod Autoscaler applies corrections directly. The InPlaceOrRecreate mode has been GA since VPA 1.6.0 on Kubernetes 1.27+ with the InPlacePodVerticalScaling feature gate. Kubernetes' own autoscaling overview still documents in-place resize as unsupported as of 1.36, so confirm the behavior on your specific VPA and Kubernetes build.
• HPA: HPA adds or removes replicas to track demand horizontally while VPA corrects per-pod requests. VPA must not target the same resource metric as HPA.
• Karpenter: At the node level, Karpenter bin-packs pods onto right-sized and often spot instances. AWS contributed Karpenter's vendor-neutral core to CNCF via SIG Autoscaling in October 2023.
• KEDA: KEDA (CNCF Graduated, August 22, 2023) scales workloads on event metrics.

The published outcomes are large. Adidas cut monthly costs 50% on dev and staging clusters with automated VPA plus Karpenter (InfoQ), Getir reported a 60% compute cost reduction within two weeks of adopting Karpenter (AWS-published, vendor-stated), and TRM Labs cut worker node-pool costs roughly 50% scaling Airflow workers with KEDA. One caution: these case studies bundle several techniques, so analysts cannot attribute the savings to a single autoscaler.

Anomaly detection and budget alerting

Cost spikes tend to come from configuration, not gradual growth, so they need detection in hours rather than at invoice time. StepChange documented a 20x Datadog bill increase caused by GKE Autopilot annotating pods with prometheus.io/scrape: true by default, which turned every exposed Prometheus metric into a billable custom metric. Anomaly detection tied to cost dimensions catches that class of failure while it is still a config revert, and budget alerts convert visibility into action by paging the owning team when a namespace crosses its monthly threshold.

Multi-cloud and on-prem pricing integration

A cost model is only as accurate as the prices it applies, so ingestion of real billing data matters more than list prices. OpenCost integrates billing from AWS (CUR/Athena, with CUR 2.0 support since v1.120.3), Azure, GCP, and OCI, and Kubecost extends this with reconciliation against negotiated discounts, a vendor-stated capability in the OpenCost FAQ. On-prem clusters have no billing API at all, so tools substitute custom pricing: OpenCost supports custom persistent volume pricing via annotations since v1.120.2 and external cost plugins since v1.110.0 that ingest arbitrary FOCUS-formatted cost data.

How Kubernetes cost models fit the tools landscape

The tools split into dedicated open-source allocators, commercial cost platforms, and DIY metrics stacks, each with a different cost-of-ownership profile:

• OpenCost: CNCF Incubating since October 25, 2024, Apache 2.0, no license fee. It provides real-time allocation with cloud billing integration. IBM Kubecost, Randoli, and a wider community that includes the major cloud providers maintain it (CNCF).
• Kubecost: IBM acquired Kubecost on September 17, 2024. The Foundations tier is free up to 250 cores with 15-day retention; Enterprise tiers are contact-sales, with an AWS Marketplace public offer of $15,000 for a 12-month subscription covering up to 250 VPC cores. Kubecost Cloud sunset on August 26, 2025, and IBM migrated users to Enterprise Cloud.
• Prometheus plus Grafana: These supply the raw metrics but no cost attribution layer; you build the billing joins yourself. Scale is the hidden cost: Coveo ran 1,000,000 active series and cut Prometheus memory from 40 GB to 8 GB only after dedicated optimization work. That tuning time is the real price of the DIY stack, and it recurs every time the cluster grows.
• Commercial observability platforms: Datadog sells Cloud Cost Management at $5 per $1,000 of cloud spend per month (Pro, annual) on top of infrastructure monitoring at $15/host/month, plus Kubernetes Autoscaling at $3/vCPU/month.

Open source gives you the model and hands you the engineering cost; commercial platforms give you packaged allocation with their own meter running. That meter is the next problem.

The observability cost problem behind the cost problem

The tool that measures your Kubernetes costs can itself become a top cloud line item, because most observability pricing scales with data volume and Kubernetes generates volume by design. Datadog bills custom metrics as the average number of distinct time series per hour, and every metric from an OpenMetrics or Prometheus check counts as a custom metric.

Wolt reported a single metric that exploded into nearly 2 million unique time series and cut indexed custom metrics 39% in cleanup. Labels increase billed series when the monitoring configuration emits those labels as metric dimensions, so the labels a cost model needs can become the same labels that volume-based pricing punishes.

groundcover breaks that coupling with flat per-node pricing, roughly $35/node/month at the Enterprise tier, with no per-GB ingestion charges, custom-metric surcharges, or per-user fees. The Flora eBPF sensor deploys as a single DaemonSet, one pod per node, capturing metrics, logs, traces, and Kubernetes events at the Linux kernel with zero application instrumentation, and feeds a BYOC (Bring Your Own Cloud) data plane where ClickHouse and VictoriaMetrics run inside your own cloud account. Because groundcover charges by node, data volume, user count, custom metric cardinality, and trace sampling rates do not change the per-node unit price. Teams can therefore keep rich attribution labels across production and non-production clusters without increasing that unit price.

groundcover documents the gap this produces at scale in groundcover's own Datadog pricing guide: a team running ~700 Kubernetes nodes with 5 TB/day of logs and 500K custom metrics was paying $2.54M/year on Datadog, while the same setup on groundcover cost $297K/year, an 87% reduction, with full APM enabled and no trace sampling.

groundcover published that comparison, and no independent audit has verified it. Better Stack's independent comparison puts typical savings in the 40–60% range for Kubernetes-heavy environments and notes that BYOC infrastructure costs belong in the calculation. If you want to validate the architecture on your own cluster, the free plan includes BYOC and requires no credit card. Deploy Flora on one cluster and evaluate full-cluster visibility within hours.

What's next for Kubernetes cost models

The frontier for cost models is workloads that current attribution cannot reach:

• GPU cost attribution: NVIDIA's documentation states that DCGM-Exporter "does not support associating metrics to containers when GPU time-slicing is enabled" with the Kubernetes device plugin; a partial fix behind the kubernetes-virtual-gpus flag adds per-process metrics, but per-process SM utilization remains unavailable for MIG combined with time-sharing. Kubernetes v1.34 shipped Dynamic Resource Allocation as GA, with Consumable Capacity in alpha, the groundwork for fractional GPU cost tracking.
• AI inference cost tracking: OpenCost v1.121.0 (July 20, 2026) added inference cost tracking through an llm-d integration, with new Prometheus metrics for total hourly LLM cost and cost per million tokens built on vLLM token throughput. Cost per million tokens becomes an allocation unit alongside cost per pod.
• eBPF-based cost tracing: eBPF supplies per-pod flow visibility, but cost attribution also requires classifying billing paths and applying provider rates. Polar Signals used a Netfilter-hook tool to attribute cross-zone traffic that had grown to nearly half its Google Cloud bill by mid-2024, then cut those costs by 50%. groundcover exposes workload-level network byte counters with an is_cross_az flag; joining those counters with provider rates is still a user-performed step.
• Carbon cost tracking: Kepler (CNCF Sandbox) attributes node power to containers in proportion to CPU time, the Software Carbon Intensity specification became ISO/IEC 21031:2024 in April 2024, and OpenCost ships a carbon estimate integration built on Cloud Carbon Footprint coefficients, with a correctness fix shipped in April 2026 after earlier versions produced materially wrong numbers.