Azure Resource Hierarchy: Tenant, Management Groups, Subscriptions

Understanding the Azure resource hierarchy is fundamental for effective governance, cost management, and security in any cloud deployment. This structured…

Understanding the Azure resource hierarchy is fundamental for effective governance, cost management, and security in any cloud deployment. This structured approach, from the top-level tenant down to individual resources, dictates how policies are applied, permissions are inherited, and costs are tracked. Grasping each layer's role and its interdependencies is crucial for architects and administrators designing robust Azure environments.

Azure Tenant (Microsoft Entra ID)

At the very pinnacle of the Azure hierarchy is the Azure Tenant, which is inextricably linked to a Microsoft Entra ID (formerly Azure Active Directory) instance. This tenant represents a single organization and serves as the primary identity and access boundary for all resources and subscriptions associated with it. When you create an Azure account, an Entra ID tenant is automatically provisioned.

• Identity Boundary: The Entra ID tenant manages user identities, groups, and application registrations. All authentication and authorization for resources within the tenant's subscriptions are handled here.
• Global Uniqueness: Each Entra ID tenant has a globally unique ID (GUID). For example, xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
• Root Scope for RBAC and Policies: While not directly a scope for Azure resources in the same way as Management Groups or Subscriptions, the Entra ID tenant implicitly defines the overall security and compliance context for all connected Azure objects. Permissions assigned at the tenant root scope (e.g., "User Access Administrator" or "Global Administrator" Entra ID roles) have immense power across all subscriptions.
• Relationship to Subscriptions: A single Entra ID tenant can host multiple Azure subscriptions. Conversely, a single Azure subscription can only belong to one Entra ID tenant at any given time. However, a subscription can be moved between tenants, albeit with significant implications for RBAC and service principals.

Management Groups

Management Groups (MGs) provide a layer of organization above subscriptions, enabling you to manage access, policies, and compliance across multiple subscriptions simultaneously. This is particularly valuable for large organizations with numerous subscriptions segmented by department, environment (dev/test/prod), or geographical region.

• Hierarchy: MGs can be nested up to six levels deep (not including the root management group). The top-level is the "Tenant Root Group," which every tenant automatically gets. All subscriptions and other MGs eventually roll up to this root.
• Policy and RBAC Inheritance: This is the primary benefit of MGs. Policies (Azure Policy) and Role-Based Access Control (RBAC) assignments applied at a management group level are inherited by all child management groups and subscriptions within that hierarchy. This drastically simplifies compliance and security enforcement.
• Use Cases:
  • Applying common security baselines (e.g., "Require HTTPS for all storage accounts").
  • Enforcing naming conventions.
  • Controlling allowed Azure regions for resource deployment.
  • Granting a group of users (e.g., "Cloud Operations Team") Contributor access to all subscriptions under a specific MG subtree.
• CLI Example (Creating a Management Group and moving a subscription):

# Install Azure CLI Management Group extension if not already installed
az extension add --name managementgroup

# Create a new Management Group named "ProdMG" under the Tenant Root Group
az management-group create --name "ProdMG" --display-name "Production Workloads" --parent "/providers/Microsoft.Management/managementGroups/<your_tenant_root_id>" 

# Move an existing subscription (replace with your subscription ID) to the new Management Group
az account management-group subscription add --name "ProdMG" --subscription <your_subscription_id>

# Verify the subscription is now under ProdMG
az account management-group subscription show --name "ProdMG" --query "value[?id=='/subscriptions/<your_subscription_id>']"

The <your_tenant_root_id> is usually the Tenant ID or "Tenant Root Group" as the display name for the root. You can find it via az management-group show --name "Tenant Root Group" --query id -o tsv.

Design Considerations for Management Groups

• Flat vs. Deep Hierarchy: A flatter hierarchy is often easier to manage initially, but a deeper one can provide more granular control for large organizations. Strive for a balance that reflects your organizational structure and governance needs.
• Environment-based: Common to have MGs like LandingZones -> Prod, Dev, Test.
• Department-based: Sales, Engineering, Finance.
• Application-based: For very large, critical applications that span multiple subscriptions.

Subscriptions

An Azure subscription is a logical container for your Azure resources and services. It serves as a billing unit and a boundary for resource quotas and usage. Every resource you deploy in Azure must reside within a subscription.

• Billing Unit: All costs incurred by resources (VMs, storage, databases, networking, etc.) within a subscription are aggregated and billed to that subscription's associated billing account.
• Resource Quotas: Subscriptions have default limits and quotas for various resources (e.g., number of cores, storage accounts, network interfaces per region). These can often be increased by contacting Azure support. Example: A typical subscription might have a default quota of 20 vCPUs per region for certain VM series.
• RBAC Boundary: Permissions assigned at the subscription level apply to all resource groups and resources within that subscription.
• Logical Grouping: Subscriptions are often used to group resources based on purpose (e.g., "Development Subscription," "Production Subscription"), owner (e.g., "Marketing Dept Subscription"), or environment.
• Associated with an Entra ID Tenant: As mentioned, each subscription is linked to a single Entra ID tenant for identity management.

Subscription Types

Azure offers several subscription types, each with different billing models and features:

Resource Groups

Resource Groups (RGs) are the lowest logical grouping layer directly above individual resources. An RG is a container that holds related resources for an Azure solution.

• Lifecycle Management: All resources within a resource group share the same lifecycle. If you delete a resource group, all resources within it are also deleted. This makes RGs ideal for grouping resources that you want to manage, deploy, and delete together (e.g., all components of a web application: VM, storage account, virtual network, public IP).
• RBAC Scope: Permissions applied at the resource group level apply to all resources within that group. This is a common scope for granting granular access to application teams.
• Location (Metadata): While resources within an RG can be deployed to different Azure regions, the Resource Group itself has a location property. This location is used for storing resource group metadata and is relevant for certain regional operations but does not dictate the region of its contained resources.
• Naming Conventions: Enforcing consistent naming conventions for RGs (e.g., rg-appname-env-region like rg-webapp01-prod-eastus) is a best practice for clarity and automation.
• CLI Example (Creating a Resource Group):

# Create a Resource Group named "myWebAppRG" in the "eastus" region
az group create --name myWebAppRG --location eastus

# Deploy a simple Storage Account into this Resource Group
az storage account create \
    --name mystorageaccount012345 \
    --resource-group myWebAppRG \
    --location eastus \
    --sku Standard_LRS \
    --kind StorageV2

# List resources within the Resource Group
az resource list --resource-group myWebAppRG --output table

Resources

Resources are the individual instances of Azure services that you create and manage. This is the bedrock of your Azure deployment.

• Examples: Virtual Machines (VMs), Storage Accounts, Virtual Networks (VNets), Databases (Azure SQL Database, Cosmos DB), App Services, Load Balancers, etc.
• Deployment: All resources must be deployed within a resource group, which in turn belongs to a subscription.
• Tags: Resources can be tagged with key-value pairs (e.g., Environment: Production, CostCenter: 12345). These tags are invaluable for cost management, inventory, and policy enforcement, especially when used in conjunction with Azure Policy.

RBAC (Role-Based Access Control)

RBAC is Azure's authorization system, allowing you to manage who has access to Azure resources, what they can do with those resources, and what areas they can access. It operates on an "allow" model.

• Scope of Application: RBAC can be applied at any level of the hierarchy: Management Group, Subscription, Resource Group, or individual Resource.
• Inheritance: Permissions granted at a higher scope are inherited by all child scopes. For instance, if a user is granted "Contributor" role at the subscription level, they will have contributor access to all resource groups and resources within that subscription.
• Principle of Least Privilege: Always grant the minimum necessary permissions.
• Built-in Roles: Azure provides numerous built-in roles (e.g., Owner, Contributor, Reader, User Access Administrator, Virtual Machine Contributor, Storage Blob Data Contributor).
• Custom Roles: You can create custom RBAC roles if built-in roles don't meet your specific requirements.

# Grant the 'Contributor' role to a user at a specific Resource Group scope
# Replace <user_object_id> with the Azure AD object ID of the user
az role assignment create \
    --role "Contributor" \
    --assignee-object-id <user_object_id> \
    --resource-group myWebAppRG \
    --assignee-principal-type User 

# Show all role assignments for a specific scope (e.g., subscription)
az role assignment list \
    --subscription <your_subscription_id> \
    --query "[].{principalName:principalName, roleDefinitionName:roleDefinitionName, scope:scope}" \
    --output table

Azure Policy

Azure Policy helps enforce organizational standards and assess compliance at scale. It defines rules that resources must adhere to, preventing non-compliant deployments or flagging existing ones.

• Scope: Policies can be assigned at the Management Group, Subscription, or Resource Group level. Management Group is generally preferred for organization-wide guardrails.
• Initiatives (Policy Sets): Groups of related policies can be combined into initiatives for easier assignment and management.
• Effects: Policies have various effects like Deny (prevents resource creation/update), Audit (flags non-compliance without blocking), DeployIfNotExists (deploys resources if a condition is met), Modify, and Append.
• Use Cases:
  • Enforcing approved SKUs for VMs.
  • Requiring specific tags on resources.
  • Auditing resources that don't use encryption.
  • Limiting resource deployments to specific regions.

Common Pitfalls

• Over-provisioning RBAC: Granting "Owner" or "Contributor" at a high level (e.g., Management Group or Subscription) too broadly violates the principle of least privilege and creates security risks. Use built-in roles specific to tasks where possible.
• Disorganized Subscriptions/Resource Groups: A lack of clear strategy for grouping resources leads to "resource sprawl," making cost tracking, policy enforcement, and management extremely difficult. Plan your hierarchy before deploying extensively.
• Ignoring Management Groups: For organizations with more than a few subscriptions, failing to implement Management Groups means duplicating policy and RBAC assignments across each subscription, leading to inconsistent governance and increased administrative overhead.
• Policy Conflicts: When policies are assigned at different scopes, conflicts can arise. Azure Policy applies the most restrictive "deny" takes precedence. Thorough testing of policy assignments is essential.
• Incorrect Quota Planning: Hitting subscription or regional quotas unexpectedly can halt deployments. Monitor usage and request increases proactively, especially for critical production environments.
• Unused Resources: Forgetting to delete resources after development or testing can lead to significant unexpected costs. Leverage resource groups to manage resource lifecycles effectively.