Academmia

Azure Management Hierarchy: Management Groups, Subscriptions, Resource Groups, and Resources

az-900•mixed•

Azure architecture and services

Azure Management Hierarchy: Management Groups, Subscriptions, Resource Groups, and Resources

Short Summary

Azure organizes what you deploy into a clear hierarchy so you can manage access, policies, and changes consistently. In this lesson, you will learn how management groups, subscriptions, resource groups, and resources relate to each other. You will also learn how Azure Resource Manager (ARM) provides a consistent management layer across this hierarchy.

Learning Objectives

By the end of this lesson, you will be able to:

  • Describe the Azure management hierarchy (management groups, subscriptions, resource groups, and resources).
  • Explain the role of Azure Resource Manager (ARM) as the management layer for deploying and managing resources.
  • Choose an appropriate scope for organizing resources and applying governance (access, policies, locks).
  • Distinguish resource group location from resource location and explain why that matters.

Core Concepts

Azure Resource Manager (ARM) is the deployment and management service for Azure. When you create, update, or delete Azure resources using the Azure portal, Azure Command-Line Interface (Azure CLI), PowerShell, REST APIs, or SDKs, the request goes through ARM so management behavior is consistent.

Azure uses a hierarchy of management scopes:

  • Management group: a governance scope above subscriptions, used to organize multiple subscriptions and apply governance (like policies and access) across them.
  • Subscription: a logical container for billing, access control, and limits/quotas. Resources are created within a subscription.
  • Resource group: a container for related resources that you want to manage together (often because they share a lifecycle).
  • Resource: an individual Azure service instance, like a virtual machine, storage account, database, or virtual network.

Scope matters because governance settings are applied at a scope and can flow down the hierarchy. For example, when you apply a policy at a higher scope (like a management group or subscription), it can apply to the resource groups and resources beneath it. This is also how Azure role-based access control (Azure RBAC) assignments and some governance controls are commonly applied.

A resource group has a location. This location is for the resource group’s metadata and control-plane operations, not necessarily where the resources inside it run. Resources inside a resource group can be in different regions, but it’s usually simpler to align the resource group location with the main region where you operate and deploy.

Resource groups are often used for lifecycle management. If a set of resources should be deployed, updated, and deleted together (for example, a small app’s web front end, database, and monitoring), placing them in the same resource group makes coordinated management easier.

Practical Understanding

Practical Situation 1: You need consistent governance across many subscriptions

A company has multiple teams and many subscriptions. They want one set of policies (for example, allowed regions) and consistent access rules across all subscriptions.

How to think about it: Use a management group to organize the subscriptions. Apply policies and Azure role-based access control (Azure RBAC) assignments at the management group scope so they cascade to the subscriptions (and then down to resource groups and resources).

Common misunderstanding: “Subscriptions are enough; management groups are only for billing.” Management groups are primarily for governance across many subscriptions, not billing.

Practical Situation 2: You want to cleanly deploy and remove an entire solution

A team builds an environment for a proof-of-concept that includes networking, compute, storage, and monitoring. When the project ends, they want to remove everything reliably.

How to think about it: Place the related resources in a single resource group when they share a lifecycle. Deleting the resource group is a straightforward way to remove the whole set of resources together (with appropriate care and approvals).

Common misunderstanding: “Deleting a resource group just removes the folder-like container.” In Azure, deleting the resource group deletes the resources inside it as well.

Practical Situation 3: You’re confused about “resource group region” vs “resource region”

You create a resource group and must select a region, but your workload resources will run in another region.

How to think about it: The resource group’s location is where its metadata is stored and where certain control-plane operations are coordinated. Each resource still has its own location (where the service actually runs). You can mix resource locations within a resource group, but aligning them often reduces complexity and surprises during operations.

Common misunderstanding: “If the resource group is in West Europe, all resources must be in West Europe.” Resources can be in different regions than the resource group.

Common Pitfalls

  • Mistake: Treating management groups as a “nice to have” and skipping them in multi-subscription environments. Correction: Use management groups when you need governance (policy/access) that spans many subscriptions.

  • Mistake: Mixing unrelated systems in one resource group “because it’s simpler.” Correction: Group resources by shared lifecycle and ownership; separate resource groups when deployment and deletion cycles differ.

  • Mistake: Confusing subscription scope with resource group scope when assigning access. Correction: Assign Azure role-based access control (Azure RBAC) at the smallest scope that still meets the need, and remember higher-scope assignments can apply broadly.

  • Mistake: Assuming resource group location is where the resources will run. Correction: Treat resource group location as metadata/control-plane location; resource location determines where the service runs.

  • Mistake: Assuming tags applied to a resource group automatically apply to resources inside it. Correction: Tag resources intentionally; don’t rely on resource group tags to flow down.

Check Your Understanding

  1. In your own words, describe the hierarchy from management group down to resource.
  2. Think of a simple web app (web + database + monitoring). How would you group these resources, and why?
  3. When would you apply access at the subscription scope instead of the resource group scope?
  4. What does Azure Resource Manager (ARM) do when you deploy or update resources?
  5. Why might it be useful to align a resource group’s location with the main region you operate from?

Further Reading