Designing Management Group Hierarchies

Introduction: The Foundation of Cloud Governance

In enterprise cloud environments, managing individual subscriptions is unsustainable. As organizations scale, they require a way to apply policies, access controls, and compliance standards across hundreds or thousands of subscriptions simultaneously.

Management Groups serve as the top-level containers in Azure that provide a governance scope for multiple subscriptions. By designing a robust Management Group hierarchy, you establish a "tree" structure that allows for the inheritance of governance settings—meaning a policy applied at the root level automatically cascades down to every child subscription, resource group, and resource.

Why does hierarchy design matter?

• Centralized Control: Apply compliance standards (e.g., "All resources must have a cost-center tag") once at the top level.
• Delegated Administration: Grant specific teams (e.g., Security, Networking) permissions at a specific node in the tree without granting them global access.
• Cost Visibility: Aggregated reporting allows leadership to track spending by business unit, environment, or geography.

Designing the Hierarchy: Practical Approaches

A well-architected hierarchy typically reflects your organization’s operating model. While there is no "one-size-fits-all" solution, most successful enterprises follow one of three common patterns.

1. The Environment-Based Model

This model organizes resources based on the lifecycle stage. It is ideal for companies that need strict separation between Production and Non-Production environments.

• Root Management Group
  • Production: Strict policies, restricted access, high availability requirements.
  • Non-Production: More flexibility, lower cost, developer access.
  • Sandbox: Highly restricted environments for experimentation.

2. The Business Unit (BU) Model

This model organizes resources based on organizational structure. This is preferred by large conglomerates where different business units operate independently.

• Root Management Group
  • BU: Finance
  • BU: Retail
  • BU: Manufacturing

3. The Hybrid (Recommended) Model

Most mature organizations use a hybrid approach that combines business units with environment stages.

Example Hierarchy:

• Root Management Group
  • Platform (Shared Services): Connectivity, Logging, Identity.
  • Landing Zones:
    • BU: Retail
      • Retail-Prod
      • Retail-NonProd
    • BU: Finance
      • Finance-Prod
      • Finance-NonProd

Implementing with Infrastructure as Code (IaC)

Using Terraform or Bicep to define your hierarchy ensures that your governance structure is version-controlled and repeatable. Below is a simplified example using Terraform to define a Management Group structure.

# Define the Root/Parent Management Group
resource "azurerm_management_group" "parent" {
  name         = "corp-root"
  display_name = "Corporate Root MG"
}

# Define a child Management Group for Production
resource "azurerm_management_group" "prod" {
  name                       = "prod-mg"
  display_name               = "Production Environment"
  parent_management_group_id = azurerm_management_group.parent.id
}

# Assign a Subscription to the Production Management Group
resource "azurerm_management_group_subscription_association" "example" {
  management_group_id = azurerm_management_group.prod.id
  subscription_id     = "/subscriptions/00000000-0000-0000-0000-000000000000"
}

Note: Always utilize the parent_management_group_id parameter to explicitly define the tree structure, ensuring that policies inherit correctly from the top down.

Best Practices

1. Keep it Shallow: Do not exceed 6 levels of depth. Deep hierarchies become difficult to visualize, manage, and troubleshoot. A 3-4 level depth is usually sufficient.
2. Use Policy Inheritance Wisely: Apply "Guardrail" policies (e.g., Allowed Regions) at the highest possible level. Apply "Specific" policies (e.g., VM SKU restrictions) as close to the subscription as necessary.
3. Governance by Exception: If a specific subscription requires an exemption from a policy, use Azure Policy Exemptions rather than moving the subscription to a less-governed Management Group.
4. Naming Conventions: Implement a strict naming convention for your Management Groups (e.g., mg-prod-retail-001). This makes it easier to identify the purpose of the group via CLI or Azure Portal.

Common Pitfalls to Avoid

• The "Root" Trap: Do not assign resources or policies directly to the "Tenant Root Group" unless absolutely necessary. This is the top-level container for the entire directory; cluttering it can lead to accidental policy enforcement across the entire organization.
• Over-Engineering: Avoid creating a Management Group for every single team or project. This leads to "Management Group Sprawl," where managing the hierarchy becomes more complex than managing the resources themselves.
• Ignoring RBAC: Do not assign "Owner" or "Contributor" permissions at the root level. Use the principle of least privilege, assigning roles at the lowest level of the hierarchy required for the task.

⚠️ Critical Warning: The Root Group

By default, the Tenant Root Group exists for every Azure AD tenant. You should create a custom "Root" Management Group under the Tenant Root Group. This allows you to manage the entire hierarchy without risking unintended global impacts on your Azure AD tenant.

Key Takeaways

• Management Groups provide the scope for governance, allowing you to manage compliance and access at scale.
• The hierarchy should reflect your business—whether that is by environment, business unit, or a combination of both.
• Use Infrastructure as Code (IaC) to deploy your hierarchy. This ensures consistency and auditability of your governance structure.
• Inheritance is your greatest tool. By placing policies at the appropriate level, you ensure that all current and future subscriptions automatically inherit the necessary guardrails.
• Complexity is the enemy. Design a hierarchy that is simple enough to be understood by your team at a glance, and avoid over-nesting.