Azure Management Groups vs. Subscriptions: Where Should Policy Live?

I once audted an Azure tenant for a mid-sized enterprise that had grown through acquisition. They had 65 subscriptions and zero Management Groups. When I asked how they enforced their “US Regions Only” rule, they proudly showed me a spreadsheet listing 65 separate Azure Policy assignments, one for every single subscription.

When they needed to expand to Europe, it took three engineers a solid week to update, test, and validate policy changes across the board. It was pure, unadulterated operational friction.

The fundamental misunderstanding here wasn’t what Azure Policy does, but where it should live. If you are assigning policies at the subscription level, you aren’t architecting; you’re just creating future technical debt.

Key Takeaways

• The Rule of Gravity: Policies applied at higher levels trickle down to everything below them.
• Subscriptions act as boundaries for billing, not necessarily governance.
• Management Groups act as boundaries for governance, grouping subscriptions logically.

The Concept: The Cascade of Power (Inheritance)

Think of Azure’s hierarchy like a corporate organizational chart.

• Tenant Root Group: The CEO.
• Management Groups: The VP / Division level (e.g., “Production,” “Non-Prod,” “Legacy acquisitions”).
• Subscriptions: The specific Department or Cost Center.
• Resource Groups: The filing cabinets.
• Resources: The files.

If the CEO issues a mandate—”No one flies First Class”—they don’t send an individual memo to every single employee. They issue the policy once at the top, and it inherits down through every division and department automatically.

In Azure, if you assign an “Allowed Locations” policy to a “Production” Management Group, every current and future subscription placed inside that group automatically inherits that rule. You do it once.

Code snippet

graph TD
    Root[Tenant Root Group] --> ProdMG[Production Management Group]
    Root --> NonProdMG[Non-Prod Management Group]
    ProdMG -- Policy: 'Deny-Public-IP' Applied Here --> SubA[Subscription A (ERP)]
    ProdMG --> SubB[Subscription B (Web App)]
    SubA --> RG1[Resource Group 1]
    RG1 -- Policy Inherited --> VM1[Virtual Machine]

The Battle: Where to Assign?

Here is the framework I use to decide where a policy assignment belongs.

The Architect’s Verdict

Stop treating subscriptions as islands.

90% of your policies—especially the guardrails we discussed like enforcing tags or restricting VM SKUs—belong at the Management Group level.

Develop a Management Group hierarchy aligned with your business (e.g., Archetypes based on environment or regulatory needs), not your org chart. Apply broad policies high up. Only use Subscription-level assignments for specific exceptions or unique workload requirements that don’t fit the broader mold.

Day 2 Operations (CapEx vs. OpEx)

While Azure Policy itself has no direct CapEx cost, the placement of those policies dictates your OpEx.

• Subscription-Level Sprawl (High OpEx): Every new subscription requires manual setup or complex automation scripts to apply baseline policies. Auditing requires scanning dozens of separate scopes.
• Management Group Hierarchy (Low OpEx): “Landing Zones” are automatically governed the moment a subscription is dropped into the correct Management Group. Day 2 operations are significantly leaner because the governance structure exists independent of the workloads.

Additional Resources

• Microsoft Docs: Scope in Azure Policy
• Cloud Adoption Framework: Management Group and Subscription organization

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →