19d (edited) • Cost Optimization
Same bill, three invoices: why shared-cost allocation decides who pays
Your tagging is fine. Your showback is still going to start a fight.
Showback rarely dies on tag coverage. It dies on the remainder: the shared Kubernetes cluster, NAT and egress, the support plan, observability, the platform team, commitment discounts, idle capacity. Somebody has to decide who pays for that, and the formula you pick decides the invoice more than the usage does.
ILLUSTRATIVE example. ExampleCo, four teams (Checkout, Search, Data, Platform), one month, total bill 200,000. I ran it through a small Python script so every number below is computed, not vibes.
Tag coverage: 92%. Looks great on a dashboard.
Directly attributable to the team that consumes it: 60%.
The gap is shared pools: the cluster, NAT, observability, support and tooling are all "tagged" to Platform or to nobody.
Now allocate the 54,000 of general shared cost three ways. Same bill, three invoices:
Checkout: even 58,000 / proportional 62,500 / driver-based 63,300
Data: even 74,000 / proportional 83,000 / driver-based 80,060
Search: even 41,500 / proportional 39,250 / driver-based 38,850
Platform: even 24,500 / proportional 13,250 / driver-based 15,790
Data's invoice moves by 9,000 depending only on a spreadsheet decision. Nobody changed a single resource.
Now the part that kills trust. Checkout cuts its direct spend by 30%. The company saves 12,000.00. Under proportional allocation (the usual default), Checkout's invoice drops by 16,000.01, and Data (+2,500.00), Search (+1,250.01) and Platform (+250.00) all get a higher bill for doing nothing. Under driver-based allocation the others absorb +444.45 in total, only because support is still split by spend. Under even split, zero.
Proportional is zero-sum and circular. Every saving one team makes is partly invoiced to its neighbours. Do that twice and nobody believes the numbers.
Two more traps in the same example:
Commitment discounts. The 18,000 commitment fee was bought from the Platform account. "Buyer pays" puts all 18,000 on Platform. Amortized by covered usage it is Checkout 4,500, Search 3,000, Data 10,500, and those teams can actually see their discount.
Idle capacity. 6,000 of unrequested cluster capacity. Give it an explicit owner (Platform, who can fix bin-packing) or spread it by requested CPU so over-requesters pay for their slack. Pick one and write it down.
What I would do:
1. Publish two numbers, not one: tag coverage and unallocated %. Aim for unallocated under 10%, then push lower.
2. Use driver-based allocation for the big pools (CPU-hours requested for the cluster, GB egress for NAT). It costs effort. It survives a dispute.
3. Run showback for about 90 days before anyone sees a chargeback.
4. Write the dispute process down before the first invoice goes out.
5. Run a stability test: if one team saves money and the others pay more, fix the method before you ship it.
My rule: if you can't explain the allocation formula to your most skeptical team lead in two minutes, don't charge anyone.
The hands-on lab is in the Classroom (Premium): "Showback That Survives a Dispute". You build the allocation script step by step, run all three methods and the stability test on your own CSV export, and walk away with a written allocation policy.
Which allocation method does your org use today, and what argument did it cause?
3-minute video version: https://youtu.be/Der8NRLwfOo
0
0 comments
Same bill, three invoices: why shared-cost allocation decides who pays
powered by
skool.com/cloud-cost-optimization-3746
Claude Code & AI agents for cloud engineers. Automate AWS, Azure, GCP, K8s and Terraform without deleting prod. Free scripts, real labs.
Suggested communities
Powered by