Skip to main content

Chargeback Design for Shared and Untaggable Costs

You are designing a chargeback system for 200 teams running across AWS, GCP, and Azure. How do you handle the 15 to 25 percent of the bill that cannot be tagged to a single team, like inter-AZ data transfer, support plans, NAT gateways, and shared Kubernetes clusters?

senior
advanced
FinOps
Question

You are designing a chargeback system for 200 teams running across AWS, GCP, and Azure. How do you handle the 15 to 25 percent of the bill that cannot be tagged to a single team, like inter-AZ data transfer, support plans, NAT gateways, and shared Kubernetes clusters?

Answer

Chargeback at scale is 70 percent politics and 30 percent engineering. The engineering problem: 15 to 25 percent of your multi-cloud bill is not directly attributable. Inter-AZ data transfer, NAT gateway hours, support plans, marketplace subscriptions, management fees, reserved instance upfront payments, and shared services like a platform Kubernetes cluster all resist simple tag-based allocation. My approach has five parts. First, split the bill into three buckets: directly attributed (tagged, owner is obvious), indirectly attributed (shared but allocatable by proxy), and unallocated (absorbed centrally). Be explicit about which costs fall where. Second, pick allocation keys for the shared bucket and write them down before the first report goes out. Shared NAT gateway gets split by data transfer bytes per source VPC or by tagged VPC usage. Support plans get split as a flat percentage on each team's direct spend. Shared Kubernetes clusters get split using Kubecost or OpenCost based on namespace and workload labels, which is a separate tagging discipline from cloud resource tags. Reserved instance and Savings Plan discounts get amortized based on which team's instance hours matched the commitment. Third, normalize everything into a single warehouse. CUR 2.0 from AWS, BigQuery billing export from GCP, EA or MCA export from Azure, all landing in Snowflake, BigQuery, or Redshift. Normalize tag keys across clouds so AWS tag team, GCP label team, and Azure tag team all become one dimension. Fourth, publish monthly with a 2-week dispute window, then freeze. Disputes after freeze go to next month. Without a freeze you will re-run the report every time finance asks a question. Fifth, untagged resources hit a 'tax' bucket owned by the platform org, not individual teams. This creates pressure to tag without punishing teams for platform gaps. Report untagged spend publicly every month and it usually drops fast.

Why This Matters

This is a senior-level question to see if the candidate has lived through a real chargeback rollout or just read the FinOps Foundation docs. Strong candidates will break down the three buckets, acknowledge that some costs simply cannot be allocated cleanly, and talk about the organizational side (freeze windows, dispute process, public reporting). They will also mention normalizing across clouds in a warehouse, and the distinction between cloud-resource tags and Kubernetes-workload labels. Red flag: candidates who claim they can tag 100 percent of the bill or who skip the politics entirely.

Code Examples

Split tagged vs untagged spend in GCP BigQuery billing export

sql

Allocate shared NAT gateway spend proportionally to VPC usage (AWS CUR 2.0)

sql

Kubecost allocation config for a shared cluster

yaml
Common Mistakes
  • Claiming every dollar can be tagged, then silently dropping untagged spend from reports
  • Running chargeback without a dispute and freeze window, so reports are never final
  • Allocating shared Kubernetes costs using cloud resource tags instead of namespace-level labels through Kubecost or OpenCost
  • Ignoring that reservations and Savings Plans break naive per-hour team attribution
Follow-up Questions
Interviewers often ask these as follow-up questions
  • How do you allocate Reserved Instance and Savings Plan discounts fairly when multiple teams benefit from the same commitment?
  • What would change in your design if you had to support GDPR-style data residency where some costs cannot cross regions even in reporting?
  • How do you stop teams from gaming the chargeback system once they see the numbers?
  • Would you build this on top of CUR and BigQuery yourself, or buy a tool like Vantage, CloudHealth, or Apptio? Why?
Tags
finops
cloud-costs
chargeback
tagging
multi-cloud
bigquery
Sponsored
Carbon Ads

More FinOps interview questions

Also worth your time on this topic