Azure Management Groups

In this comprehensive tutorial, we will explore what Azure Management Groups are, how they structure the overarching cloud hierarchy, and how to use them to enforce policies and security at scale.

Azure Management Groups

What are Azure Management Groups?

At their core, Azure Management Groups are logical containers that allow you to organize, manage, and apply governance conditions across multiple Azure subscriptions simultaneously. They introduce a layer of scope that sits cleanly above your subscriptions, forming a top-tier administrative framework.

When you place multiple subscriptions into a management group, any governance conditions you apply to that group—such as an Azure Policy definition or an RBAC role assignment—automatically propagate downward via inheritance to all nested management groups, subscriptions, resource groups, and the individual cloud resources themselves.

Architectural Rules and Technical Limits

To design an effective management group hierarchy, it is important to understand the hard boundaries built into the Azure Resource Manager (ARM) engine. Microsoft enforces specific structural rules to maintain performance and avoid overly deep setups:

• The Tenant Root Group: Every single Azure Entra ID tenant automatically receives a single, immutable top-level container known as the Root Management Group. All other custom management groups and newly created subscriptions fold up underneath this root group.
• Hierarchy Depth Limits: Your custom management group tree can support a maximum depth of six levels. Importantly, this six-level limit does not include the ultimate Tenant Root Group or the target subscription layer.
• Single-Parent Constraint: A management group or an individual subscription can support exactly one direct parent. You cannot map a subscription to two distinct management groups simultaneously. However, a single parent group can host an unlimited number of children.
• Scale Capacity: A single Microsoft Entra ID directory can scale up to support a maximum of 10,000 distinct management groups.

Core Capabilities: Governance and Access Control at Scale

There are two primary reasons why enterprise platform teams deploy management groups: Policy Enforcement and Access Management.

1. Unified Policy Enforcement

Imagine your compliance team issues a mandate: to adhere to specific financial regulations, no corporate data or compute resources can ever be deployed outside of the continental United States.

Without management groups, you would have to manually attach an “Allowed Locations” Azure Policy to every single subscription. If a team creates a new subscription next week, that policy might be forgotten, creating a compliance gap.

By applying the “Allowed Locations” policy directly at a high-level management group, the restriction instantly applies to all current and future descendant subscriptions. Even a subscription owner or a full resource administrator cannot bypass or overwrite this rule at their local scope.

2. Streamlined Role-Based Access Control (RBAC)

Managing access permissions on a subscription-by-subscription basis can lead to configuration drift and administrative fatigue.

With management groups, you can assign an Entra ID security group a role like Network Contributor at the management group level. Instantly, every engineer in that group gains full authority to manage virtual networks, ExpressRoute circuits, and firewalls across every single subscription nestled under that group. One single assignment replaces what used to require dozens of duplicate tasks.

Architectural Comparison: Where Do Management Groups Fit?

The Microsoft Cloud Adoption Framework (CAF) Blueprint

When designing a production-grade management group tree, avoid the temptation to mirror your company’s internal HR org chart. Corporate re-organizations happen frequently, and shifting your management group structure to reflect every personnel change can create an administrative burden.

Instead, the Microsoft Cloud Adoption Framework (CAF) recommends structuring your hierarchy based on workload type, security baselines, and connectivity requirements. Here is an architectural blueprint modeled after the CAF landing zone reference structure:

The Recommended Sub-Group Tiers

1. The Intermediate Root Group: Create a custom management group right below the Tenant Root Group, named after your organization. This leaves the absolute root clean and gives you an isolated point to begin your custom architecture.
2. The Platform Group: This branch hosts core shared subscriptions managed by your central infrastructure or platform teams. It typically contains dedicated subscriptions for core identity services (domain controllers) and centralized management or logging.
3. The Landing Zones Group: This is where your customer-facing and internal business workloads reside. It is often split into:
   • Corp (Corporate): Subscriptions hosting applications that require direct private connectivity back to an on-premises data center.
   • Online: Subscriptions for internet-facing applications that utilize public endpoints and are isolated from the core corporate internal network.
4. The Sandbox Group: A dedicated environment for engineering teams to experiment, prototype, and explore new Azure capabilities. Policies here are usually relaxed to encourage innovation, but these subscriptions are strictly isolated from your internal networks to protect the rest of the estate.

Production Design and Governance Best Practices

Before establishing your management group architecture, consider these core governance principles to ensure your environment remains both secure and maintainable:

• Keep the Hierarchy Flat: While Azure technically supports six levels of depth, best practices recommend keeping your custom structure to no more than three to four levels. A flat tree minimizes the complexity of troubleshooting inherited rules and keeps your operational overhead lean.
• Avoid Broad RBAC at High Scopes: While it is tempting to grant your platform engineering team full Owner or Contributor rights at the highest intermediate management group, doing so carries risk. Privilege inheritance means a mistake at that high level could impact every system beneath it. Instead, restrict high-level access, and use specialized, just-in-time tools like Privileged Identity Management (PIM) for elevated tasks.
• Test Policies in Sandbox First: Because a policy change at a management group level instantly cascades down the tree, rolling out an unverified policy directly to your production branch can inadvertently disrupt running services. Always apply and validate new policy initiatives inside your Sandbox group first to ensure they behave exactly as intended before pushing them to live workloads.

You may also like the following articles:

• Azure Resource Group vs Resource Manager
• Azure Subscription ID
• Azure Budget Alerts

Rajkishore

I am Rajkishore, and I am a Microsoft Certified IT Consultant. I have over 14 years of experience in Microsoft Azure and AWS, with good experience in Azure Functions, Storage, Virtual Machines, Logic Apps, PowerShell Commands, CLI Commands, Machine Learning, AI, Azure Cognitive Services, DevOps, etc. Not only that, I do have good real-time experience in designing and developing cloud-native data integrations on Azure or AWS, etc. I hope you will learn from these practical Azure tutorials. Read more.