Azure Resource Hierarchy: Management Groups, Subscriptions, and Resource Groups
Azure organizes every resource into a four-level hierarchy: management groups, subscriptions, resource groups, and individual resources. Understanding this hierarchy is the key to governing access, enforcing policy, and managing costs at scale — because anything you configure at a higher level flows down automatically to everything beneath it.
The four levels explained
Here is the structure, from top to bottom:
Root Management Group
└── Management Group: acme-corp
├── Management Group: acme-production
│ ├── Subscription: acme-prod-core
│ │ ├── Resource Group: rg-webapp-prod
│ │ │ ├── App Service: acme-web-app
│ │ │ ├── Azure SQL Database: acme-db-prod
│ │ │ └── Application Insights: acme-insights-prod
│ │ └── Resource Group: rg-networking-prod
│ │ ├── Virtual Network: vnet-prod
│ │ └── Application Gateway: agw-prod
│ └── Subscription: acme-prod-data
│ └── Resource Group: rg-analytics
│ └── Synapse Workspace: acme-synapse
└── Management Group: acme-nonprod
├── Subscription: acme-staging
└── Subscription: acme-devLet’s walk through each level.
Management groups
Management groups are containers for subscriptions. They exist purely for governance — you cannot put resources directly in a management group. Their purpose is to let you apply Azure Policy and RBAC role assignments once and have them cascade to all subscriptions below.
Every Azure tenant has a single Root Management Group that is created automatically. You cannot delete it or move it. All subscriptions and management groups in the tenant ultimately sit under the root.
Management group rules
- Maximum depth: 6 levels below the root (so root + 6 = 7 total levels)
- A management group can have up to 10,000 subscriptions
- Each management group can have only one parent
- A management group or subscription can be moved to a different parent
- The root management group cannot have policies removed by subscription owners — only Global Administrators can modify root-level policies
Creating a management group
# Create a management group
az account management-group create \
--name "acme-production" \
--display-name "Acme Production"
# Move a subscription into the management group
az account management-group subscription add \
--name "acme-production" \
--subscription "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
# List management groups
az account management-group list --output tableNew subscriptions land under the root management group by default. If your organization has a policy that all subscriptions must be in a specific management group, you need to move them immediately after creation — they don’t go there automatically.
Subscriptions in the hierarchy
Subscriptions are where billing happens and where most access control decisions are made. A subscription belongs to exactly one management group (or the root if you haven’t organized them yet).
RBAC roles assigned at the subscription level apply to all resource groups and resources inside it. A policy assigned to a management group flows down to all subscriptions in that group, which in turn flows down to all resource groups and resources inside those subscriptions.
For a full discussion of subscription types, limits, and when to use multiple subscriptions, see Azure subscriptions.
Resource groups
A resource group is the deployment unit in Azure. Every Azure resource must live in exactly one resource group. A resource group has a name, a region (which determines where the resource group’s metadata is stored), and belongs to exactly one subscription.
What resource groups are used for
Resource groups serve several practical purposes:
- Lifecycle management. Delete the resource group and all resources inside it are deleted together. This is how you clean up an entire environment without hunting for individual resources.
- Deployment scope. ARM templates and Bicep files can target a resource group, deploying multiple resources in a single operation.
- Access scope. RBAC roles can be assigned at the resource group level. A developer might have Contributor access to a dev resource group but only Reader access to the production resource group.
- Cost grouping. Azure Cost Management can show costs broken down by resource group.
Important: resource groups are not regions
A resource group has a location, but that location is only for storing the resource group’s metadata. Resources inside the group can be in any region. For example, a resource group named rg-global-assets might be located in East US (where its metadata lives) but contain a storage account in West Europe and a CDN endpoint in Southeast Asia.
# Create a resource group in East US
az group create \
--name "rg-webapp-prod" \
--location "eastus" \
--tags Environment=Production Team=Engineering CostCenter=12345
# List all resource groups in the current subscription
az group list --output table
# List all resources inside a specific resource group
az resource list --resource-group "rg-webapp-prod" --output table
# Delete a resource group and ALL resources inside it
az group delete --name "rg-webapp-dev" --yesaz group delete is permanent and deletes every resource inside the group immediately. There is no recycle bin. Always verify you’re targeting the right group by running az resource list —resource-group [name] first and reviewing what will be deleted.
Naming conventions matter
Azure does not enforce naming conventions, but consistent names make the hierarchy readable. A common pattern is rg-[workload]-[environment]-[region], for example rg-webapp-prod-eastus or rg-analytics-dev-westeurope.
Individual resources
Resources are the actual Azure services you use: virtual machines, storage accounts, SQL databases, virtual networks, function apps, and so on. Each resource:
- Belongs to exactly one resource group
- Has a resource ID — a path like
/subscriptions/{sub-id}/resourceGroups/{rg-name}/providers/Microsoft.Compute/virtualMachines/{vm-name} - Has a type (e.g.
Microsoft.Storage/storageAccounts) - Can have tags applied to it (in addition to tags on its resource group)
- Can have RBAC roles assigned directly to it (though scoping to resource groups is usually cleaner)
How policy and RBAC flow down the hierarchy
This is the most important operational concept in the Azure hierarchy: assignments made at a higher scope automatically apply to all child scopes.
Think of it like company policy
A rule applied at the company level applies to all departments, teams, and individual employees. A rule applied to one department applies to all teams in that department, but not to other departments. You cannot opt out of a parent-level rule at a child level.
RBAC inheritance
If you assign the Reader role to a user at a management group, that user has read access to every subscription, resource group, and resource in that management group. You can grant more permissive access at a lower level (e.g. Contributor on a specific resource group), but you cannot deny access granted higher up. Azure RBAC is additive — there is no “deny assignment” in the standard model (Azure does have explicit Deny Assignments, but they’re used rarely and require careful management).
Azure Policy inheritance
Azure Policy can enforce rules like “all resources must have a cost-center tag” or “virtual machines must use approved SKUs.” Policies assigned to a management group apply to every subscription and resource group below it. You can assign policies at any level, but you cannot override a policy assigned at a parent level with a conflicting policy at a child level.
For example, if the root management group has a policy that blocks deployment of resources to regions outside the EU, no subscription or resource group in the tenant can deploy outside the EU — regardless of what roles a user has.
# List Azure Policy assignments at the subscription level
az policy assignment list --scope "/subscriptions/{subscription-id}" --output table
# List Azure Policy assignments at a resource group level
az policy assignment list \
--scope "/subscriptions/{sub-id}/resourceGroups/rg-webapp-prod" \
--output tableUnderstanding policy inheritance is key to explaining why a resource deployment might fail even when a user has the correct RBAC role. Policy violations block deployments regardless of permissions. See Azure RBAC for a deeper look at how roles and policies interact.
How this differs from other clouds
If you’ve used GCP, you’ll notice similarities but important differences. GCP has organizations, folders, projects, and resources. Azure’s equivalent mapping is roughly: management groups ≈ folders, subscriptions ≈ projects, resource groups (no GCP equivalent at this level), resources.
The key difference is resource groups — Azure adds an extra level of grouping below the subscription that doesn’t exist in GCP. In GCP, resources are owned directly by a project. In Azure, resources belong to a resource group which belongs to a subscription. This extra level gives more flexibility for lifecycle management but also adds a required decision about how to group resources within a subscription.
If you’ve used AWS, the closest mapping is: management groups ≈ AWS Organizations organizational units, subscriptions ≈ AWS accounts, resource groups ≈ AWS resource groups (though AWS resource groups are less central to the architecture than Azure’s). One major difference: AWS accounts are fully isolated billing and IAM boundaries. Azure subscriptions are billing boundaries, but all identity still flows through one Entra ID tenant.
Common hierarchy mistakes
- Not setting up management groups before creating subscriptions. If you create subscriptions directly under the root management group without a management group structure, any policies or RBAC you want applied to all subscriptions must be assigned individually to each one. Adding management groups later and moving subscriptions is possible but disruptive. Plan the structure first.
- One resource group for all resources. Putting every resource in a single resource group loses the lifecycle management benefit. When you want to delete a dev environment, you need to identify and delete resources individually instead of just deleting the resource group. Use separate resource groups for separate workloads or environments.
- Forgetting that resource groups have a region for metadata but not for resources. New users sometimes avoid putting resources in a resource group that’s in a different region, thinking it will cause latency or cross-region data transfer. It won’t — the resource group’s region only affects where its metadata is stored, not where the resources run.
- Granting RBAC at the resource level instead of the resource group level. Managing permissions resource-by-resource becomes unmanageable quickly. Grant at the resource group or subscription level and use deny assignments or policy only when you need finer granularity.
Summary
- The Azure hierarchy is: root management group → management groups → subscriptions → resource groups → resources.
- Management groups contain subscriptions and are the place to apply organization-wide policies and RBAC — they cascade down to everything below.
- Resource groups are the deployment unit: create together, update together, delete together. Every resource must be in one.
- RBAC and Azure Policy assignments are additive and inherited — higher-level assignments flow down, and you cannot deny a parent-level assignment at a child scope.
- Resource group location is only for metadata storage — the resources inside can be in any Azure region.
Frequently asked questions
What is the Azure resource hierarchy?
Azure organizes resources in a four-level hierarchy: management groups at the top, then subscriptions, then resource groups, and individual resources at the bottom. Policies and RBAC roles assigned at a higher level automatically apply to everything below it.
What is an Azure resource group?
A resource group is a logical container for Azure resources. Every resource must belong to exactly one resource group. It acts as the deployment and management unit — you can deploy, update, or delete all resources in a group together. Resources in the same group can be in different regions.
Do I need management groups?
Management groups are optional for small organizations with one or two subscriptions, but become essential when you have many subscriptions. They let you apply Azure Policy and RBAC once at a group level rather than repeating the same configuration on every subscription.