A cloud cost hierarchy rolls segments up in stages, teams into departments, departments into business units, for example. A segment is a named group of cost lines that cost allocation builds from accounts, tags or rules, and every line belongs to exactly one segment per dimension. So each dimension adds up to the invoice on its own, and several dimensions, such as product, team, environment or region, coexist over the same data. Management, finance and the teams then read different cuts of the same invoice total.
How it works
Dimensions and values
A dimension is a question asked of every line, such as which product it belongs to. Its values are the segments, plus a remainder value for whatever meets no condition. Two rules keep a dimension adding up. Each line gets exactly one value, so nothing is counted twice, and the remainder is a value of its own, so nothing disappears. Dimensions do not interfere: the same line belongs to a product, a team and an environment at once. The FinOps Foundation's Allocation capability makes the same point: finance, engineering and operations each read the same cost data through a breakdown of their own.
Hierarchies
A hierarchy rolls the values of one dimension up into those of a higher one, team into department, department into business unit. It keeps adding up as long as every node has exactly one parent.
A reorganisation changes the hierarchy and raises the question of which months it affects. If the new mapping applies backwards, time series stay comparable but earlier reports change their figures. If it applies from a cut-off date, earlier reports stay correct but the series jumps. Either is defensible, provided the mapping carries an effective date. The providers differ. Google records a project's ancestry in project.ancestry_numbers as it was at the time of usage; AWS applies changed cost category rules from the start of the current month or, when an earlier effective month is chosen, retroactively from that month; for the Cost and Usage Report AWS documents a backfill through a support case. For period comparison, this decision determines whether a series stays comparable.
AWS
AWS Cost Categories are the built-in segmentation. A cost category is a key, its values are segments, and AWS attaches the pair to every cost line that a rule or the default value matches. A regular rule sets a fixed value from conditions on dimensions such as account, service, region, charge type, tag or another cost category; an inherited value rule takes the value dynamically from a tag key or the account name. Rules are evaluated in order, the first match wins, and an optional default value catches whatever no rule matches. Hierarchies arise when one cost category's rules use the values of another, for instance a business unit category grouping a team category's values.
After a create or edit, values can take up to 24 hours to reach Cost Explorer, AWS Budgets, the Cost and Usage Report and Cost Anomaly Detection. In the CUR 2.0 they sit in the map column cost_category, and a key appears there only on lines with a value. The management account or a standalone account creates cost categories: up to 50 per management account, each with up to 100 rules in the console or 500 through the API (AWS Cost Explorer and AWS Budgets).
Azure
Azure builds segments from the resource tree and tags. The tree consists of management groups above subscriptions and resource groups, up to six levels below the root management group. It rolls up usage-based charges only, though, and Cost Management does not currently support it for Microsoft Customer Agreement subscriptions. A dimension becomes a saved view in cost analysis: it keeps filters, grouping, granularity and chart type, is valid only in the scope it was saved in, and stores no data. Each user can keep up to 100 private views across scopes, and each scope up to 100 shared views open to anyone with at least Cost Management Reader. Virtual tags and allocation rules covers cost allocation rules, which move cost between subscriptions, resource groups or tags.
Google Cloud
On Google Cloud the built-in tree is the resource hierarchy of organization, folders up to ten levels deep, and projects. The export holds it in project.ancestors, the Cloud Billing reports as the Project hierarchy grouping. Further dimensions come from labels: the reports group by a label key, though not by labels set on the project, and gather cost without that key under "Charges for other usage". On Google Cloud, segments that combine several conditions can be built as queries on the BigQuery export.
The three providers side by side
| Built-in grouping | Hierarchy | Where it shows in the data | |
|---|---|---|---|
| AWS | accounts, Cost Categories | organizational units; cost categories that use other cost categories | cost_category in the CUR 2.0, a dimension in Cost Explorer and AWS Budgets; organizational units not in the CUR 2.0 |
| Azure | subscriptions, resource groups, tags, saved views | management groups, up to six levels | SubscriptionName, ResourceGroup and Tags in the cost details; management groups only as a scope |
| Google Cloud | projects, labels | folders, up to ten levels | project.ancestors, labels and project.labels in the export |
What it means for your cost
Each dimension becomes a cost report or dashboard with the same total: by business unit for management, by cost centre for finance, by product and environment for the teams. Because each dimension covers the whole invoice, the reports can be checked against one another, and in each the remainder shows how much belongs to no segment yet. Budgets, period comparisons and unit costs build on a segment and inherit its quality. Cost centres and team ownership describes the link between team and cost centre that finance needs.
Segments describe cost and never move it: the invoice, the billing account and the payer stay unchanged. The containers underneath come from allocation by account, subscription and project, and the values inside them from tags and labels or rules.
Where it goes wrong
- One line in two segments. Symptom: the total across all teams exceeds the invoice. Cause: conditions overlap without a fixed order; AWS cost categories assign the value of the first matching rule, while a hand-written query does so only if built that way.
- A node with two parents. Symptom: a shared team appears under two departments, and the business units together exceed the invoice. Cause: the hierarchy allows two parents where a shared team needs its own node and a split rule.
- No remainder value. Symptom: an analysis over a cost category's values comes to less than the invoice. Cause: without a default value, unmatched lines carry no value; the key is then absent from
cost_categoryin the CUR 2.0, and a query over the values silently drops them. - A reorganisation without an effective date. Symptom: a closed quarter's figures change after the fact, or a department's series jumps in the month of the reorganisation. Cause: the mapping changed with no effective date and no decision on whether it applies backwards.
Sources
Read on 2026-10-16. FinOps Foundation Allocation capability (CC BY 4.0); AWS organizing costs using AWS Cost Categories, creating cost categories, CUR 2.0 cost category column and Billing and Cost Management quotas and restrictions; Microsoft management groups overview, Understand and work with scopes, Introduction to cost allocation, save and share customized views and cost details fields; Google Cloud about resource hierarchy, Create folders, Structure of Standard data export and Cloud Billing reports.