Azure sprawl usually starts with well-intentioned subscription creation and ends with inconsistent policy, identity exceptions, and networking nobody owns.
Use Management Groups as the spine: platform, landing zones, and sandboxes with Azure Policy initiatives that encode your real standards—not every built-in policy at once. Connect Entra ID with clear PIM and break-glass paths.
Hub-spoke networking, private endpoints where needed, and centralized Log Analytics give ops and security a shared view. Treat landing zone modules (CAF-aligned or custom Terraform) as versioned products, not one-off ARM experiments.
When Azure foundations are explicit, product teams move faster because exceptions become rare and auditable.
Align subscription design with blast radius: shared platform services, corp connectivity, and workload landing zones should fail independently when possible.
Make private connectivity and DNS patterns part of the landing zone definition so every app team does not reinvent hub access.
Version your CAF-aligned or custom Terraform modules and publish upgrade notes the same way you would for an internal product.
Key takeaways
- Use Management Groups as the policy spine—not a folder dump of subscriptions.
- Roll out Azure Policy in layers; avoid enabling every built-in initiative on day one.
- Pair Entra ID PIM with hub-spoke networking and centralized Log Analytics.
FAQ
How many Management Groups do we need?
Enough to express platform, landing zones, and sandboxes clearly. Deep trees that mirror org charts usually create policy conflicts without improving governance.
Where should Azure Policy live?
At the Management Group level for estate-wide baselines, with narrowly scoped exemptions that expire and are reviewed—never permanent silent exclusions.