Cost allocation by account uses the container a resource runs in: the AWS account, the Azure subscription and its resource group, or the Google Cloud project. This account structure is written on every usage line of the billing data, for past months too, without anything being set on a single resource; a tag offers neither. When each container has exactly one owner, the cost allocation is already exact. AWS's multi-account whitepaper calls the account the default means of allocating costs. How workloads are spread across accounts, subscriptions and projects is therefore the cheapest and most durable allocation decision.
How it works
All three providers have two levels. The container is where resources are created, and its identifier is on every usage line. Above it, a hierarchy built for access and policy groups containers into larger units that reports can use too. A second tree stands apart: the billing hierarchy, which decides which billing account pays, not who owns a resource. Billing accounts and hierarchies covers that tree.
AWS
The whitepaper Organizing Your AWS Environment Using Multiple Accounts recommends several accounts rather than one, separated by workload and environment, and notes that AWS charges for usage, not for the number of accounts. In AWS Organizations, organizational units (OUs) group accounts and nest up to five levels below the root. In the Cost and Usage Report 2.0 every line carries line_item_usage_account_id and line_item_usage_account_name, the account that used it, whether management or member account; the paying management account sits separately in bill_payer_account_id (see AWS Cost and Usage Report and Data Exports). The OU is not among the line item and bill columns. Account tags can carry it: tags on accounts in AWS Organizations, activated under Cost Allocation Tags in the Billing and Cost Management console. AWS states that they apply to all metered usage in a tagged account, including refunds, credits and certain service charges that cannot be tagged at the resource level. Reports show them with the prefix accountTag, and activation can take up to 24 hours.
Azure
Azure has two container levels: the subscription and, inside it, the resource group holding each resource. Management groups arrange subscriptions into a tree under the directory's root management group. A directory supports up to 10,000 management groups and a tree up to six levels, not counting the root or the subscription level, and every management group and subscription has exactly one parent. The cost details carry SubscriptionId, SubscriptionName and ResourceGroup; charges from no resource group show an empty value, Others or Not applicable. No field names the management group. In Cost Management it is a scope for cost analysis, with documented limits: Cost Management features do not currently support management groups for Microsoft Customer Agreement subscriptions or in CSP scopes, the Cost Details API supports them for neither EA nor MCA, and a management group rolls up usage-based charges only. Purchases such as reservations or third-party Marketplace offers appear only at the billing level: the EA billing account, or the MCA billing account and its billing profiles (see Azure Cost Management and Billing).
Google Cloud
On Google Cloud the project is the container, and every service resource belongs to exactly one project. The organization sits at the root with optional folders in between, and every resource except the top one has exactly one parent. Folders nest up to ten levels deep. In the standard usage export each line from a project carries project.id and project.name, the project's labels in project.labels and the hierarchy above it in project.ancestors, ordered from the project through its folders to the organization; the field is filled from April 2022. Google's schema states that project.ancestry_numbers records the ancestry at the time of usage, so a project later moved to another folder stays in its old place on old rows (see Google Cloud billing export). The Cloud Billing reports group by Project hierarchy (organization, folder, project) for time ranges from 2022-01-01, and show cost outside any project as "Charges not specific to a project". Google keeps the Cloud Billing account outside this tree: ownership (IAM inheritance) and payment linkage are separate, and a billing account can pay for another organization's projects.
The three providers side by side
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| Container | account | subscription, with resource groups inside | project |
| Hierarchy above | organizational units, up to five levels below the root | management groups, up to six levels below the root management group | folders, up to ten levels below the organization |
| Container in the export | line_item_usage_account_id, line_item_usage_account_name | SubscriptionId, SubscriptionName, ResourceGroup | project.id, project.name |
| Hierarchy in the export | only through account tags or Cost Categories | not in the cost details, only as a scope | project.ancestors from April 2022; project.ancestry_numbers as at the time of usage |
| Who pays | management account, bill_payer_account_id | EA billing account or MCA billing profile | Cloud Billing account, billing_account_id |
What it means for your cost
A report by account, subscription or project is the only grouping that covers every usage line without preparation. If each container belongs to one team, a list mapping containers to teams is enough to split the bill, and the list works backwards because the identifier is already on old lines. The hierarchy above supplies the next roll-up, from team to department for instance, built as segments and hierarchies explains.
A container with one owner is allocated exactly; one with several needs tags or rules. Separate containers for production and development also make the environment visible without a tag. This dimension misses cost that arises with the buyer or the payer: commitment purchases, support and Marketplace purchases sit with the account that bought them or at the billing level, and need a shared cost rule of the kind shared cost and how to split it describes.
Where it goes wrong
- Shared accounts and platform projects. Symptom: an account or project named shared or platform carries a large part of the bill and nobody answers for it. Cause: the container hosts several teams' workloads, but the dimension can name only one owner; tags or a split rule do the rest.
- Purchases at the payer. Symptom: the team accounts add up to less than the invoice, and on Azure the root management group shows a different total from the billing account. Cause: reservations, Savings Plans, support and Marketplace are charged where they were bought or at the billing level; on Azure, neither management groups nor EA departments nor MCA invoice sections include such purchases.
- Management groups under an MCA. Symptom: a management group view is missing for Microsoft Customer Agreement subscriptions or cannot be pulled through the Cost Details API. Cause: Microsoft does not currently support management groups in Cost Management for MCA, nor in the Cost Details API for either agreement type.
- A move in the hierarchy. Symptom: a folder's or OU's cost series jumps in the month of a reorganisation. Cause: containers were moved. Google keeps old rows in their old place, whereas a mapping list without an effective date applies the new structure to every month.
Sources
Read on 2026-10-16. AWS Organizing Your AWS Environment Using Multiple Accounts and its section benefits of using multiple AWS accounts, quotas for AWS Organizations, using account tags for cost allocation, Organizing costs using AWS Cost Categories, CUR 2.0 line item columns and bill columns; Microsoft management groups overview, understand and work with scopes and cost details fields; Google Cloud about resource hierarchy, Create folders, Cloud Billing overview, Structure of Standard data export and Cloud Billing reports.