Azure Management Groups

What Are Management Groups?

Azure Management Groups are containers that sit above subscriptions in the Azure hierarchy. They allow you to organise multiple subscriptions and apply governance at scale — a policy or role assigned to a Management Group automatically applies to all subscriptions beneath it.

The Root Management Group

Every Azure Active Directory (Entra ID) tenant has exactly one Root Management Group — automatically created by Azure. All subscriptions and management groups ultimately sit under this root.

Building a Hierarchy

You can create up to 6 levels of Management Groups beneath the Root (not counting the Root itself). This gives you enormous flexibility to model your organisation's structure.

A typical enterprise hierarchy might look like this:

Root Management Group
├── Production MG
│   ├── Production-India Subscription
│   └── Production-US Subscription
├── Non-Production MG
│   ├── Dev Subscription
│   └── Test Subscription
└── Shared Services MG
    └── Shared Infrastructure Subscription

Policy and RBAC Inheritance

This is the most important concept in Management Groups — inheritance. Anything you apply at a Management Group level automatically cascades down to all children.

RBAC Inheritance

Role assignments also inherit. If you assign the "Reader" role to a security team at the "Production MG" level, they can read all resources in both Production subscriptions — without needing separate role assignments in each subscription.

Management Group Limits

Real-World Hierarchy Example

Here's how a mid-sized Indian technology company might structure their Azure environment:

TechCorp Root MG
│   Policy: "All resources must be in India regions"
│   Policy: "MFA required for all users"
│
├── Production MG
│   Policy: "No public IP addresses on VMs"
│   Policy: "Azure Defender must be enabled"
│   │
│   ├── TechCorp-Production Subscription
│   │   ├── rg-ecommerce-prod
│   │   └── rg-api-prod
│   │
│   └── TechCorp-DataPlatform Subscription
│       └── rg-datawarehouse-prod
│
├── Non-Production MG
│   Policy: "Auto-shutdown VMs at 8 PM"
│   Policy: "Dev/Test VM sizes only"
│   │
│   ├── TechCorp-Dev Subscription
│   └── TechCorp-Test Subscription
│
└── Shared Services MG
    └── TechCorp-Shared Subscription
        ├── rg-networking-shared
        └── rg-monitoring-shared

Notice how policies cascade. The "All resources must be in India regions" policy at the Root applies to every subscription — production, dev, test, and shared. The "No public IP" policy only applies to Production. Dev gets a cost-saving "auto-shutdown" policy that production doesn't have.

Creating Management Groups

# Create a top-level management group
az account management-group create \
  --name "Production-MG" \
  --display-name "Production"

# Create a child management group under an existing one
az account management-group create \
  --name "Production-India-MG" \
  --display-name "Production India" \
  --parent "Production-MG"

# Move a subscription into a management group
az account management-group subscription add \
  --name "Production-MG" \
  --subscription "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

Best Practices

• Model your org structure — Mirror your company's business units or environment structure in Management Groups
• Apply root-level policies sparingly — Only truly universal policies belong at the root (e.g., MFA requirement, allowed regions)
• Separate production from non-production — Always have distinct Production and Non-Production Management Groups
• Use a Shared Services MG — Networking, monitoring, and shared infrastructure subscriptions should have their own group
• Don't go too deep — 3–4 levels is usually sufficient. Deeper hierarchies become hard to understand and audit.
• Document your hierarchy — Keep an up-to-date diagram of your Management Group structure for new team members