Skip to main content
In Azure, organizing resources with a clear hierarchy is essential for scalable governance, consistent security, and predictable cost management. Azure’s management hierarchy lets you group subscriptions, apply policies, and assign roles at broader scopes so settings automatically propagate down to child objects. The hierarchy is commonly structured like this:
  • Management groups (root → nested groups)
  • Subscriptions (one or more under management groups)
  • Resource groups (within subscriptions)
  • Resources (virtual machines, databases, storage accounts, etc.)
Summary table — Azure hierarchy at a glance:
A slide titled "Understanding the Hierarchy" showing a tree diagram with a Root Management Group branching into IT and Finance, then into Production/Develop and individual subscriptions (A, B, C). A side flow diagram illustrates the scope: Management Groups → Subscriptions → Resource Groups → Resources, with brief explanatory notes on the left.
Why this matters
  • Assignments (policies, initiatives, and RBAC roles) inherit downward, so applying them at a higher scope reduces repetitive configuration.
  • Management groups provide a single place to manage security baselines, compliance rules, and cost controls across multiple subscriptions.
  • A well-planned hierarchy reflects organizational boundaries (teams, departments), compliance domains, and cost centers, simplifying reporting and automation.
Inheritance and RBAC Because Azure inherits assignments from parent to child, you can assign access at a management group level instead of repeating it on each subscription. For example, granting a user Reader role on the “IT” management group gives them read access to all subscriptions and resources under that group.
Assignments made at a management group level (policies, RBAC roles, and initiatives) inherit to all child management groups, subscriptions, resource groups, and resources. Plan your management group hierarchy to reflect organizational boundaries, compliance domains, and cost centers.
Azure supports up to six levels of nested management groups beneath the root (the root group itself is excluded from this limit). Be careful when reorganizing subscriptions—moving a subscription changes the inherited policies and role assignments that apply to it.
Creating and organizing management groups in the Azure portal
  1. In the Azure portal, open the Management groups blade. You will see the root management group and any existing nested groups or subscriptions.
  2. Create a new management group by choosing Create management group and providing a unique management group ID and a display name.
    • Example: ID = AZ-104, Display name = 104.
  3. After creating the group, it will appear with no subscriptions by default. Add existing subscriptions using the Add subscription option, selecting the subscriptions you want to include.
  4. To reorganize, select a subscription, choose Move, and pick the target management group. After saving, the subscription becomes a child of the selected management group and inherits its policies and role assignments.
A screenshot of the Microsoft Azure portal showing the Management groups blade on the left and a "Create management group" pane on the right. The pane contains fields for Management group ID ("AZ-104") and display name ("104") with Submit and Cancel buttons.
Adding subscriptions to a management group
  • From the management group blade, use Add subscription and select one or more subscriptions to include.
  • After adding, verify that expected policies and RBAC roles are applied to the subscriptions and resources beneath the group.
  • You can move subscriptions between groups when organizational requirements change.
Screenshot of the Microsoft Azure portal showing the "AZ-104" management group on the left and an "Add subscription" dialog on the right. The dialog's subscription dropdown is open, listing options such as "Kodekloud Azure Admin - PoC 1."
Best practices
  • Design your management group structure to match how teams, environments, and cost centers operate (e.g., Root → IT/Finance → Prod/Dev).
  • Apply critical security and compliance policies at the highest practical level to ensure consistent enforcement.
  • Use dedicated subscriptions for isolation of production workloads, compliance boundaries, or billing separation.
  • Regularly review role assignments and policy effects after moving subscriptions to avoid unexpected access or restrictions.
Links and references With this foundation in place, you can manage access, apply policies, and control costs consistently across your Azure environment. Next, we’ll cover how to create and assign policies at different scopes.

Watch Video