Cloud Cost Allocation Methods for Shared Costs: Untagged Resources, Support, and Data Transfer

Shared cloud costs are allocated with one of four methods: an even split across consuming teams, a fixed percentage agreed in advance, proportional allocation driven by a usage metric, or a proxy metric that stands in when the real driver cannot be measured. The FinOps Foundation documents all four and does not endorse one, because the right choice depends on what you can measure and what your teams will accept. Proportional allocation is the most defensible when a usage driver exists. An even split is the most likely to start an argument.

Every cloud bill has a chunk that belongs to nobody in particular. The shared Kubernetes cluster. The NAT gateway. The support charge. The data transfer that four services caused together. The observability platform that bills on ingested logs from everywhere. Direct tagging handles the easy majority of a bill, and then this remainder sits in an unallocated bucket that quietly grows until finance stops trusting the whole report.

This is the part of allocation that tooling alone does not fix, because the hard question is not technical. It is deciding what counts as fair, writing it down, and getting the teams who will be charged to agree before the first invoice lands on them.

What counts as a shared cloud cost?

A shared cost is any spend consumed by more than one team, product, or customer where the provider gives you a single line item. The usual suspects, in rough order of how often they cause trouble:

• Shared compute platforms. A multi-tenant Kubernetes cluster or an ECS cluster where dozens of workloads share the same instances. The provider bills you for nodes, not for pods.
• Networking. NAT gateways, load balancers, VPN and interconnect, and cross-availability-zone data transfer. Frequently the single largest unallocated line.
• Support and enterprise agreements. Charged at the payer or parent account level, calculated on total spend, and attributable to nobody directly.
• Shared data services. A central data warehouse, a message bus, a logging and observability pipeline, a shared cache.
• Commitment discounts. Reserved instance and savings plan benefits land wherever the billing engine applies them, which is rarely the team that committed to the spend.
• Untagged resources. Not shared in principle, but functionally identical in practice: you cannot attribute them, so they end up in the same pile.

The four cloud cost allocation methods, compared

The FinOps Foundation's Allocation capability states that shared costs can be split "using an appropriate distribution model(s) (proportional, fixed, even-split)" and that allocation "can be performed in a variety of ways including fixed allocations, proportional or by using proxy metrics to determine a variable proportion". That is the whole documented menu. Everything vendors market on top of it is an implementation of one of these four.

Most mature programs run several of these at once rather than picking one. Direct tagging handles the bulk of the bill, proportional handles the shared costs with real drivers, and a fixed or even split handles the small residue where the measurement effort is not worth it.

How do you allocate shared costs to teams fairly?

Match each shared cost to the driver that actually causes it, then charge on that driver. Fairness in practice means a team can look at its charge, understand what it did to earn it, and change its behavior to reduce it. An allocation nobody can act on is just a tax, and teams treat it like one.

That gives a simple test for any rule you write: if a team cuts its usage in half, does its charge drop? If the answer is no, you have chosen the wrong driver. Here is the mapping we would defend for the common cases:

What can AWS and Azure allocate natively?

More than most buyers realize, and less than a full solution. Both clouds shipped shared-cost features that get skipped in vendor comparisons because they do not sell anything.

AWS Split Cost Allocation Data handles the container case specifically. Per the AWS Cost and Usage Report documentation, it introduces cost and usage records for ECS tasks and Kubernetes pods, generating container-level costs "by looking at each container's EC2 instance resource consumption" and splitting on "the amortized cost of the instance and the percentage of CPU and memory resources consumed". For EKS it automatically creates cost allocation tags including aws:eks:cluster-name, aws:eks:namespace, aws:eks:node, aws:eks:workload-name, and aws:eks:workload-type. For accelerated instances it also splits GPU, Trainium, and Inferentia allocation, which matters if you run shared AI training capacity.

The catch is volume. AWS documents that enabling it adds two usage records per task or pod per hour (three for accelerated EKS), and publishes the formula: for EKS, (number of pods x average pod lifetime x 2) x 24 records per day. Their own worked example is 1,000 pods running hourly producing 48,000 new records per day. Your Cost and Usage Report gets substantially bigger, and if you query it in Athena or a warehouse, that shows up in your query bill.

Azure cost allocation rules are the more general tool. Microsoft's Cost Management documentation describes reassigning costs from source subscriptions, resource groups, or tags to target subscriptions, resource groups, or tags, either by manually defined whole-number percentages or "proportionally based on the current usage of the compute, storage, or network across the specified targets". That is the fixed-percentage and proportional methods delivered natively. Two limits worth knowing: the source shows zero cost afterward, which surprises people the first time, and as Microsoft puts it, cost allocation "is simply moving costs around within your billing account to facilitate organizational reporting and chargeback". Your invoice does not change.

Google Cloud has no equivalent reallocation rule engine. The practical route there is the BigQuery billing export plus labels, where you write the split logic yourself as a query. That is more flexible and more work, and it means your allocation rules live in SQL that somebody has to own.

How do you handle untagged resources?

Fix the source first, then cover the remainder with rules. Enforce required tags in your infrastructure-as-code modules so untagged resources cannot be created, which converts an ongoing cleanup task into a one-time backfill. Then apply account or subscription level defaults, and only after that fall back to splitting whatever is left proportionally across teams.

The order matters because rules-based virtual tagging is seductive. It makes the unallocated bucket disappear from the dashboard without anyone fixing the underlying ownership problem, and six months later nobody remembers which numbers are measured and which are inferred. Use it deliberately and label it in your reporting.

Tracking down the owner of a legacy untagged resource is its own small project, usually involving old tickets, a runbook nobody has opened in two years, and a Slack thread from a team that has since reorganized. If that archaeology is a recurring tax on your platform team, being able to search across every internal system at once saves more hours than the tagging work itself. Our full cloud cost allocation tagging strategy covers the enforcement side in detail.

Should shared costs be charged back or left on a central budget?

Leave them central at first, then move to chargeback once your allocation is accurate enough to survive scrutiny. The FinOps Foundation's maturity ladder says exactly this: at the Crawl stage shared costs are "allocated to central budgets or platform teams directly and not charged back to cost centers or business units", at Walk the strategy is documented and applied to multiple elements of shared cost, and at Run organizations reach full allocation with automation and shared costs clearly distinguished from dedicated ones.

That sequencing exists for a political reason, not a technical one. The first time you charge a team for shared infrastructure, they will challenge the number. If you cannot explain the rule in one sentence and show the underlying usage, you lose the argument and the program stalls. Showback buys you the months needed to get the rules right while nobody's budget is on the line. We wrote up the difference and the transition in showback vs chargeback.

How do you allocate reserved instance and savings plan discounts?

Allocate on amortized cost, not on the invoice line. Commitment discounts get applied by the billing engine to whichever eligible usage runs at the time, so a team that never committed to anything can receive a discount another team paid for, and the same team's costs will swing month to month for reasons entirely outside its control.

Amortization spreads the upfront and recurring commitment cost evenly across the term and across the usage that consumes it, which produces a number a team can be held to. The alternative, keeping the benefit centrally and charging teams at on-demand rates, is defensible too and funds the central team that takes the commitment risk, but you have to say which model you use out loud. Teams discovering it by accident in a budget review is how FinOps programs lose credibility. The tradeoffs are covered in reserved instances vs savings plans.

What percentage of a cloud bill is typically shared?

There is no reliable published figure, and be skeptical of anyone who quotes one to two decimal places. The share varies enormously with architecture: a company running a few large multi-tenant Kubernetes clusters can have most of its compute bill in shared infrastructure, while a company with one account per product and little cross-team networking may have very little. Vendor blogs cite precise-sounding percentages for unallocated spend, but these are almost always drawn from that vendor's own customer base, which is self-selected for having an allocation problem worth buying software to solve.

Measure your own. Sum the spend that carries no owner-identifying tag, add the line items you know are shared platforms, and divide by total spend. That single number is the honest baseline for your program, and watching it fall is a better metric than any industry benchmark.

Where to start this quarter

Pick the three largest shared line items on last month's bill and write one sentence for each describing how it will be split and on what driver. Circulate those three sentences to the teams who will be charged and take the argument now, while it costs nothing. Then implement them, in native tooling if it covers your case or in a platform if it does not, and report the result as showback for a full billing cycle before any money moves.

Three rules that people understand beats twenty that nobody can explain. If you want to see what the tooling side of this looks like, our comparison of cloud cost allocation software covers how each platform handles untagged and shared spend specifically, which is the only feature question in this category that reliably separates the tools. Costanalyst connects your AWS, GCP, and Azure billing read-only and allocates cloud and SaaS spend together, from 99 dollars a month.