Management Groups and Subscriptions

Azure organises resources into a four-level hierarchy. At the top are Management Groups — containers that group subscriptions for policy and access control at scale. Below are Subscriptions — billing and resource boundary units. Within subscriptions are Resource Groups — logical containers for related resources. At the bottom are Resources — individual services like VMs, databases, and storage accounts. Policies and permissions applied at higher levels cascade downward.

An Azure subscription is both a billing unit and a logical resource boundary. All resource usage in a subscription is billed to a single invoice. Subscriptions set limits (quotas) on how many resources of each type can be deployed. Organisations commonly create separate subscriptions for different environments (Production, Development, Testing), different business units, or different geographic regions — each with its own cost reporting and access control.

Large enterprises use multiple subscriptions for several reasons. Isolation — production resources are completely isolated from dev/test; a misconfiguration in dev cannot affect production. Billing granularity — each department's subscription generates its own invoice for clear cost allocation. Subscription limits — Azure has per-subscription quotas (e.g., 250 VMs per region); large workloads may need multiple subscriptions to stay within limits.

A Management Group is a container above subscriptions in the Azure hierarchy. You can organise subscriptions into management groups and apply Azure Policy definitions and RBAC role assignments at the management group level. These cascade down to every subscription and resource within the group. This eliminates the need to duplicate the same policy or role assignment across dozens of individual subscriptions.

Management groups can be nested up to six levels deep. Every Azure directory has a single Root Management Group at the top, which all other management groups and subscriptions fall under. A typical enterprise hierarchy might be: Root → Company → Platform → Production → Landing Zones → Individual Workload Subscriptions. Policies applied at the Root level affect every subscription in the entire directory.

Access control assignments at any level in the hierarchy inherit downward. If you assign a user the Reader role on a management group, they automatically get Reader access on every subscription and resource group within that management group. This inheritance is additive — you cannot revoke an inherited permission at a lower scope (you can only add more permissions). Deny assignments are the exception: they block actions even when a role assignment would permit them.

Similarly, Azure Policy assignments at a management group level apply to all subscriptions, resource groups, and resources within that group. A common pattern is assigning a corporate baseline policy at the root or company management group to enforce standards like allowed regions, mandatory tags, or required diagnostic settings across the entire organisation, while individual subscription owners can add more specific policies below without overriding the corporate baseline.

Azure subscriptions can be created, renamed, cancelled, and moved between management groups. Moving a subscription to a different management group changes which policies and role assignments apply to it — policy changes take effect immediately on all resources in the subscription. Cancelling a subscription disables resource creation and eventually deletes all resources within it after a grace period, so this action should only be taken with careful planning.

Large organisations access Azure through billing agreements that affect how subscriptions are structured. An Enterprise Agreement (EA) provides subscriptions under an enrolment with a central billing account for large committed spend. A Microsoft Customer Agreement (MCA) is the modern successor, offering more self-service subscription management. Under both, billing profiles and invoice sections let you group subscription charges for different departments.

Every Azure subscription has service quotas — soft limits on how many resources of each type can exist per region. Default examples: 20,000 vCPUs per region, 980 resource groups per subscription, 800 managed disks per subscription. When your workload approaches a quota, you can submit a quota increase request in the Azure portal (Support + troubleshooting > New support request). For massive scale-out, Microsoft recommends distributing workloads across multiple subscriptions.

Microsoft recommends several best practices for management group design. Avoid more than three to four levels of nesting — too many levels make policy troubleshooting complex. Create a dedicated Platform management group for shared services (identity, connectivity, management) separate from landing zone workloads. Separate Production and Non-Production into different management groups so production-only policies (like disabling public internet access) do not accidentally apply to dev environments.

Test your understanding of Microsoft Azure Fundamentals (AZ-900) concepts from this lesson.

In this lesson you learned: the Azure resource hierarchy flows from management groups to subscriptions to resource groups to resources, policies and RBAC assignments at management group level inherit downward to all child subscriptions, and multiple subscriptions provide billing isolation, environment separation, and workaround for per-subscription quotas. Next up we explore Azure Policy in depth.