This chapter explains how every line of the cloud bill gets an owner: through the structure of accounts, subscriptions and projects, through tags and labels on resources, through rules for everything neither of those captures, and through the unit costs in which allocated cost is finally read. Allocation is not a bookkeeping exercise. It is what lets a cost report answer the question someone actually asked, and what lets a saving be credited to the team that achieved it.

What this chapter covers

The chapter starts with structure. Why allocation comes before any optimisation is the first question: a saving that belongs to nobody is not implemented, and a budget without an owner is not kept. The FinOps Foundation's FinOps Framework lists Allocation as a capability of its Understand Usage & Cost domain, and the article FinOps Framework 2026: what small teams should actually change sorts out how much of that a small team really needs. From there the chapter turns to the first and cheapest allocation dimension, the account, subscription and project structure every provider writes into every line anyway; to cost centres and the question of which team owns a resource; and to segments and hierarchies, which let the same cost be cut by product, team or region depending on who is reading.

The second section is about tags. What a tag or label technically is, and by which route it reaches the billing data on AWS, Azure and Google Cloud, is the foundation; the providers differ here more than the shared vocabulary suggests. On that rest the questions of what a tagging policy looks like that is still followed after the second quarter, how coverage and untagged cost are measured and why allocation coverage counts money rather than resources, and how virtual tags and allocation rules close the gaps that cannot be closed on the resource.

The third section covers what cannot be cleanly assigned to one owner. Shared cost such as networking, monitoring and support needs a splitting rule; unallocated cost needs an owner for the remainder; a Kubernetes cluster needs allocation by namespace, label and pod, because the bill only knows the nodes. The section ends with unit economics, where allocated cost first becomes a statement, and with the views by customer, feature and environment that finance, product and engineering actually want to read.

Key terms

  • Cost allocation: the process by which every line of the bill is assigned to an owner, through structure, tags or rules.
  • Tag: the key-value pair on a resource that the provider copies into the billing data; a label on Google Cloud.
  • Allocation coverage: the share of cost that has an owner, measured in money; the number this chapter is judged by.
  • Shared cost: cost that belongs to several owners at once and is only distributed by a rule.
  • Segment: a named view of the same cost, by product, team or environment for instance, from which a report is built.
  • Showback and chargeback: whether allocated cost is merely shown to teams or actually charged to them.
  • Unit economics: allocated cost per counted business unit, the form in which allocation is finally read.

Neighbouring chapters

Before this chapter comes "What cloud services cost": it explains what the lines are for that get an owner here, and without it the reader cannot see why data transfer, support and commitments escape allocation on a resource. After it comes "Reporting and analysis": what was allocated here is read there in reports, dashboards and subscriptions, and every grouping in a report presupposes an allocation this chapter describes. The policies that keep an allocation complete, mandatory tags, approvals and ownership of the unallocated remainder, sit in "Governance and the operating model". The unit costs this chapter ends on return in "Budgets, forecasts and finance" as the basis of a forecast and in "FinOps for AI" as cost per token. The overview of all chapters is in the handbook.