Cloud cost allocation: methods, tags, shared costs and examples

Why allocation comes before everything else

Forecasts, budgets, chargeback and unit costs all inherit the allocation. A forecast per department is only as good as the split of last year’s bill into departments. A unit cost for a product is the product’s allocated cost divided by its volume. If the allocation is wrong or incomplete, every number downstream is wrong in the same way, which is why FinOps practitioners consistently rank allocation among the capabilities they prioritize most in the FinOps Foundation’s State of FinOps surveys, ahead of further optimization.

The cost of getting it wrong is visible at budget time. Flexera’s 2025 State of the Cloud report found organizations exceeding their public cloud budgets by 17% on average. Part of that gap is spend nobody forecast because nobody owned it: the unallocated remainder, the shared platform that grew, the commitment that went unused. Allocation is how those costs acquire an owner who can act.

The three methods, in order

The methods form a hierarchy. A cost is allocated by the first method that applies, and moves down the list only when the one above cannot place it.

1. Direct allocation. The cost has one identifiable owner: it sits in an account, subscription, project or resource group mapped to that owner, or it carries a tag or label that names the owner. A virtual machine in the payments team’s account is the payments team’s cost. Direct allocation should cover the majority of the bill; the share it covers is the best single measure of how well the account structure and tagging are working.
2. Proportional allocation. The cost is shared and there is a measured driver that says how much each tenant used: requested CPU and memory on a Kubernetes cluster, bytes scanned on a data warehouse, requests through an API gateway, or each consumer’s own direct spend for a support plan priced as a percentage of the bill. The driver must be measured for the same period as the cost, and it must be one the tenants recognize as fair.
3. Fixed allocation. The cost is shared and there is no sensible driver, or the amount is too small to justify one: a security scanner licensed for the whole estate, a shared DNS zone, an organization-wide monitoring plan. The cost is split by percentages the recipients agreed to in advance, reviewed on a schedule, and never adjusted mid-period.

What none of the three can place is reported as unallocated, by cause: missing or invalid tag, unmapped container, or a provider-level charge such as a credit or a tax line. Reporting it honestly is what keeps the rest of the model credible; spreading it evenly across everyone is the fastest way to lose that credibility.

Cost allocation tags: what works on each provider

Across all three, the container is more reliable than the tag. An account, subscription or project has exactly one owner by construction and cannot be forgotten at deploy time. Tags carry the finer dimensions, such as product or environment, inside a container that already has an owner. Organizations that lean on containers for the first dimension and tags for the second reach a high allocated share far faster than those that try to tag everything.

Worked example: one slice of a month across three clouds

The figures below are illustrative. They show how a $70,500 slice of a monthly bill lands on owners when the three methods are applied in order, and what the unallocated remainder looks like when it is reported rather than hidden.

Three things to notice. The largest line is placed by the account, not by a tag. The shared cluster is split by a driver the three tenants can see in their own dashboards. And the unallocated line names its cause and a count of resources to fix, which turns it from an embarrassment into a task.

Shared cost allocation: choosing the driver

A driver is fair when the tenants can influence it and can see it. These are the defaults that hold up in practice.

• Kubernetes and container platforms: requested CPU and memory by namespace, with idle capacity carried by the platform budget so that tenants are charged for what they asked for, not for the platform’s headroom.
• Shared data platforms: bytes scanned, slot or credit consumption, or storage by dataset owner, whichever the platform reports per tenant.
• Networking and egress: bytes by owner where the provider reports them; an agreed fixed split otherwise.
• Observability, logging and security tooling: ingested volume where the tool reports it; a fixed split where it does not.
• Support plans and enterprise agreements: each consumer’s direct spend, because that is how the provider prices them.
• Central FinOps, architecture and shared tooling: not allocated; reported as a budget of its own and reviewed on its own merits.

Commitments, credits and refunds

Reserved capacity, savings plans and committed-use discounts are bought centrally and applied by the provider to whatever usage matches. Left alone, the discount lands on whichever account happened to match first, and nobody sees the saving. The allocation that holds up is to charge covered usage at the discounted rate to the consumer whose usage was covered, and to carry unused commitment centrally as the cost of the decision to commit, reported to procurement as its own line.

Credits, refunds and one-off adjustments arrive at the billing-account level. They are allocated proportionally to the consumers whose spend generated them where the provider says which usage they relate to, and otherwise held centrally and reported, never silently netted against the largest consumer.

Allocating on more than one dimension

Finance wants cost by cost center. Product wants cost by product. Sales wants cost by customer. These are different dimensions of the same spend, not competing allocations, and the model should carry all of them on every line. A line in the payments account, tagged product “checkout”, serving customer “Acme” through a shared cluster, has a cost center, a product and a customer at once.

The rule that prevents double counting is simple: each dimension allocates 100% of the bill independently. The cost-center view and the product view each sum to the invoice. What is not allowed is allocating a line to a cost center and then allocating part of it again to a product as if it were extra spend. Tooling that treats dimensions as columns on one ledger gets this right by construction; a spreadsheet per dimension does not.

Measuring allocation quality

• Allocated share: the percentage of the invoice placed by a direct, proportional or fixed rule, tracked every period. The template on this site suggests starting with a target of no more than five percent unallocated.
• Direct share: the percentage placed by direct allocation alone. A rising direct share means the account structure and tagging are improving; a rising proportional share means more of the estate is becoming shared.
• Tag and container coverage: the share of resources with a valid owner, by provider.
• Time to allocate: how many working days after the invoice the statements are out. Five is a good target.
• Disputes per statement, and how many were resolved from the drill-down without a rule change.

Common mistakes

• Tagging first, mapping later. Containers give the first dimension for free; tags are for the second.
• Spreading the unallocated remainder. Every team’s number becomes slightly wrong and nobody can say by how much.
• Choosing a precise driver over a fair one. A driver the tenants cannot see or influence produces disputes every month.
• Allocating commitments to whoever matched. The saving becomes invisible and the commitment decision is never evaluated.
• Changing rules mid-period. Rule changes apply from the next period, with both treatments shown once.
• Building it in a spreadsheet. It reconciles once, by hand, and then never again.

How Runcost does allocation

Runcost applies the three methods as ordered rules over one ledger built from the AWS, Azure and Google Cloud billing exports. Accounts, subscriptions, projects and tags map to cost centers, products and customers, shared services carry their drivers, and commitments are allocated to covered usage. Every dimension sums to the invoice, the unallocated remainder is reported by cause with the resources to fix, and any statement line drills to the resources and the rule that produced it.