How to Design an Azure Management Group Hierarchy Without Copying Your Org Chart
Designing an effective Azure management group hierarchy is one of the most critical foundational tasks for any cloud architect. Rather than building a sprawling tree that mimics your human resources reporting structure, a successful cloud architecture groups subscriptions by common security, policy, and compliance needs to ensure scalable governance without administrative chaos.
Key Takeaways
- Avoid mirroring corporate organizational charts in your Azure management group tree to prevent administrative overhead and rigid governance bottlenecks.
- Design your Azure hierarchy around shared rule sets, security boundaries, and policy enforcement rather than reporting lines.
- Keep your management group tree flat (aiming for three to four levels deep) to ensure visibility and maintainability across the tenant.
- Utilize built-in landing zones like platform, corp, online, sandboxes, and decommissioned to establish a proven, scalable foundation.
The Trap of Org Chart Governance
When organizations first transition to the cloud, it is tempting to use the company directory or organizational chart as the blueprint for Azure architecture. You might create a top-level group for Marketing, another for Finance, and nested subgroups for every sub-department underneath them. While this feels intuitive on day one, it quickly introduces severe operational friction.
Human organizations change constantly. Departments merge, rebrand, spin off, or get restructured every few quarters. If your Azure management group hierarchy strictly follows your org chart, every corporate shakeup forces you to reorganize your cloud infrastructure. Subscriptions must be shifted, inheritance models break, and security policies have to be entirely re-evaluated. More importantly, separate departments often share the exact same technical governance requirements. Grouping them by HR boundaries rather than technical rules defeats the primary purpose of management groups.
Building Around Rules, Not People
The true purpose of a management group is to apply consistent rules, policies, and role-based access control (RBAC) across multiple subscriptions at once. Therefore, your hierarchy should be built around operational boundaries rather than human reporting structures. Ask yourself what technical rules a workload needs to follow rather than who owns the budget.
Does a specific set of workloads require strict PCI compliance and isolation from the public internet? Do certain development environments need relaxed policies to encourage experimentation? These technical requirements dictate your folder structure. When you group subscriptions that share identical compliance demands, security baselines, and network connectivity profiles, your governance strategy becomes infinitely easier to manage.
The Proven Landing Zone Model
To avoid the guesswork of designing a tree from scratch, Microsoft provides a battle-tested blueprint known as the Enterprise-Scale Landing Zone. This reference architecture establishes a clean, predictable hierarchy that scales seamlessly across hundreds of subscriptions without falling victim to organizational drift.
Beneath the Tenant Root Group and your company-specific intermediate root, the architecture typically splits into four core branches:
- Platform: Holds shared services like connectivity, identity, security, and management subscriptions.
- Landing Zones: Houses your actual business workloads, often split into corp (internal-facing) and online (internet-facing) groups.
- Sandboxes: Provides an isolated space for developers and engineers to test ideas with minimal guardrails.
- Decommissioned: Acts as a temporary parking lot for retiring subscriptions before Azure purges them.
This layout ensures that shared foundational services—managed by specialized teams like networking and security—remain completely isolated from everyday business application workloads. Each branch can inherit the exact policies it needs without bleeding restrictions into unrelated parts of the business.
Keeping the Hierarchy Flat and Maintainable
A common pitfall when implementing Azure management groups is over-engineering. Engineers often create deep, multi-layered nesting structures with six, seven, or eight levels of subfolders, believing that extreme granularity equals better security. In reality, deep hierarchies obscure visibility and complicate troubleshooting.
Microsoft advises keeping your management group tree flat, generally capping it at three to four levels deep. Remember that policy inheritance flows downward, and deny-assignments established at higher levels cannot be easily overridden further down without explicit exemptions. If your tree is too deep, tracing why a specific resource deployment was blocked turns into a frustrating treasure hunt.
Furthermore, be mindful of the default behavior when creating new subscriptions. Every new subscription you spin up automatically drops directly into the Tenant Root Group unless you explicitly assign it elsewhere. Because the root group anchors your entire tenant and affects every resource globally, you should establish operational guardrails to immediately relocate new subscriptions into your structured landing zones.
Conclusion
Designing your Azure management group hierarchy requires a shift in mindset. Instead of asking how your company looks on paper, focus on how your workloads behave in code. By structuring your cloud environment around technical landing zones rather than human org charts, you eliminate administrative overhead and build a resilient foundation that scales cleanly.
To hear a complete, jargon-free breakdown of how Azure management groups and subscriptions work together to tame cloud sprawl, be sure to Listen to the full episode of the M365 FM Podcast and master your cloud architecture today!
Frequently Asked Questions
Why shouldn't I mirror my company's org chart in Azure management groups?
Org charts change frequently due to restructures, acquisitions, and department renaming. If your Azure hierarchy matches your HR reporting lines, you will constantly have to move subscriptions, rewrite policies, and disrupt inheritance models. Management groups should be structured around operational rules and security requirements, not personnel.
How many levels deep should an Azure management group hierarchy be?
Microsoft recommends keeping your management group tree relatively flat, typically aiming for three to four levels deep below the tenant root group. Going too deep creates a tangled web of inheritance that becomes difficult to audit, troubleshoot, and explain to new administrators.
What is the difference between platform and workload management groups?
Platform management groups hold shared foundational subscriptions such as connectivity, security, identity, and monitoring that the entire organization relies on. Workload management groups hold actual business applications and services, separated into categories like corp, online, or sandbox based on their networking and exposure needs.
Where do newly created Azure subscriptions automatically land?
By default, when you create a new subscription in Azure without specifying its location, it drops straight into the Tenant Root Group. Because global rules applied at the root group affect every subscription in the enterprise, it is a best practice to move new subscriptions into appropriate child management groups immediately.
