Home/Library/Shared-Services Allocation
How-to · Azure · Governance · Updated May 2026

Azure Cost Allocation for Shared Services and Platform Teams

Direct costs are easy to attribute. The hard part is the shared layer: the platform team, the shared AKS cluster, networking, observability, the things every product depends on but no single team owns. Leave it unallocated and your showback is a fiction. Allocate it well and accountability finally reaches the platform.

Azure cost allocation for shared services means distributing the cost of platform, networking, and observability resources, which no single product team owns directly, across the teams that consume them, using a usage-based key where you can measure consumption and a proportional key where you cannot. Without it, shared spend either hides in an unallocated bucket or lands entirely on the platform team, and neither reflects who is actually driving the cost.

This article is part of our Azure cluster. For the broader picture, start with the complete guide to Azure cost optimization, the pillar this piece links up to. Allocation is the heart of the See step in our See, Cut, Lock, Run method: every dollar needs an owner before any of the other steps can hold.

Start from a working tagging and hierarchy model

Allocation only works on top of clean attribution. Before you split anything shared, your direct costs should already be mapped to teams through tags, subscriptions, and management groups, the foundation covered in Azure tagging and management groups for cost allocation. Once direct spend is attributed, what remains is the shared pool: resources tagged to a platform or shared cost center rather than a product. That pool is what this allocation exercise distributes.

Choose an allocation key per shared cost

There is no single right way to split shared cost; there is a right key for each type. The principle is to use the most direct measure of consumption you can get, and fall back to a proportional key when you cannot measure directly.

Shared costAllocation keyWhy
Shared AKS clusterNamespace CPU and memory usageDirectly measurable per team
Observability platformLog volume or ingestion by sourceTracks who generates the data
Networking and egressTraffic by subscription or subnetMaps to the workloads using it
Platform team overheadProportional to each team's direct spendNo direct usage signal available
Shared licenses and toolingHeadcount or seat countConsumption scales with people

Usage-based keys are fairer and harder to argue with, which is why they drive better behavior: a team that sees its own AKS namespace usage on its bill has a reason to right-size it. Proportional keys are simpler but blunter, so reserve them for genuinely indivisible overhead. For the shared Kubernetes case specifically, the namespace-level breakdown in AKS cost optimization: node pools, spot, and autoscaling is what makes usage-based allocation possible.

Shared and platform costs landing in a black hole?

Our Azure engagements build the allocation model, pick a defensible key for each shared cost, and deliver showback every team accepts, so platform spend finally has owners. On the performance model, you pay only from realized savings. No savings, no fee.

Book an Azure cost audit →

Handle the unallocated bucket honestly

Some cost will resist allocation: a genuinely fixed platform commitment, spend that predates your tagging, resources nobody will claim. Do not force a false precision onto it. Keep a clearly labeled unallocated bucket, track its size as a metric, and drive it down over time. A healthy allocation model is not one where everything is split to the cent; it is one where the unallocated share is small, shrinking, and visible. A growing unallocated bucket is a signal that tagging is slipping, which loops back to the governance discipline in the tagging guide.

Turn allocation into showback that changes behavior

Allocation is only worth the effort if someone sees the result and acts on it. Build a monthly showback that gives each team its fully loaded cost, direct spend plus its share of the shared layer, in terms they recognize. Showback, reporting cost back to teams without an internal charge, is usually enough to change behavior; full chargeback, billing teams internally, adds accountability but also overhead and politics, so most organizations start with showback and only move to chargeback when the culture is ready. Either way, pair the number with the levers a team can pull, and connect it to the budgets and alerts in Azure budgets and cost alerts: a setup guide so each team manages its allocated total.

The allocation mechanisms available in Azure Cost Management, including cost allocation rules for splitting shared costs, reflect the platform as of May 2026. Verify the current allocation-rule capabilities and any limits in Microsoft's Azure Cost Management documentation before you build your model on them.

Go deeper · free guide

The Azure Cost Optimization Field Guide includes our shared-cost allocation key matrix and the showback report template we use on engagements. It is the downloadable companion to this article.

The short version

Shared and platform costs are the hardest part of Azure allocation, but leaving them unallocated breaks every team's bill. Build on clean direct attribution, pick a usage-based allocation key for each shared cost where you can measure consumption and a proportional key where you cannot, keep an honest and shrinking unallocated bucket, and deliver monthly showback that shows each team its fully loaded cost. To forecast against those allocated totals, see how to forecast Azure spend. When you want the allocation model and showback built for you, that is exactly what our Azure cost optimization service delivers.

The Cloud Cost Brief

Cloud pricing moves. We tell you when it matters.

New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.

Subscribe · Work email only