Direct costs — a VM that belongs to one team — are easy. The genuinely difficult problem in allocation is shared costs: infrastructure that multiple teams use simultaneously and that cannot be tagged to a single owner.
Common Shared Cost Categories
- Shared Kubernetes clusters: The control plane, node pools, and cluster-level tooling (monitoring, ingress) serve every team running workloads on the cluster.
- Centralized data platforms: A shared data lake, a Kafka cluster, or a centralized logging system used by all engineering teams.
- Network egress and NAT gateways: Traffic costs that are generated by many services but billed at the network boundary.
- Support and enterprise agreements: AWS Enterprise Support, Azure Reserved Instance commitments, or GCP committed use discounts purchased centrally.
Splitting Strategies
There is no universally correct answer. The right strategy depends on your organization's culture and the availability of usage data.
| Strategy | How It Works | Best For |
|---|---|---|
| Equal Split | Divide the shared cost evenly among all consuming teams. | Simple, low-overhead. Fair when usage is roughly equal. |
| Proportional Split | Divide based on each team's share of a proxy metric (e.g., CPU hours consumed, number of pods, GB of data processed). | More accurate. Requires usage instrumentation. |
| Fixed Allocation | Assign a fixed percentage to each team based on a business agreement (e.g., "Platform team absorbs 100% of shared infra costs"). | Simple governance. Decouples cost from usage. |
| Direct Attribution | Use detailed metering to charge each team only for what they actually consumed. | Most accurate. Highest engineering effort. |
The proportional split based on actual usage metrics is the gold standard, but it requires that your shared infrastructure emits per-team usage data — which often means instrumenting your Kubernetes cluster with namespace-level cost tooling (like OpenCost or Kubecost) or your data platform with per-team job accounting.
A common interview question is: "How would you allocate the cost of a shared Kubernetes cluster across 10 product teams?" The weak answer is "tag the nodes." The strong answer explains that node-level tags only tell you which team owns the node pool, not how much of a shared node pool each team consumed. The correct approach is to use a Kubernetes cost allocation tool (OpenCost, Kubecost, or cloud-native equivalents like AWS Cost Allocation Tags on EKS) that measures CPU requests, memory requests, and actual usage at the namespace or label level, then maps those metrics to team cost shares. You also need a policy for idle/unallocated capacity — does it go to a shared overhead pool, or is it distributed proportionally?