Azure Landing Zones – Resource Naming

Guidance for resource naming at enterprise-scale

Microsoft’s Cloud Adoption Framework (CAF) describes best practices for deploying applications and services into Azure.  The “enterprise-scale” architecture includes recommended designs to organise infrastructure and workload resources to ensure proper governance, security and scalability.

Azure subscriptions provide a security boundary to separate resources and services of different types.  Azure management groups are used to organise subscriptions into a meaningful hierarchy to simplify governance. 

Infrastructure (platform) subscriptions can be divided into three distinct types below, each of which can be subject to appropriate governance policies.

• Identity – e.g. Active Directory domain controllers
• Management – shared services such as monitoring
• Connectivity – network resources e.g. virtual WAN or traditional hub virtual networks

Workload resources reside in “landing zone” subscriptions.  A new landing zone should be created to support applications/services that need different security controls from those in existing landing zones. 

Landing Zones can be further organised by lower level management groups according to different policy requirements e.g. PCI landing zones.

A “canary” hierarchy mirrors the “live” management group structure and this is for testing infrastructure policies.  It is not for application code development within a subscription.

The diagram below shows a management group structure based on Microsoft’s CAF design.

With the management group hierarchy and platform resources in place, it is important to define a process for rapidly deploying new landing zones to support workload requirements.  This is often referred to as a “subscription vending machine”.  The key to supporting this approach is a robust naming standard for subscriptions and resources contained within them.

Firstly, the subscription should be named to indicate its position within the management group hierarchy.  Secondly, it is useful to identify the environment so that production resources for example can be differentiated from non-production counterparts. Alternatively, the environment indicator could be set as a resource tag instead of embedded within the naming convention. The example below shows one approach:

Subscription name ab1234 where:

• a:
  • z = landing zone
  • i = identity
  • m = management
  • n = connectivity/network
  • x = sandbox
• b:
  • p = production
  • d = development
  • t = test
  • s = staging
  • q = quality assurance
  • c = canary
• 1234
  • unique index

The subscription identifier (subid) can then be used to name individual resources within that subscription.

General good practice naming guidelines include:

• Use lower case for all resources (as some resources mandate that condition)
• Use hyphens to separate naming components where possible
• Prefix with resource type (Recommended abbreviations for Azure resource types – Cloud Adoption Framework | Microsoft Docs)
• Suffix with function or index or both
• Include a short organisation identifier (e.g. abc) to improve chances of global uniqueness for resources such as key vaults
• Include a three-character location identifier (e.g. uks) for resources that are fixed by region (e.g. virtual networks) but not for those that may be migrated or recovered between sites (e.g. virtual machines)
• Keep names as succinct as possible
• Use resource tagging instead of naming for attributes that may change (e.g. department)

Examples are shown below: