Azure Management Groups and Hierarchy
Not sure you’re ready?
Take the ~3-minute readiness diagnostic and see where you stand.
Imagine being tasked with imposing a strict financial budget and rigid security protocols across a sprawling multinational corporation. If you attempt to enforce these rules by individually walking into every single office to brief every single employee, you will fail before you finish the first department. Instead, you design a structural hierarchy: you mandate policies at the executive board level, which logically cascade down to regional divisions, then to local offices, and finally to individual teams.
In the Microsoft Azure cloud, this exact principle of hierarchical inheritance is how organizations tame the chaos of deploying thousands of applications, virtual machines, and databases. To govern the cloud without being overwhelmed by it—whether you are a finance manager tracking costs, a project manager organizing deployments, or an architect securing infrastructure—you must understand the overarching Azure management hierarchy.
The Azure management hierarchy organizes resources into four distinct levels: management groups, subscriptions, resource groups, and individual resources.
Think of this structure as a set of perfectly nested Russian dolls. By organizing cloud environments this way, Azure provides logical boundaries where you can precisely apply security rules (Role-Based Access Control, or RBAC), compliance policies (Azure Policy), and cost tracking.
To understand how these layers interact, we must examine them from the foundational deployment level up to the absolute apex of organizational governance.
1. Resources: The Lowest Level
At the base of our hierarchy, we find the actual cloud services you are paying for. Azure resources are the lowest level of the management hierarchy and represent individual deployable cloud services like virtual machines or databases.
Whether an engineer spins up an artificial intelligence cognitive service or a simple storage account, they are creating an Azure resource. However, a resource cannot exist in a vacuum.
Crucial Rule: An individual Azure resource must exist within exactly one Azure resource group. You cannot have a resource floating freely, nor can it belong to multiple resource groups simultaneously.
2. Resource Groups: The Lifecycle Container
As a project manager or IT lead, you rarely think about a single virtual machine in isolation. A web application, for example, requires a web server, a database, and a virtual network. Because these resources are created together, updated together, and will eventually be decommissioned together, they should be managed together.
An Azure resource group is a logical container used to group and manage resources that share the same lifecycle.
By grouping resources this way, when a temporary project concludes, you do not have to hunt down isolated virtual machines to stop the billing; you simply delete the entire resource group, and every resource inside it is cleanly destroyed.
There are two strict architectural rules governing resource groups:
- Azure resource groups cannot be nested inside other Azure resource groups. You cannot create a "parent" resource group and place "child" resource groups inside it. It is a strictly flat structure.
- An Azure resource group must belong to exactly one Azure subscription.
3. Subscriptions: The Billing Boundary
If resource groups represent project lifecycles, subscriptions represent the financial checkbook. An Azure subscription is a logical container used to provision resources and serves as a primary billing and management boundary.
For finance and sales professionals, the subscription is arguably the most important layer. Every month, an Azure invoice is generated at the subscription level. A company might create one subscription for "Production" and another for "Development," or divide them by departments like "Human Resources" and "Marketing."
However, success in the cloud breeds complexity. What happens when your company grows from having two subscriptions to managing fifty? How do you ensure that every single subscription strictly prohibits the deployment of extremely expensive GPU-optimized virtual machines, or blocks data from being hosted outside of the European Union for compliance reasons?
Attempting to log into fifty separate subscriptions to manually configure these rules introduces human error. This is the exact problem the final, highest tier of the hierarchy was built to solve.
4. Management Groups: Scaling Governance
Azure management groups are logical containers used to manage access, policies, and compliance across multiple Azure subscriptions.
They allow you to treat multiple subscriptions as a single, governable entity.
- An Azure management group can contain multiple child Azure subscriptions simultaneously.
- An Azure management group can contain multiple subordinate child management groups.
Because you can place management groups inside other management groups, you can build an organizational tree that mirrors your business. For example, you might create a "North America" management group, and inside it, place subordinate "Finance" and "Engineering" management groups, distributing your subscriptions among them accordingly.
While management groups are incredibly flexible, Azure enforces specific limits to ensure the hierarchy remains performant and logical:
| Management Group Boundaries | Specification |
|---|---|
| Tenant Limit | A single Microsoft Entra ID tenant supports a maximum limit of 10,000 Azure management groups. |
| Nesting Depth | The Azure management group hierarchy supports a maximum of six levels of depth for nesting. |
| Depth Calculation | The six-level depth limit strictly excludes the root management group level and the Azure subscription level. |
| Identity Requirement | Azure subscriptions must be associated with the same Microsoft Entra ID tenant to be placed within the same management group hierarchy. |
Just as a resource group maps strictly to one subscription, an Azure subscription can only belong to one parent management group at any given time. It cannot report to two separate bosses.
If we follow our hierarchy all the way up—past resources, resource groups, subscriptions, and our nested management groups—we eventually reach the ceiling.
Every Microsoft Entra ID tenant includes a single top-level management group known as the Root Management Group.
This unique entity sits at the absolute top of the hierarchy and encapsulates all other management groups and subscriptions within a tenant. Because it is the fundamental anchor point for your entire cloud environment, it possesses special characteristics that differentiate it from standard management groups:
- The Azure Root Management Group cannot be deleted.
- The Azure Root Management Group cannot be moved.
- All newly created Azure subscriptions are automatically placed under the Azure Root Management Group by default.
When a new subscription is purchased, it doesn't float in the abyss; Azure immediately attaches it to the Root Management Group until a cloud administrator explicitly moves it to a more specific, subordinate management group.
Why do we care so deeply about this hierarchy? The answer lies in one word: Inheritance.
In physics, gravity pulls objects downward. In Azure, governance pulls downward. Any rule applied at a higher level automatically cascades down to every single level beneath it.
Inheriting Access Controls
Security in Azure is handled via Role-Based Access Control (RBAC). Role-Based Access Control assignments applied to an Azure management group are inherently inherited by all child management groups and subscriptions. If you grant a database administrator "Read" access at a management group level, they automatically possess "Read" access to every subscription, every resource group, and every individual database contained underneath that group.
Inheriting Compliance
Similarly, Azure Policy definitions assigned to an Azure management group are automatically enforced on all subordinate subscriptions and resource groups. If your corporate compliance team applies an Azure Policy to a management group dictating that all storage accounts must be encrypted, no engineer can bypass this rule in any child subscription. The policy is absolute.
Breaking and Remaking Inheritance
Because governance flows strictly downward from the parent, the location of a subscription within the hierarchy dictates its reality.
Crucial Rule: Moving an Azure subscription to a different management group entirely replaces the inherited policies and access controls with those of the new parent.
Imagine moving an employee from the "Experimental R&D" department to the "Strict Financial Accounting" department. They instantly lose the permissive rules of R&D and are subjected to the rigid audits of Finance. If you move a subscription out of a "Sandbox" management group and into a "Production" management group, the sandbox policies immediately vanish, and the production policies violently, automatically attach themselves to the subscription.
To succeed in cloud governance, visualize the management hierarchy as your primary tool for scale.
- You deploy Resources to build your applications.
- You bundle them into Resource Groups because they share a lifecycle.
- You place those groups into Subscriptions so finance can pay the correct bill.
- You organize those subscriptions into Management Groups under a single Root Management Group so security and compliance can enforce Inherited Policies and RBAC uniformly.
By mastering this hierarchy, you transform Azure from a disorganized collection of servers into a predictable, financially trackable, and highly secure extension of your business.