Cost Allocation · AWS + Azure + Google Cloud
Published
Every FinOps capability rests on one question: who spends what, on which thing, and is it worth it? If the bill cannot be split truthfully across teams, products and environments, then optimisation has no owner, commitments have no baseline and finance has no forecast. Allocation is unglamorous, it sits among the foundational capabilities of the FinOps Foundation’s framework, and it is the foundation everything else stands on.
Structure first, tags second
The coarsest allocation instrument is the account boundary: AWS accounts, Azure subscriptions and Google Cloud projects. Spend lands in them unavoidably, no tag required, which makes a well-designed account structure the most reliable allocation you will ever get. Separating production from non-production, and major products from each other, at the account level answers the biggest questions before a single tag is written.
Tags then carry the finer grain. The mistake almost every organisation makes is aspiration: a tagging standard with fifteen keys, three of them mandatory in theory, none enforced in practice. Allocation needs a small set that is actually present:
- Owner: the team, not a person who will leave
- Environment: production, staging, development
- Service or product: the thing the business would recognise
- Cost centre: the code finance already uses
Enforce them where resources are created: validation in your infrastructure-as-code pipelines, AWS tag policies and service control policies, Azure Policy, and organisation policy on Google Cloud. Tags added retrospectively in a spreadsheet are archaeology, not allocation.
Measure the untagged, relentlessly
Untagged spend is the honest metric of an allocation practice. Track it as a percentage, publish it, and drive it under 5%. Two mechanisms do most of the work: blocking untagged resources at deployment, and a monthly sweep in which everything unattributed is assigned to a named owner for correction. Note that some spend is never taggable, such as certain support charges and data transfer line items; allocate it by an agreed rule rather than pretending it does not exist.
From reporting to behaviour
Allocation only earns its keep when the numbers reach the people who cause them:
- Showback puts each team’s spend in front of that team and its leadership every month. In our experience this alone changes behaviour: engineers fix what they can see, and nobody wants to lead the waste table. The storage line is usually the first thing they attack.
- Chargeback goes further and bills the spend to team budgets. It creates the strongest incentives and the most politics; adopt it only once showback numbers are trusted.
- Unit economics is the mature end point: cost per customer, per transaction, per tenant. It converts the bill from a scary total into a business metric, and it is the number that makes cloud cost conversations rational. A rising bill with falling cost per transaction is success, not a problem.
The raw material for all of this is the billing data itself: the Cost and Usage Report with Cost Categories on AWS, cost exports on Azure, and the BigQuery billing export on Google Cloud. The tooling layer on top matters less than the discipline underneath.
Whose job is this?
Allocation fails as a side project because it sits between finance, who own the money, and engineering, who own the resources. Someone has to own the join. Inside our Managed FinOps retainer that is us: we build and enforce the allocation model, run the monthly numbers, and train your teams until the discipline lives in your organisation rather than in a consultant. Day one of the Cloud Cost Health Check is precisely this exercise, mapping where the money goes, so if you cannot currently answer that question, that is the place to start.