How should Azure management groups and subscriptions be structured for a large enterprise environment?

A large Azure environment should be designed as a governance hierarchy, not simply as a collection of subscriptions created whenever a project starts. Management groups provide a scope above subscriptions where organisations can apply Azure Policy, access controls and governance consistently. Subscriptions then provide an important boundary for resource management, billing, quotas and operational ownership.

A simplified enterprise structure could look like:

Tenant Root
    |
    v
Platform
    |
    +---- Management
    +---- Connectivity
    +---- Identity
    |
    v
Landing Zones
    |
    +---- Production
    |       +---- Business Unit A
    |       +---- Business Unit B
    |
    +---- Non-Production
            +---- Development
            +---- Test
            +---- UAT

However, management groups should not become a mirror of every department, project and geography in the company. Microsoft recommends keeping the hierarchy reasonably flat, ideally around three to four levels, and avoiding management groups created merely to represent regions unless regulatory or data-residency requirements justify that structure.

Enterprise design principles

Management groups should primarily represent governance boundaries.

For example:

Management Group
      |
      |-- Azure Policy
      |-- Security Standards
      |-- RBAC
      |-- Compliance
      |
      v
Subscriptions
      |
      |-- Resource Groups
             |
             |-- Resources

Policies assigned at a management-group level can be inherited by subscriptions below it. Likewise, Azure RBAC supports management groups as a scope above subscriptions.

Subscription design considerations

A subscription might represent:

• Production vs non-production.
• A major business application.
• A business unit.
• A regulatory boundary.
• A security boundary.
• A cost-management boundary.
• A workload with distinct operational ownership.

Avoid creating a new subscription simply because a developer needs another resource group.

Enterprise questions to ask

Before designing the hierarchy, ask:

• Who owns the workload?
• Who pays for it?
• What security boundary is required?
• Are there regulatory requirements?
• Should policies be inherited?
• Who should have subscription-level access?
• What happens if the business unit changes?
• How will FinOps reporting work?
• How will central platform teams govern the environment?

For students: understand the hierarchy:

Tenant → Management Group → Subscription → Resource Group → Resource

For professionals: think about governance, Azure Policy, RBAC, identity, security, networking, cost management, compliance and landing-zone architecture rather than simply organising resources by project names.