Nobody designs a tenant with sixty subscriptions. It accumulates one defensible decision at a time. A project needs isolation, so it gets its own subscription. A vendor needs access on a Friday afternoon, so someone grants Owner because Contributor threw a permissions error and everyone wanted to go home. A proof of concept gets built in the portal because writing Bicep felt heavy for a demo, and three years later that demo is processing invoices, and there is no template because there never was one.
Most tenants we meet in our Azure work share this biography. Subscription-per-project became the default because subscriptions were the only isolation boundary anyone trusted. Owner got handed out because diagnosing RBAC errors is slower than escalating past them. Portal-built resources survived because they worked, and working systems do not get rebuilt as code. They get inherited.
None of this was incompetence. Each decision was a reasonable trade made under deadline, which is exactly what makes sprawl a debt rather than a mistake. The interest compounds quietly, and it gets collected in two currencies.
Sprawl bills you twice
The first bill is cost you cannot attribute. When workloads share subscriptions and tagging is voluntary, the monthly invoice is one number with no owner. Finance asks what the recommendation engine costs, and answering requires an archaeology project. Our cloud cost optimization engagements stall on this more often than on any technical problem. You cannot cut spend you cannot assign, and you cannot assign spend when the boundaries mean nothing.
The second bill is the changes nobody dares make. Every aging tenant has a subscription with a VNet peered to production and no known owner. Deleting it might save money. It might also take down something named legacy-integration-02 that turns out to feed payroll. So it stays, and so does everything like it. Fear has a run rate. It just never appears in Cost Management.
A structure ten people can maintain
Management group designs fail in a predictable way: they mirror the org chart, and the org chart will not sit still. Design for policy inheritance instead, keep it shallow, and resist the urge to make it interesting.
Tenant Root
└── org baseline: allowed regions, required diagnostics
├── platform identity, connectivity, shared services
├── workloads
│ ├── prod strict policy, no public endpoints, change control
│ └── nonprod budget alerts, auto-shutdown, looser SKUs
└── sandbox hard spend caps, resources expire by policy
Three levels below root. Policy assignments live in a repo and change by pull request, the same way we hand over every engagement. A subscription lands in exactly one place, and if deciding where requires a meeting, the tree is too clever for the team that has to run it.
Here is the claim some readers will dislike: subscriptions are policy and billing boundaries, not team boundaries, and subscription-per-team is how you got here. Give a team a resource-group-scoped role inside a shared subscription and most of the isolation argument evaporates. The genuine exceptions (separate blast radius, regulatory separation, quota walls) are real, but they are rarer than your subscription count implies.
Clean up RBAC in this order
The order matters more than the tooling.
- Export every role assignment at every scope. The direct assignments to individual humans are your debt register. Expect the list to be embarrassing.
- Create Entra groups per role per scope and assign roles to the groups. People join groups. Access stops changing every time someone joins, leaves, or moves teams.
- Put privileged roles behind PIM. Owner, User Access Administrator, and anything broad at management group scope become eligible rather than active, time-bound, with justification on activation.
- Only then remove the direct assignments. Removing access before the replacement path exists is how cleanups get quietly reverted within a month.
Standing Owner held by humans should end at zero. Not the platform lead, not the CTO. Break-glass accounts and PIM activation cover the genuine emergencies. Engineers will say this adds friction, and they are right. The friction is the control.
When not to reorganize
Mid-migration, leave the tree alone. Moving a subscription between management groups changes its effective policy set, and doing that while workloads are in flight means every incident has two suspects. Finish the migration, then move the boxes.
The same goes for the run-up to an audit. Assessors want a stable control environment and evidence that maps to it. A governance re-org six weeks before evidence collection means explaining every diff in the assignment history to someone paid to be suspicious. Reorganize after the report is signed, not before.
And if the current structure is ugly but the policies bind and the spend is attributable, weigh what a re-org buys beyond aesthetics. Governance debt is measured in unattributable cost and unmakeable changes, not in how the diagram looks on a slide.
The tenants in the worst shape are rarely the neglected ones. They belong to teams that reorganized twice, each time to match an org chart that no longer exists, each time stopping partway through. Sprawl is not the absence of governance. It is the fossil record of every governance initiative that ran out of quarter.