Azure Subscriptions, Resource Groups and Management Groups

Four levels, one resource manager

Azure organizes everything you deploy into a strict hierarchy, and almost every confusing moment a newcomer has on the platform comes from mixing up two of its levels. Permissions are assigned at one level, quotas are counted at another, invoices arrive at a third, and the thing you delete by accident lives at a fourth.

The good news is that the hierarchy is small and consistent. Once you can name the levels and say what each one is for, the Azure portal, the CLI and Bicep templates all start to make sense at the same time. This article works top to bottom, then shows how role assignments and policies flow through the tree, and finishes with a short CLI session that builds a sensible starting layout.

Readers coming from another cloud may find the AWS versus Azure matrix useful for mapping concepts, since an Azure subscription plays a role that is close to, but not identical with, an AWS account.

The hierarchy from top to bottom

1. Microsoft Entra tenant. The identity directory. Users, groups, service principals and managed identities live here. A tenant is not an Azure resource container; it is the thing that authenticates you before you touch any container.
2. Management groups. Optional containers for subscriptions. Every tenant has a Tenant Root Group, and you can nest groups beneath it to mirror business units or environments. Policies and role assignments placed here cascade to every subscription below.
3. Subscriptions. The billing and quota boundary. A subscription is linked to exactly one tenant and one billing arrangement, and it carries its own service limits.
4. Resource groups. Logical folders inside a subscription. Every resource must belong to exactly one resource group, and a resource group cannot be nested inside another.
5. Resources. Virtual machines, storage accounts, virtual networks, App Service plans, SQL databases and everything else that Azure Resource Manager knows how to create.

Azure Resource Manager, usually shortened to ARM, is the control plane that sits across all of this. Whether you click in the portal, run az, or apply a Bicep or Terraform file, the request lands on ARM, which checks your role assignment at the relevant scope, evaluates policy, and only then talks to the underlying service. The Azure Resource Manager overview describes this flow in detail.

Resource groups in practice

A resource group is the level people interact with most, so it pays to understand its quirks. The group itself has a location, but that location only says where the group's metadata is stored. Resources inside the group may sit in any region. A group named rg-web-prod in West Europe can happily contain a VM in North Europe and a storage account in East US.

The defining feature of a resource group is shared lifecycle. Deleting the group deletes every resource inside it, in dependency order, with one confirmation. That makes groups ideal for things that are created and destroyed together: an application's web tier, or the complete infrastructure of a short-lived test environment.

It also makes them dangerous. Two protections exist. Resource locks come in two flavors, CanNotDelete and ReadOnly, and apply to the group or to individual resources. Role-based access control lets you give a team Contributor rights on their own group without granting delete rights elsewhere.

Resources can be moved between groups, and even between subscriptions, but not every resource type supports moves and dependent resources often have to travel together. It is easier to decide the grouping strategy up front. Common approaches include one group per application per environment, one group for shared networking, and one group for monitoring and logging resources that outlive individual applications.

Subscriptions as billing and quota boundaries

Where a resource group is about lifecycle, a subscription is about money and limits. Every subscription produces its own cost line, and Azure Cost Management can set budgets at the subscription scope or narrower. Subscriptions come in offer types that reflect how they are paid for: Free Trial, Pay-As-You-Go, Enterprise Agreement, Microsoft Customer Agreement, Cloud Solution Provider, and developer offers tied to Visual Studio subscriptions.

Quotas are the other half. Limits such as regional vCPU counts per VM family, public IP addresses, or storage accounts are tracked per subscription and per region. A busy data-science team in the same subscription as your production API can exhaust the shared quota, which is a strong argument for separate subscriptions by workload class. Increases are requested through the portal's quota blade and reviewed by Microsoft.

Subscriptions also draw the line for several services that are configured once per subscription, including Microsoft Defender for Cloud plans and the default activity log. If you are operating an Azure subscription supplied through AllCloudShop, check which offer type it carries and whether it is already attached to a tenant you control; the Azure account listing explains the variants in terms of what their names state, and the support channels can clarify details before you plan a layout around them.

The wider question of what a subscription is compared with a tenant or a project on another platform is covered in What Is a Cloud Account?.

Management groups and policy at scale

A single subscription does not need management groups. Three or more usually do. Management groups let you assign an Azure Policy or a role once and have it apply to every subscription beneath, including subscriptions created later. The Cloud Adoption Framework landing zone design uses a small tree such as Platform (with Identity, Management and Connectivity subscriptions) alongside Landing Zones (with Corp and Online subscriptions), plus Sandbox and Decommissioned groups.

Azure Policy is the enforcement engine. A policy definition describes a condition and an effect: Deny blocks non-compliant deployments, Audit reports them, DeployIfNotExists remediates by adding missing configuration, and Modify alters properties such as tags. Definitions are bundled into initiatives and assigned at management group, subscription or resource group scope. Restricting allowed regions, requiring specific tags, and blocking public IP addresses on VMs are the typical first three assignments.

Management groups are documented in the Azure governance documentation, which also lists the actions that are only available at the tenant root and therefore need elevated access to configure.

How role assignments inherit through the tree

Azure RBAC ties a security principal (user, group, service principal or managed identity) to a role definition at a scope. Scope can be any of the four container levels or a single resource. Assignments flow downward, and Azure evaluates the union of everything that applies, with any explicit deny assignment winning.

The practical rule is to assign to Entra groups rather than to individual people, and to assign at the narrowest scope that still avoids repetition. Contributor on a resource group is the workhorse assignment. Owner at the subscription root should be rare, and the principles in Cloud IAM Fundamentals apply directly: least privilege, group-based grants, and periodic review.

Building a starting layout with the Azure CLI

The following sequence assumes you have az login working and rights on the subscription. It creates a management group, places the subscription under it, creates a locked resource group and hands a team Contributor rights on that group.

• az account list --output table lists subscriptions your identity can see; copy the ID of the one you want.
• az account set --subscription "<subscription-id>" makes it the default for later commands.
• az account management-group create --name mg-landing-zones --display-name "Landing Zones" creates a management group under the tenant root.
• az account management-group subscription add --name mg-landing-zones --subscription "<subscription-id>" moves the subscription beneath it.
• az group create --name rg-web-prod --location westeurope --tags environment=prod owner=web-team creates the resource group with tags in one step.
• az group lock create --name no-delete --lock-type CanNotDelete --resource-group rg-web-prod protects it from accidental deletion.
• az role assignment create --assignee "<group-object-id>" --role Contributor --resource-group rg-web-prod grants the team's Entra group Contributor at group scope.

Every one of those commands has a Bicep equivalent, and once the layout stabilizes it belongs in source control. The introduction to infrastructure as code shows how to make that transition without recreating resources.

Frequently asked questions