The tolerated pain
Cloud resources are easy to create and consumption changes continuously. Without an ownership taxonomy, finance sees spend while operational teams see resources, and neither side can reliably connect the two.
The monthly invoice may be accurate to the cent and still answer none of the questions the business actually has. Which product drove last month's increase? How much does this customer cost to serve? Is the test environment still needed? When spend cannot be traced to a business owner, those questions have no one to answer them.
Why businesses tolerate it
Allocation is usually postponed rather than rejected. Early in a cloud journey the bill is small and one engineer understands everything. Resources are created quickly to meet deadlines, and naming or tagging conventions feel like overhead. By the time the bill is material, there are hundreds of untagged resources, several accounts or subscriptions with mixed purposes and shared platforms that serve everyone.
Tagging also has to be designed and switched on deliberately. AWS's documentation on user-defined cost allocation tags explains that tags must be created, applied to resources and then activated in the Billing and Cost Management console before they can be used for cost tracking, and recommends a consistent set of tag keys that reflects how the organisation wants to organise its costs. Allocation does not happen by default.
Operational consequence
Optimisation discussions become generic. Nobody knows which owner should justify a cost increase, which environment is safe to resize, or which customer and product economics depend on the resource.
- Stalled clean-up: engineers hesitate to delete a resource they cannot identify, so idle resources survive. See the waste of unused cloud resources.
- Blame without action: finance asks why spend rose; engineering says usage grew; nobody can say whose usage.
- Manual investigation: someone spends days each month working through the bill line by line.
- Unpriced decisions: product and pricing decisions are made without knowing the infrastructure cost behind them.
The related pain of cloud costs rising without explanation is often the moment this becomes visible.
Financial consequence
The first loss is weak accountability: unowned cost is difficult to challenge. The second is distorted economics when shared infrastructure is not attributed to the services it supports.
unallocated cloud rate = unassigned cloud spend ÷ total cloud spend
Track the percentage over time. The target does not need to be zero if some shared cost is genuinely common, but unexplained cost should be visible.
An illustrative cost model
All figures are illustrative assumptions. Replace them with your own billing data.
| Monthly cloud spend | Illustrative amount | Share of total |
|---|---|---|
| Allocated to a team, product or environment | R510,000 | 60% |
| Shared platform cost (genuinely common, not yet apportioned) | R120,000 | 14.1% |
| Unexplained (no owner, no tag) | R220,000 | 25.9% |
| Total | R850,000 | 100% |
The unallocated cloud rate is (R120,000 + R220,000) ÷ R850,000 = 40%.
Accountability loss. Assume, illustratively, that 20% of the unexplained spend is idle or orphaned: forgotten test environments, old snapshots, oversized instances. That is 20% × R220,000 = R44,000 a month, or R528,000 a year, that persists mainly because nobody owns it.
Margin distortion. Now assume a product line earns R400,000 a month in revenue and its tagged cloud cost is R60,000, which suggests infrastructure consumes 15% of its revenue. If, in fact, that product drives half of the R340,000 unallocated pool, its true monthly cloud cost is R60,000 + R170,000 = R230,000, or 57.5% of revenue. The product may look healthy on the visible numbers and be marginal or loss-making on the real ones. That kind of error affects pricing, sales focus and investment decisions far beyond the cloud bill itself.
What the model leaves out
The model counts only two effects. It does not include the staff time spent each month investigating the bill manually, the commitment discounts that go unused because nobody can forecast which workloads will persist, or the delay in spotting a runaway resource when no owner receives the alert. Each of these depends on the business, and none should be assumed. They are, however, all reduced by the same fix: making every material cost belong to someone who understands why it exists.
It is also worth being clear about what allocation does not do. Tagging a resource does not make it cheaper. Allocation creates the conditions for good decisions by putting the right cost in front of the right person; the saving comes from what that person then chooses to resize, schedule, retire or reprice.
Urgency
Commercial trigger
If a meaningful cloud increase cannot be traced to a business owner or workload, cost governance is operating after the bill rather than inside the architecture.
The trigger is sharper when cloud spend is growing faster than revenue, when the business sells per-customer or per-product services whose margins depend on infrastructure, when a pricing review is under way, or when a commitment discount or reserved capacity purchase is being considered without knowing which workloads will use it.
Resolution
The FinOps Foundation's Allocation capability describes three linked strategies: an allocation strategy mapping cost to organisational units, a tagging strategy defining how resources are named and grouped, and a shared-cost strategy for distributing common expenses through fixed, proportional or proxy-based methods. It describes maturity moving from a stage where many costs remain untagged and need manual investigation each month, to one where costs can be allocated at any required granularity with minimal unidentified spend.
- Define a small mandatory ownership taxonomy.
- Apply cost allocation at account, subscription, project or resource level as appropriate.
- Separate production, development and shared services.
- Review unallocated spend as an exception.
- Give owners visibility before optimisation decisions are made.
- Connect significant platform cost to product and customer economics where feasible.
A practical starting taxonomy is four keys: owner, application or product, environment and cost centre. Enforce them when resources are created rather than chasing them afterwards, and agree one documented rule for splitting shared platform cost. Mellorca's Digital Infrastructure work can help design that structure into the cloud estate.
Bottom line
You cannot manage cloud economics well when you can only see the total. Allocation turns infrastructure spend into an accountable operating input. Once every material cost has an owner, idle resources get challenged, increases get explained and product margins reflect what the business actually spends to deliver them.
Sources and further reading
- Using user-defined cost allocation tags - AWS Billing (last verified 10 October 2026)
- Allocation FinOps Framework Capability (last verified 10 October 2026)