Azure Resource Hierarchy: Management Groups, Subscriptions & Resource Groups | Cloud & AI Tutorial

When organizations migrate workloads to Microsoft Azure, provisioning resources haphazardly across unmanaged subscriptions creates security chaos, financial sprawl, and compliance failures. Without a structured management architecture, cloud administrators struggle to answer basic questions: Which department owns this virtual machine? Who is authorized to access this storage account? Why did this month's cloud invoice spike unexpectedly?

To establish enterprise governance, cost accounting, and access control at scale, Azure structures all cloud assets through the Azure Resource Manager (ARM) Hierarchy.

The Four Scopes of the Azure Resource Hierarchy

Azure organizes all infrastructure components into a strict four-level top-down governance tree. Settings, permissions, and policies applied at a higher scope are automatically inherited by all child scopes beneath it.

Hierarchy Level	Scope Entity	Governance & Operational Purpose
Level 1 (Top)	Management Groups	Containers that group multiple Azure subscriptions together. Enables enterprise-wide policy enforcement (Azure Policy) and access management (RBAC) across multiple subscriptions simultaneously.
Level 2	Subscriptions	The fundamental billing and quota boundary in Azure. Links resource usage directly to an Azure billing account and establishes default regional compute/network capacity quotas.
Level 3	Resource Groups (RGs)	Logical containers that group related Azure resources that share the same lifecycle (e.g. deployed together, monitored together, and deleted together).
Level 4 (Bottom)	Resources	Individual deployable service instances: Virtual Machines, Storage Accounts, Virtual Networks, SQL Databases, Key Vaults, and Network Security Groups.

Level 1: Management Groups & Enterprise Root

Every Azure tenant features an automatic Tenant Root Management Group at the very top of the hierarchy. Organizations can build a management group tree up to six levels deep to mirror their corporate business structure:

Core Architecture: An enterprise might create a Production Management Group and a Non-Production Management Group beneath the Root.
Policy Inheritance: If an administrator assigns an Azure Policy requiring all storage accounts to enforce TLS 1.2 at the Production Management Group level, every current and future subscription inside that group automatically enforces that compliance rule without manual intervention.

Level 2: Subscriptions (Billing & Security Boundaries)

A single enterprise Azure deployment should almost never rely on just one subscription. Subscriptions serve two critical architectural functions:

Billing Separation: Each subscription generates distinct invoice line items. Organizations assign distinct subscriptions to business units (e.g. Sub-Finance-Prod, Sub-Marketing-Dev) to facilitate FinOps chargeback and showback.
Scale Limits & Isolation: Azure enforces subscription-level resource limits (e.g. maximum vCPU counts per region). Splitting production, development, and testing into separate subscriptions prevents a runaway dev script from exhausting production compute quotas.

Level 3: Resource Groups (Lifecycle Management)

A Resource Group is not just an administrative folder; it is a lifecycle boundary:

The Core Golden Rule: Place resources that share a common lifecycle in the same Resource Group. For example, a three-tier web application (Web VM, App VM, SQL DB, Virtual Network) that is deployed and decommissioned together belongs in a single Resource Group.
Regional Independence: A Resource Group has a metadata location (e.g. East US), but the resources inside that group can physically reside in completely different Azure regions.
Cascading Deletion: Deleting a Resource Group automatically deletes every single resource contained inside it, preventing orphaned storage disks and unused public IPs from accumulating hidden cloud costs.

Resource Locks: Preventing Accidental Deletion

Because deleting a Resource Group instantly destroys all child assets, enterprise production environments apply Azure Resource Locks (CanNotDelete or ReadOnly) at the Resource Group scope. A CanNotDelete lock prevents even a Subscription Owner from deleting the group until the lock is explicitly removed.

Inheritance of Role-Based Access Control (RBAC)

Azure Role-Based Access Control (Azure RBAC) governs user authorization across the hierarchy:

If a DevOps engineer is granted the Contributor role at a Resource Group scope, their permissions are strictly confined to managing resources inside that specific Resource Group. They cannot view or modify resources in adjacent Resource Groups.
If an identity is granted Reader at the Management Group scope, that identity inherits read-only visibility across every subscription, resource group, and resource governed by that management group.

Managing Resource Groups via Azure CLI

Azure CLI (Bash / PowerShell)

# 1. Create a production Resource Group in East US with enterprise governance tags
az group create \
    --name "rg-ecommerce-prod-eastus" \
    --location "eastus" \
    --tags Environment="Production" Department="Engineering" CostCenter="CC-4050"

# 2. Apply a CanNotDelete lock to protect all child assets from accidental deletion
az lock create \
    --name "lock-prevent-deletion" \
    --resource-group "rg-ecommerce-prod-eastus" \
    --lock-type CanNotDelete

# 3. List all resources contained within the Resource Group
az resource list --resource-group "rg-ecommerce-prod-eastus" --output table

Summary

The Azure Resource Manager hierarchy provides the architectural scaffolding for enterprise cloud governance. By structuring cloud assets through Management Groups for global compliance, Subscriptions for billing and quota boundaries, Resource Groups for lifecycle cohesion, and enforcing RBAC inheritance with Resource Locks, cloud architects establish a secure, organized, and cost-controlled Azure enterprise foundation.