Cost allocation on shared Kubernetes in multi-tenant SaaS

Multi-Tenant SaaS on Shared Kubernetes Is the Hardest Cost-Allocation Problem in Cloud

Run a B2B SaaS at any reasonable scale on Kubernetes and the same problem will eventually land on the platform team’s plate: which customer is costing how much. The single-tenant version of this question is easy — one cluster per customer, one bill per customer, done. The multi-tenant version is the one nobody wants to write about because the answer is hard.

Pods are not features. Namespaces are not customers. Labels are not consistent. Idle capacity is not free. Cluster autoscaling is non-linear. The control plane has its own cost. The shared services — ingress, observability, secrets, service mesh — are nontrivial and are not somebody’s “feature.” And on top of all of it, the bill from AWS or GCP arrives at cluster-and-node granularity, not at customer-or-tenant granularity. The translation layer is the problem.

In 2026 the translation layer has matured. OpenCost is the open-source vendor-neutral specification, originated from Kubecost’s engine. Kubecost itself is now an IBM product following the 2024 acquisition, with self-hosted and SaaS variants. CloudZero and Vantage cover the cost-aggregation side. Apptio’s Cloudability and the FinOps Foundation’s Multi-Cloud Cost Allocation specification provide the higher-level frame. Together they make multi-tenant cost allocation possible — not free.

What “Tenant” Has to Mean Before You Allocate

Before any tool can attribute cost, the platform team has to make an explicit decision about what a tenant is in their cluster. Three patterns dominate:

Namespace-per-tenant. Each customer gets a namespace. Cost allocation is straightforward — every pod, every PVC, every ingress in the namespace gets attributed to the customer. Works for small to mid-sized B2B with hundreds of tenants. Breaks down at thousands of tenants because Kubernetes namespaces have a non-zero scheduling and policy cost.

Label-per-tenant within shared namespaces. Tenants are differentiated by a label (tenant=acme, customer-id=12345) on every workload. Cost allocation requires consistent labeling across every Deployment, StatefulSet, Job, and PVC. Fragile if labeling discipline drifts; supports very large tenant counts; requires admission controllers to enforce.

Logical tenancy (database row level). Tenants are not visible at the Kubernetes layer at all — they are rows in a database, served by shared application replicas. Cost allocation has to happen at the application layer (request count, data volume, feature usage) rather than at the cluster layer. Most pure-multi-tenant SaaS lives here.

The cost allocation strategy follows directly from this decision. Tools cannot save a team that has not decided what a tenant means.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

The Three Cost Components That Have to Be Attributed

A complete multi-tenant cost allocation handles three components, not one. Most teams allocate the first cleanly, the second imperfectly, and the third not at all.

Workload cost. CPU, memory, GPU, persistent volume, and network for tenant-attributable pods. OpenCost and Kubecost both compute this from Prometheus metrics on resource requests and usage, multiplied by the cloud provider’s effective hourly rates pulled from billing exports. This is the part that works.

Shared-services cost. Ingress controllers, service meshes, observability stacks, secret managers, the control plane itself, the cluster autoscaler. None of these belong to a single tenant; all of them have to be allocated by some rule. The honest rules are: proportional to workload cost (default in OpenCost), proportional to a usage signal (request count for ingress, log volume for observability), or fixed-percentage overhead (simplest, least accurate). Whichever rule is chosen has to be documented, defended, and consistent across reporting periods.

Idle cost. This is the one most teams ignore at their peril. A node provisioned for one hundred units of capacity that is being used at sixty units has forty units of idle capacity. Whose cost is that? Three honest answers: allocate proportionally to running tenants (their usage triggered the node provisioning), allocate to a “platform overhead” bucket (centralizing the optimization incentive), or allocate to a “headroom” bucket reserved for autoscaling. The wrong answer is pretending it is not there. Idle cost is typically twenty to forty percent of cluster spend in mid-market multi-tenant SaaS.

OpenCost vs. Kubecost vs. SaaS Variants in 2026

The 2026 landscape after the IBM acquisition of Kubecost (2024) and OpenCost’s CNCF incubation is clearer than it was a year ago.

OpenCost is the open-source specification and reference implementation. Free, vendor-neutral, integrates with the major cloud providers’ billing APIs. Strong fit for a team that wants the cost data in Prometheus and a Grafana dashboard, and is comfortable building chargeback reports on top of that data themselves. Limited UI for non-engineering stakeholders.

Kubecost (IBM) offers a free tier and paid tiers. The paid tiers add multi-cluster aggregation, governance and budgets, deeper unit-economics reporting, and an enterprise UI. Strong fit for a team that wants chargeback and showback dashboards out of the box, plus enterprise support. The IBM acquisition’s effect on roadmap and pricing is the variable to watch — early signals through 2025 and into 2026 are stable, but enterprise software pricing always tends one direction post-acquisition.

CloudZero, Vantage, Apptio Cloudability. Higher-level cost-aggregation tools that ingest Kubecost or OpenCost data along with non-Kubernetes spend (RDS, S3, third-party SaaS bills) and produce CFO-grade reports. Strong fit for a finance organization that wants one place for all cloud and SaaS cost reporting; weaker fit if all spend is Kubernetes and the team only needs cluster-internal allocation.

For a multi-tenant SaaS choosing today: start on OpenCost (free) for the engineering view, add Kubecost (paid) when the chargeback motion becomes a real business process, and layer CloudZero or Vantage on top when finance needs unified reporting across cloud + SaaS + Kubernetes.

Chargeback vs. Showback: Where the Real Decision Lives

The most consequential cost-allocation decision is not which tool — it is what the engineering team is held accountable for once costs are visible.

Showback. Costs are reported per tenant, per team, per service. Engineers see the bill. Finance does not move money around based on it. The hope is that visibility alone drives optimization. It works for some cultures; in many it produces dashboards that get bookmarked and ignored.

Chargeback. Costs are reported per tenant, per team, per service, and budget is allocated to the consuming team accordingly. Going over budget has consequences. Engineers optimize because their team’s budget is the constraint, not because a Slack channel is yelling at them.

The structural reason chargeback works where showback does not: cost optimization without a budgetary feedback loop is a side project. With a feedback loop it is part of the team’s roadmap. The teams that have moved from forty-percent-idle clusters to fifteen-percent-idle clusters in 2026 did it by enabling chargeback, not by buying a fancier cost tool.

What an Active Cost Agent Adds on Top

A passive cost dashboard tells the team what is wrong. The shift to an active operational layer in 2026 means an agent watches the dashboard, attributes the regression to a tenant or a service, and acts on reversible cleanup autonomously while escalating irreversible decisions for human approval.

In a multi-tenant SaaS context, the cost agent’s working surface looks like:

• Continuous attribution. Re-runs the OpenCost / Kubecost allocation hourly, not weekly. Cost changes are noticed in hours, not invoice cycles.
• Regression detection. When a tenant’s allocated cost jumps, the agent investigates the cause — new workload deployed, request volume spike, label drift, container image bloat — and produces a rooted summary, not a “your cost went up” alert.
• Reversible cleanup, autonomous. Right-sizing oversized requests, applying TTL on idle PVCs in dev environments, pausing long-running unused dev-cluster workloads. Audit trail records every action. The savings show up on the next bill.
• Irreversible cleanup, gated. Deleting persistent volumes, decommissioning shared services, changing tenant tier — always escalates to the human approver with full context.
• Chargeback report generation. The cost-attribution dashboard is generated from the agent’s own attribution graph, not maintained by hand.

The pattern is the same one the active operational layer applies elsewhere: agents do the cost work, humans are in the loop only where judgment matters, audit trail covers everything.

The Three-Phase Rollout

Phase 1 — Get attribution right. Decide what a tenant means. Apply consistent labeling. Stand up OpenCost. Run the cost allocation against your own knowledge of which tenants are big and small — if the numbers do not match your expectation, the labeling is wrong. Two to six weeks for a mid-sized cluster.

Phase 2 — Move from showback to chargeback. Get finance and engineering on the same page about budgets, ownership, and consequences for going over budget. This is a process change, not a tooling change; expect it to take a quarter and to require executive air cover.

Phase 3 — Layer the cost agent. Continuous attribution, regression detection, autonomous reversible cleanup. The win compounds as the cost agent learns the cluster’s tenancy patterns and the tenancy patterns themselves stabilize. Most mid-market SaaS see fifteen to thirty percent steady-state cluster cost reduction within six months of phase three.

How IAN Helps

IAN’s cost agent runs continuous attribution against shared Kubernetes clusters out of the box, integrates with OpenCost or Kubecost where they are deployed, and applies the active operational layer pattern to multi-tenant cost: agents do the right-sizing, the lifecycle, and the regression investigation; humans approve the irreversible cleanup; the audit trail is the artifact.

Pricing is BYOK and usage-based. Customers bring their own Claude or model keys; IAN charges for the orchestration of cost actions across clusters and clouds. The cost-allocation work that used to be a half-FTE on the platform team becomes a continuous service running in the background, with chargeback reports generated as a side effect of the agent’s attribution graph.

Get a free infrastructure audit → | See pricing →