When Azure costs sit in a central IT budget with no visibility into who is spending what, nobody feels responsible for them. Engineers make infrastructure decisions without understanding the financial consequences. Finance reports a number to the board that nobody on the technical side can explain. And the FinOps team — if there is one — spends most of their time doing forensic accounting instead of driving improvement.
Cost allocation is the process that fixes this. It takes your total Azure spend and distributes it to the teams, products, business units, or cost centres that are actually driving it — creating the accountability structure that makes FinOps work in practice. This page covers how to build that model, what decisions you'll need to make along the way, and how Turbo360 Cost Analyzer supports the process.
Showback vs Chargeback — What's the Difference?
These two terms are often used interchangeably but they describe meaningfully different models, and choosing the right one for your organisation matters.
Showback | Chargeback | |
|---|---|---|
What happens | Teams are shown what their Azure spend is, for information and awareness | Teams are billed internally for their Azure spend — it comes out of their own budget |
Financial impact on teams | None directly — spend sits in a central IT budget | Direct — overspending reduces the team's own budget allocation |
Accountability strength | Moderate — creates awareness but limited consequence for overspend | Strong — teams have a direct financial incentive to manage their spend |
Organisational complexity | Low — reporting only, no internal billing process required | High — requires finance processes, internal billing systems, and agreement on allocation rules |
Best for | Starting out; organisations where internal billing is not culturally accepted | Mature FinOps organisations; teams that own their own P&L |
Where to start: Almost all organisations should begin with showback. It creates visibility and accountability without requiring a complex internal billing infrastructure. Many organisations stay at showback permanently and get excellent results. Chargeback adds real financial teeth but also real organisational friction — make sure you have the maturity and executive backing before moving to it.
The Three Layers of Cost Allocation
Cost allocation in Azure typically works across three layers, each offering a different degree of precision. Most organisations use a combination of all three.
Layer 1 — Subscription and resource group structure
If each team or product has its own Azure subscription, you get cost separation almost for free — the billing data is already partitioned. This is the cleanest model and the one the Azure landing zone guidance tends to recommend. The limitation is that most organisations don't have perfectly separated subscriptions — shared services, platform infrastructure, and legacy workloads complicate the picture.
Resource groups within a shared subscription give you a second level of separation without full subscription isolation. Costs can be filtered by resource group in Azure Cost Management, making resource group design a useful allocation lever even without separate subscriptions.
Layer 2 — Tags
Tags fill the gaps that subscription and resource group structure can't address. They let you allocate costs across subscription boundaries (useful for shared services used by multiple teams), split costs within a resource group (when multiple teams share one), and track spending by dimensions that don't map to your Azure hierarchy — project, product line, customer segment.
Tags are the most flexible allocation mechanism, but also the most dependent on discipline and enforcement. If your tagging coverage is incomplete or inconsistent, your allocation model will have gaps. See the Tagging Strategy page for guidance on building a tag schema and enforcing it.
Layer 3 — Cost allocation rules
Some costs can't be tagged directly to a team or business unit because they're genuinely shared — networking infrastructure, security services, shared Kubernetes clusters, Azure Monitor. Cost allocation rules let you distribute these shared costs across teams using a formula rather than direct attribution.
Common distribution methods for shared costs:
Equal split — divide the shared cost equally across all teams. Simple but often unfair.
Proportional split — divide based on each team's share of total Azure spend. Teams that spend more pay more of the shared infrastructure cost.
Usage-based split — divide based on actual consumption metrics (e.g. node hours in a shared AKS cluster, API calls through a shared APIM instance). Most accurate but requires usage data.
Fixed allocation — assign a fixed percentage of shared cost to each team, agreed in advance. Transparent and predictable even if not perfectly accurate.
Architect's Perspective — Building an Allocation Model That Works
Start with the questions you need to answer
Before designing your allocation model, be clear on what decisions it needs to support. "Which team is spending the most?" requires team-level allocation. "Is our customer portal profitable?" requires product-level allocation including a share of shared infrastructure. "Which Azure region is costing us the most?" requires regional grouping. Different questions require different allocation models — trying to build one model that answers every possible question usually results in one that answers none of them well.
Accept that allocation will never be perfect
Every allocation model involves approximation. Shared costs distributed by formula are not the same as direct attribution. Tags that aren't applied to 100% of resources leave gaps. Costs that can't be tagged at all (some platform services, networking, support charges) require estimation. The goal is an allocation model that's accurate enough to be useful and fair enough to be trusted — not one that's mathematically perfect.
Don't let perfect be the enemy of useful. A common mistake is delaying the rollout of showback reporting until the tagging coverage is perfect, the shared cost methodology has been agreed in exhaustive detail, and every edge case has been resolved. In practice, this means showback never happens. Start with the coverage you have, communicate the limitations clearly, and improve the model iteratively.
Agree the methodology before publishing numbers
When you show a team their Azure bill for the first time, the instinctive response is often to challenge the numbers. "That can't be right — we don't use that much." If your methodology hasn't been agreed in advance, you'll spend your first showback conversation defending your model rather than having a productive discussion about the spend. Get buy-in from engineering leads and finance on the allocation approach before publishing reports.
Handle shared costs transparently
Whatever method you use to distribute shared costs, document it and make it visible. Teams that feel costs are being allocated to them arbitrarily or unfairly will disengage from the process. A shared cost that's transparently split using a documented formula — even an imperfect one — is more credible than a black box allocation that produces numbers nobody can explain.
Design your subscription structure with allocation in mind
If you have the opportunity to influence how your Azure environment is structured — a new landing zone, a migration project, a significant reorganisation — build cost allocation into the design from the start. The easiest allocation model is one where subscription boundaries map to your organisational accountability boundaries. Every deviation from that ideal (shared subscriptions, cross-team resource groups) adds complexity to your allocation model. The cost of getting the structure right early is almost always lower than the cost of building allocation logic to compensate for a poorly structured environment later.
Implementing Showback Reporting
A practical showback implementation typically involves three components:
1. A consistent cost view per team
Each team should receive a regular cost report showing their Azure spend for the period — broken down by resource group, service type, or whatever level of granularity is useful to them. This can be delivered via scheduled email reports from Azure Cost Management, a shared dashboard, or a tool like Turbo360 that provides team-scoped views. The format matters less than the consistency — reports that arrive on the same day each month with the same structure get read. Ad-hoc reports sent when someone remembers to send them don't.
2. A shared cost allocation statement
In addition to their direct spend, each team should see their allocated share of shared infrastructure costs. This is the part that most showback implementations get wrong by either ignoring shared costs entirely (leaving a significant portion of spend unaccounted for) or dumping the entire shared infrastructure cost into one team's report.
3. A monthly review conversation
Reports alone don't drive action. A monthly cost review — even a short one — where teams walk through their spend, explain any changes, and identify upcoming changes that will affect cost is what turns visibility into accountability. See the FinOps Principles page for guidance on how to structure this.
Moving from Showback to Chargeback
If your organisation decides to move to chargeback, there are several things to get right before the first internal bill goes out:
Executive sponsorship is non-negotiable. Chargeback changes how budgets are managed across the organisation. It will face resistance. Without clear leadership mandate, it won't stick.
Run showback first, for at least one quarter. Teams need to see the numbers, understand what's driving them, and have the opportunity to optimise before they're financially accountable for them. Chargeback that lands without warning is deeply unpopular and counterproductive.
Define the rules clearly and in writing. What's included in the chargeback? How are shared costs allocated? What period does each bill cover? What's the process if a team disputes a charge? Every one of these questions will be asked and you need answers ready.
Integrate with existing finance processes. Chargeback amounts need to flow into your finance system — updating team budgets, generating journal entries, or feeding into your internal billing platform. This is the infrastructure investment that makes chargeback operationally viable.
Start with direct costs only. Include shared cost allocation in showback from the start, but consider delaying it from chargeback until the methodology is well-established and trusted. Charging a team for a share of infrastructure they can't see or control creates conflict.
How Can Turbo360 Cost Analyzer Help?
Turbo360 Cost Analyzer is built to support the full cost allocation workflow — from establishing team-level visibility through to generating the reports that drive showback and chargeback conversations.
Team and department cost views
Cost Analyzer lets you build cost views segmented by subscription, resource group, tag, or any combination — giving each team their own lens on Azure spend without requiring them to navigate the Azure portal. These views can be shared with team leads and finance stakeholders directly, removing the need to manually build reports from raw cost data.
Tag-based allocation
If your tagging strategy is in place, Cost Analyzer can use tag values to allocate costs across any organisational dimension — team, product, project, cost centre. Resources tagged Owner: platform-team and Project: customer-portal can be sliced and reported on independently, giving you multi-dimensional allocation without duplicating data.
Regular reporting for showback
Schedule regular cost reports to be delivered to team leads and stakeholders, in a format they can understand without Azure expertise. Consistent delivery builds the habit of cost review into the team's regular rhythm — which is what creates the cultural change FinOps depends on.
Multi-tenant allocation
Turbo360 provides the multi-tenant cost visibility and reporting needed to produce accurate cost statements.
FAQ
What's the difference between cost allocation and cost optimisation?
Cost allocation is about visibility and accountability — understanding who is spending what and making sure the right people can see it. Cost optimisation is about reducing spend — rightsizing, reservations, waste elimination. Allocation comes first. You cannot meaningfully optimise costs that haven't been allocated to an owner, because there's nobody accountable for acting on the recommendations.
What do we do about Azure costs that can't be tagged?
Some Azure costs don't attach to resources that can be tagged — support charges, marketplace purchases, some networking costs. These need to be handled through allocation rules at the account or subscription level. A common approach is to pool them into a "platform" or "shared" cost category and distribute them proportionally across teams based on their share of total direct spend. Document whatever method you use so teams understand why they're seeing shared charges in their reports.
How granular should our allocation model be?
As granular as the decisions you need to support — no more. Team-level allocation is enough for most FinOps accountability purposes. Product or project-level allocation is useful when you need to understand the economics of specific initiatives. Resource-level allocation is rarely worth the overhead for showback purposes, though it's useful for investigation when a team is trying to understand what's driving their bill. Start at team level and add granularity if there's a specific question it would help answer.
How do we handle costs for resources that multiple teams share?
Choose a distribution method, document it, and apply it consistently. Equal split, proportional split (based on direct spend), or usage-based split (based on actual consumption) are the three main options. The right choice depends on how the shared resource is actually consumed and how much effort you're prepared to put into measuring usage. For most shared infrastructure, proportional split based on total direct spend is a reasonable default — it's simple, auditable, and scales teams pay more as they grow.
Our teams are pushing back on their showback numbers. What do we do?
Pushback on showback numbers usually has one of three causes: the numbers are wrong (allocation methodology issue), the numbers are right but surprising (discovery moment — the team didn't know they were spending that much), or the numbers are right but the team feels they've been allocated costs they don't control (shared cost methodology issue). Diagnose which it is before responding. If the methodology is sound and the numbers are correct, the right response is to help the team understand what's driving the spend and work with them on a plan to address it — not to adjust the numbers to avoid the difficult conversation.
Useful Resources
Turbo360 blog posts
Related playbook pages
Microsoft documentation