Shared cloud costs are costs that serve several owners at once and so belong to no single account, tag or team: a central network, security and monitoring platforms, the support plan, a shared cluster or a shared database. For cost allocation they are not a tagging gap, because a tag names exactly one owner. They need a rule that splits them by a key. Left central, teams see only their direct cost, and unit costs and budgets come out lower than the operation that carries them. Split, the key decides who carries how much.
How it works
Shared is whatever several parties use and one pays for: central networks and gateways, security and monitoring services, support plans, commitments whose discount applies across several accounts or subscriptions, and shared clusters and databases. AWS names data transfer, enterprise support and operating costs that several teams incur together; Microsoft describes central subscriptions hosting shared infrastructure whose cost belongs with the teams that use it. Kubernetes clusters follow the same logic one level down, with their own questions about idle capacity and system overhead (Kubernetes cost allocation by namespace and label).
The keys
The FinOps Foundation's Allocation capability sets a shared cost strategy beside the allocation strategy and the tagging strategy. Under it, each shared item is either split or deliberately funded centrally, which the Foundation calls "informed ignore". Splitting uses fixed shares, proportional shares or proxy metrics that approximate consumption.
| Key | Calculation | What it assumes |
|---|---|---|
| Proportional to direct cost | the target's share of all targets' direct cost | The shared service grows with direct consumption. |
| Proportional to a usage driver | the share of requests, gigabytes or CPU hours | The driver measures use of the shared service. |
| Even | the amount divided by the number of targets | Everyone benefits equally. |
| Fixed | agreed percentages | Usage rarely shifts. |
Which key is appropriate is the organisation's decision; none of them changes the provider's invoice. Two things hold for every key: the split shares add up to exactly the shared amount, and the rule is visible to anyone who reads a split figure.
| Provider | Mechanism | Keys | Result visible in |
|---|---|---|---|
| AWS | split charge rules in Cost Categories | proportional, fixed, even split | only the cost category details page and its CSV |
| Azure | cost allocation rules | even, by total, compute, storage or network cost, fixed percentages | cost analysis, budgets, forecasts, exports |
| Google Cloud | built in only for committed use discounts and GKE clusters, otherwise a query over the BigQuery export | proportional or prioritised (commitments), by resource requests (GKE), otherwise any | export and console (commitments), detailed export (GKE), otherwise own tables |
AWS
Split charge rules are part of Cost Categories. The source is a value that collects the shared cost, the targets are other values of the same category, and proportional here means in line with each target's weighted cost. A value can be the source in only one rule and then cannot also be a target; each cost category allows ten split charge rules. Because rules are evaluated top down, AWS recommends moving the values that hold shared cost to the top of the rule list. When editing, the uncategorised remainder (Uncategorized cost) can also be chosen as a source. The limit is visibility: Cost Explorer, the Cost and Usage Report and the other tools show the values unsplit.
Azure
Cost allocation rules move cost from subscriptions, resource groups or tags to subscriptions, resource groups or tags as targets. Compute, storage and network cost mean the cost of resource types in the Microsoft.Compute, Microsoft.Storage and Microsoft.Network namespaces in the current billing month; fixed percentages are whole numbers that add up to 100. Once set, the prefilled percentages stay fixed until someone edits the rule, so a proportional key on Azure is a snapshot. A target with no cost of its own receives nothing. Purchases such as reservations and savings plans cannot be split, the invoice stays unchanged, and the feature is available for Enterprise Agreements and Microsoft Customer Agreements. In exports each split appears as a pair of rows carrying costAllocationRuleName; the Usage Details API and the Power BI connectors do not show it. How rules work in general is covered in virtual tags and allocation rules.
Google Cloud
Google Cloud splits two kinds of shared cost itself: committed use discount fees and credits across projects, in proportion to eligible usage or by an allotment you set, and, with GKE cost allocation, a cluster's cost by namespace and label, calculated from resource requests. For all other shared cost Google names a shared IT cost centre or a proportional split by the number of workloads, calculated over the BigQuery export.
What it means for your cost
A split changes every target's cost and with it its unit costs and its comparison with its budget. The key is therefore agreed and recorded with a date, and a change takes effect from a stated month; on AWS a changed cost category applies from the first of the current month, or retroactively from a chosen start date. A report per owner shows direct and split cost apart, so it stays visible what a team can steer itself. Whatever remains after every rule is reported as a line of its own rather than quietly spread over everyone; unallocated cost covers it.
Because AWS does not write the split into the Cost and Usage Report, a recharge based on export data has to recompute it outside. On Azure the split amounts are in the export and are filtered out for reconciliation with the invoice. Where cost is recharged between legal entities, the tax adviser or auditor decides on the treatment.
Where it goes wrong
- Source and target at once. Symptom: on AWS the platform's cost cannot be split to the teams and onward again. Cause: a value that is the source of a split charge rule cannot be a target, and each value can be a source only once.
- The split expected in the export. Symptom: Cost Explorer and the Cost and Usage Report show different team costs from the cost category details page. Cause: split charges appear only on the details page.
- Stale Azure percentages. Symptom: months later the shares no longer match usage. Cause: the prefilled percentages stay fixed until the rule is edited.
- A reservation stays central. Symptom: a reservation purchase remains in the central subscription. Cause: Azure cost allocation rules do not support purchases.
- A key changed without a date. Symptom: budgets and unit costs jump with no change in usage. Cause: the key was changed without a recorded date, and on AWS the change applies from the first of the current month.
Sources
Read on 2026-10-16. FinOps Foundation Allocation (CC BY 4.0); AWS splitting charges within cost categories, creating cost categories, editing cost categories and quotas and restrictions; Microsoft create and manage Azure cost allocation rules and introduction to cost allocation; Google Cloud attribution of committed use discount fees and credits, GKE cost allocation and manage costs and attributions.