When we run cost assessments, one pattern shows up more than almost any other: a single subscription consuming roughly half the entire Azure spend. Sometimes more.
It is not unusual. It is not always wrong. But it is always worth investigating, because it usually points to deeper problems with architecture, governance, and cost visibility.
How It Happens
Nobody sets out to dump everything into one subscription. It happens gradually.
Organic growth. The organisation started with one subscription. The first workloads went there. Then the next few. Then someone needed a quick deployment and picked the existing subscription because it already had the networking and the permissions. Before anyone noticed, it became the default.
The production dumping ground. A subscription called "Production" becomes the home for everything production-related — web apps, databases, analytics, batch jobs. If it is production, it goes in production.
Shared infrastructure accumulation. Hub networking, centralised logging, security tooling, backup vaults — they all need to live somewhere. They gravitate to whichever subscription was set up first.
Over time, these forces pull costs into the same place. The result is one subscription at 40–60% of total spend, with everything else barely registering.
Why It Matters
Budget risk. When one subscription holds half your spend, a single team's mistake can blow the entire cloud budget. An accidental oversized deployment or a runaway pipeline impacts the whole organisation, not just one project.
Limited visibility. Answering "how much does Project X cost per month?" is nearly impossible when it shares a subscription with 15 other projects and shared infrastructure. Tags help, but tagging discipline is rarely perfect.
Blast radius. A misconfiguration or security incident affects everything in the subscription. If your production app, database, monitoring, and hub networking all share one, a single overly broad permission puts everything at risk.
Meaningless alerts. Budget alerts on a subscription that contains everything tell you nothing about which workload is responsible. You end up ignoring them entirely.
The Hub Subscription Trap
The hub subscription deserves special attention. Shared networking infrastructure — firewalls, connectivity gateways, DDoS protection, central logging — can easily reach five figures per month before a single workload subscription has spent a penny. That is not waste, but it creates all the governance and visibility problems above.
What To Do About It
You do not need to rearchitect overnight. Start with visibility.
Tag everything. Even within a single subscription, consistent tagging transforms cost attribution. At minimum: cost centre, environment, project, and owner.
Separate dev/test from production. The single highest-impact change with the lowest risk. Dev/test subscriptions get reduced pricing, separate budgets, and reduced blast radius.
Adopt a subscription topology. Microsoft's landing zone architecture separates concerns into purpose-built subscriptions — management, connectivity, identity, and workload subscriptions. You do not need the full framework overnight, but understanding the pattern helps.
Set meaningful budgets. Once concerns are separated, budgets become useful. A budget on a workload subscription tells you exactly when that workload is overspending. That is an actionable signal.
The key insight is that cost concentration is not just a FinOps problem — it is an architecture and governance problem that shows up in your bill first.
Wondering where your Azure spend is really going? Get a free FinOps assessment — we break down cost concentration across your subscriptions and identify where structural changes would save money.