Skip to main content

Azure Management Hierarchy and Naming Conventions

To effectively manage Azure resources, understanding the management hierarchy and applying consistent naming conventions is essential. This document explains the key management units in Azure and best practices based on the Microsoft Cloud Adoption Framework (CAF).

Azure Management Hierarchy​

The management structure of Azure consists of the following four levels:

  1. Management Groups
  2. Subscriptions
  3. Resource Groups
  4. Resources

These have a parent-child relationship, and policies and access permissions applied at a higher level are inherited by lower levels.

1. Tenant / Microsoft Entra ID​

Strictly speaking, this sits outside the Azure resource hierarchy, but it defines the identity and access boundary.

  • Represents an instance for one organization (company).
  • Manages identity information for users, groups, and applications.

2. Management Groups​

Containers for grouping and managing multiple subscriptions.

  • Usage: Governance, policy application, and compliance management across the organization.
  • Example: Grouping by "Production Environment", "Development Environment", or "Business Unit" to apply common policies (e.g., allowing usage only in specific regions).

3. Subscriptions​

Logical containers for resources and the primary boundary for billing and access control.

  • Usage: Unit of cost management, boundary for technical limits (quotas).
  • Strategy:
    • Workload Separation: Separate subscriptions for Production and Non-Production environments (Recommended).
    • Category Separation: Separate by application type or business unit.

4. Resource Groups​

Containers for logically grouping Azure resources. Every resource must belong to exactly one resource group.

  • Lifecycle Management: Group resources that share the same lifecycle (creation, update, deletion).
  • Permission Management: Unit for granting access rights only to specific project members.
  • Best Practices:
    • Deleting a resource group deletes all resources within it, which can be used for environment cleanup.
    • Consider separating resources with different lifecycles (e.g., persistent DB and temporary VM) into different groups.

Naming Conventions​

Consistent naming conventions facilitate resource identification, management, and troubleshooting. Microsoft CAF recommends combining the following components.

Basic Format: [Resource Type]-[Workload/App Name]-[Environment]-[Region]-[Instance Number]

Resource TypeAbbreviationExample
Resource Grouprgrg-myapp-prod-001
App Service Planaspasp-myapp-prod-eastus-001
App Service (Web App)appapp-myapp-prod-eastus-001
Function Appfuncfunc-myapp-prod-eastus-001
SQL Serversqlsql-myapp-prod-eastus-001
SQL Databasesqldbsqldb-myapp-prod-eastus-001
Storage Accountststmyappprod001 (Lowercase alphanumeric only)
Virtual Networkvnetvnet-myapp-prod-eastus-001
Key Vaultkvkv-myapp-prod-001

Points to Note​

  • Scope Uniqueness: Some resources like Storage Accounts and Key Vaults require globally unique names.
  • Character Restrictions: Available character types (e.g., no hyphens) and length limits vary by resource.
  • Immutable: Resource names cannot be changed after creation, so decide carefully.

Tagging Strategy​

Using tags to attach metadata in addition to names streamlines cost analysis and operational management.

  • Owner: Person responsible for the resource (email address, etc.)
  • Environment: Production, Staging, Development
  • CostCenter: Department code for billing
  • Application: Related application name
  • Criticality: High, Medium, Low (Used for disaster recovery prioritization, etc.)

Summary of Best Practices​

  1. Hierarchy Design: Leverage Management Groups to enforce governance across the organization.
  2. Subscription Separation: Separate production and development environments at the subscription level to prevent security risks and operational errors.
  3. Resource Group Lifecycle: Group resources that are deployed and deleted together.
  4. Enforce Naming Conventions: Document and adhere to rules in anticipation of automation and IaC (Infrastructure as Code) adoption.
  5. Leverage Tags: Apply mandatory tag policies for cost allocation and operational automation.