change-my-mind-naming

In this post, I’m sharing the naming convention I’ve been using for the biggest Azure infrastructure projects during my career at Microsoft and EPAM. Since 2015, it has proven to work well in enterprise-scale environments long before Microsoft introduced CAF and the concept of Landing Zones.

I’ve noticed that many customers tend to take CAF’s guidance on naming conventions too literally, which is far from perfect when you move beyond test lab scales.

It’s probably too late for you to change the naming convention of Azure resources, as the cloud adoption curve has been past its peak for years. So, now could be a good time to share my old “trade secret”.

Naming principles

  • Generic naming pattern is:

tex2img_equation

  • Names are divided into sections. The sections could be <Mandatory> or [Optional]
  • In most cases, a hyphen (-) is used to separate naming sections, and an underscore (_) can be used to divide parts within the same section. Other symbols are less suitable as separators, because of worse compatibility with URL and DNS standards, along with existing Azure resource naming restrictions.
  • Sections are ordered to have bigger ‘taxons’ first.

    System > Environment > Region > Component > Instance > Resource_Type

    This helps to navigate, search, and keep the structure when resources are sorted alphabetically
  • Names of logically ‘child’ resources are appended to the ‘parent’s’ name. This helps to have ‘child’ resources grouped with their parents when sorted alphabetically.

    For example, virtual network gateways are attached to a virtual network, so they are considered ‘child’ resources and displayed together with their parent when resources are sorted alphabetically or searched:
    • PlatCon-PRD-EUW-Hub-vnet (for virtual network)
    • PlatCon-PRD-EUW-Hub-vnet-vnge (for express route gateway)
    • PlatCon-PRD-EUW-Hub-vnet-vngv (for VPN gateway)
    • PlatCon-PRD-EUW-Hub-vnet-vngv-T_Systems-con (for VPN gateway connection)
  • It should be possible to skip some sections where they are not applicable like there is no region for some kinds of resources
  • There could be exclusions from the generic pattern (for instance, VM names are better to specify the same as OS hostname to avoid many hidden stones; there could be names that cannot include some characters, like storage accounts)
  • Names may use both UPPERCASE and lowercase characters to support better readability and accessibility, where allowed by the resource type. Although some resources (like storage accounts) and other cloud providers (like AWS) have more restrictive rules on naming, they should not set the bar for the readability of all other Azure resources
  • Names of globally unique resources like storage accounts should have short suffix derived from the company name, like ‘iro’ (as abbreviation of my name) to avoid overlapping with resource names of other customers
  • No need to spend time to define conventions for all possible resource types in Azure, using the same principles you can expand your convention when needed

Naming sections

Below are the sections of the resource names in the order they should be used.

Naming section Description Examples
System To divide big company-wide systems, service lines, or business units from each other.

Order position 1, the highest unit of division. This could be a company-wide system name, like SAP, AVD, SharedServices; or an alias of a business unit if they prefer to manage multiple applications in a single group		 SAP, AVD, Security, SharedSvc, PlatMgmt
Environment To separate different environments of the same system.

Order position 2, since systems are often divided into different environments. Usually, the components inside the environment may share the same components, infrastructure, and security measures.		 SBX, DEV, QA, NPR, PRD
Region To accommodate expansions of the system to other regions without naming conflicts.

Order position 3, since the same environment often spans across multiple regions. Even if you never plan to expand your system to other regions, this may come in the future as a common architecture pattern for cloud high availability and disaster recovery.		 EUW, EUN
Component Optional name of system’s component, such as application, workload, or service that the resource is a part of.

Used to distinguish subsystems within the same System.

Order position 4, since inside the same environment and region the system might have various logical parts. By dividing a system into logical components that share the same lifecycle and purpose, you leverage the intended use of Resource Groups concept.		 Network, ADDC, ADFS, NVA_Int, NVA_Ext, FrontEnd, BackEnd, App1_DB

Note the optional instance indicator that could be included into this segment as a digit or text like DB, see description of virtual Instance section below
Resource type Always at the end of the resource name, with some rare exceptions.

Order position 5, contrary to the popular example of the naming convention in CAF, resource type should be at the end of the name (suffix) to support the whole concept or name section ordering from big taxons to small. Putting the resource type at the beginning of the names (prefix) breaks this whole concept and leads to a naming standard that is not convenient to use on a big scale.		 vnet, nsg, log, …

Virtual naming sections

The sections below are virtual – they are constructed based on the sections defined above for the purpose of grouping and automation.

Naming section Description Examples
Landing Zone Constructed as ‘System-Environment’.

Usually, System-Environment forms a unit of separation of duties, security, and concerns, which corresponds to a model of Landing Zone, and is a good candidate for a dedicated subscription.		 Security-PRD, SharedSvc-QA
Instance Optional instance indicator for a specific resource, to differentiate it from other resources in the same logical array, like disks, virtual machine instances of the same service, and cluster nodes.

Many organizations used to use padding for the instance count, no matter if the resource could even have multiple instances and how many of them are possible.

It is recommended to be wise and use padding only when necessary, for example, if in your organization you have only 6 domain controllers, no need to pad their instance counts into 4 digits, like DC0001, DC0002; padding with 2 digits like DC01, DC02 is enough for this purpose.		 NVAPEUWFW01
NVAPEUWFW02
instance count is padded as XX for 2 firewall instances, it supports upgrade and migration scenarios when you need room for more instances in the name

PlatConn-PRD-EUW-Hub-vnet-afw
PlatCon-PRD-EUW-Hub-vnet-bas
a vnet can have only one firewall and one bastion resource attached, so it does not make sense to include any instance count in the name of the resource

NVAPEUWFW01-D_LUN01-md
NVAPEUWFW01-D_LUN02-md
NVAPEUWFW01-D_Log1-md
NVAPEUWFW01-D_Log2-md these are examples of multiple managed disk instances attached to the same vm with name NVAPEUWFW01
[expand to see] A note on padding from CAF

Padding improves readability and sorting of assets when those assets are managed in a configuration management database (CMDB), IT Asset Management tool, or traditional accounting tools. When the deployed asset is managed centrally as part of a larger inventory or portfolio of IT assets, the padding approach aligns with interfaces those systems use to manage inventory naming.

Unfortunately, the traditional asset padding approach can prove problematic in infrastructure-as-code approaches that might iterate through assets based on a non-padded number. This approach is common during deployment or automated configuration management tasks. Those scripts would have to routinely strip the padding and convert the padded number to a real number, which slows script development and run time.

Choose an approach that's suitable for your organization. Before choosing a numbering scheme, with or without padding, evaluate what will affect long-term operations more: CMDB and asset management solutions or code-based inventory management. Then, consistently follow the padding option that best fits your operational needs.

— CAF: Define your naming convention


Resource type abbreviations

The table below illustrates abbreviations for the most used resources. When expanding existing naming convention for new resource types, it’s a good practice to use well-known abbreviations from CAF: Abbreviation examples for Azure resources.

Resource type Abbreviation
Resource Group rg
Virtual Network vnet
Network Security Group nsg
Network Interface nic
Managed Disk md
.. ..

Region abbreviations

Contrary to CAF which provides examples for region abbreviation as westus, eastus2, westeu; it’s better to follow the logic of natural grouping by regions when alphabetically sorting the resources, so West and North Europe should be abbreviated as EUW and EUW, East and West US should be abbreviated USW and USE respectively.

Region Abbreviation
West Europe EUW
North Europe EUN
East US USE
East US 2 USE2
Central US USC
.. ..

Note: The list of regions is constantly expanding, it will be challenging to accommodate all possible regions into 3 characters and keep it readable, so it’s a good idea to have region abbreviation flexible.

Naming restrictions

Please be aware that most Azure resources have restrictions in terms of length and characters, and may require to be globally unique across all Azure customers.

Please refer to Naming rules and restrictions for Azure resources for details and updates.

Naming convention table

The table below describes common resource naming conventions with comments explaining cases when naming does not exactly follow the common pattern:

<System>-<Environment>-<Region>[-Component]-<res_type>

The table is supposed to be a living document, and be updated as new resource types are introduced into the environment.

Resource Type Scope Format + Examples + Comments
Governance
Management Group Tenant <GroupName>-mg
Display Name for MG can be different from MG actual resource name and is easy to change.

Even though management groups are rarely handled together with other resource types, it still makes sense for them to have a name suffix of (-mg) since it helps to distinguish -MGs from -Subs when only using names in diagrams and communications.

• Platform-mg
• SAP-PRD-mg
Subscription Account/Enterprise Agreement <System>[-Env][-Component]-sub
Note that subscription names are easy to change when needed, however, it is still a good practice to keep subscription names consistent and aligned. Subscriptions might still benefit from having a resource type suffix (-sub), to help to distinguish them from management groups.

• SAP-PRD-sub Note the omitted region segment since subscription by definition may contain resources from multiple regions
• AVD-PRD-sub For subscriptions dedicated to a single system, the name of the subscription before (-sub) can form the Landing Zone prefix for all the resources inside.
• BUnit1-PRD-sub For subscriptions hosting multiple systems inside, the sub name without type extension (-sub) can still be used as a common prefix for all shared components, like networking.
• PlatformConnectivity-sub For platform related subscriptions, such as Connectivity, which can be shared among different environments, ‘environment’ section can be skipped if there is no plan to deploy non-production resources.
Resource Group Subscription <System>-<Env>[-Component]-rg

• SAP-PRD-EUW-App1_DB-rg
• PlatCon-PRD-EUW-Network-rg
• PlatIdty-PRD-EUW-ADDC-rg
• SharedSvc-PRD-EUW-Network-rg
Policy Definition Management Group or Subscription <PolicyName>-pol
Display Name for a Policy Definition is easy to change. Actual Policy definition resource names can even use a GUID pattern to ensure uniqueness, but you might wat to hve them stable to preserve policy assignments during policy definition updates.

• Custom-Enable-Storage-Diagnostics-pol
• Custom-Enable-NSG-Flow_Logs-pol
Policy Set (Initiative) Management Group or Subscription <InitiativeName>-ini
Display Name for a Policy Initiative is easy to change. Same as with policy definitions, you might wat to have them stable to preserve policy assignments during policy set updates.

• Custom-Required-Deploy-ini
• Custom-Optional-Monitor-ini
Networking
Virtual Network Resource group <System>-<Env>-<Region>[-Component]-vnet

• PlatCon-PRD-EUW-Ext-vnet
• PlatCon-PRD-EUW-Hub-vnet

• SAP-PRD-EUW-vnet Note that vnet name may omit the component segment (like Hub or Ext) if SAP-PRD Landing Zone is designed to have only one vnet.
Subnet Virtual network <App>[-Component]
Note that subnet names are just attributes of a vnet, there is no need to make them globally unique or specify CIDR inside the subnet name. Keeping subnet names short and simple helps when managing and diagnosing networking on Azure portal since shorter subnet names are displayed fully in the GUI and not truncated with … in the most interesting place.

• NVA_Hub-Mgmt
• AD-DC
• App1-FE
• App1-BE
Using hyphen (-) to destingush different components of the same app

• GatewaySubnet
• AzureBastionSubnet
• AzureFirewallSubnet
These subnet names are predifined. There is no need to have Subnet as a name suffix for non-predefined subnets.
Azure Firewall Resource group <parent_vnet_name>-afw

•  PlatConn-PRD-EUW-Hub-vnet-afw
Azure Bastion Resource group <parent_vnet_name>-bas

•  PlatCon-PRD-EUW-Hub-vnet-bas
Virtual network gateway Resource group <parent_vnet_name>-vnge
for ER gateway
• PlatCon-PRD-EUW-Hub-vnet-vnge

<parent_vnet_name>-vngv
for VPN gateway
• PlatCon-PRD-EUW-Hub-vnet-vngv
Gateway connection Resource group <parent_vng_name>[-Component]-con
for ER connection
•  PlatCon-PRD-EUW-Hub-vnet-vnge-C_EquinixAMS-con

<parent_vng_name>[-Component]-con
for VPN S2S connection
•  PlatCon-PRD-EUW-Hub-vnet-vngv-S_TSystemsFRA-con
Local network gateway (VPN) Resource group <parent_vng_name>[-Component]–lng

•  PlatCon-PRD-EUW-Hub-vnet-vngv-L_TSystemsFRA-lng
Route Table Resource Group <parent_vnet_name>[-Component]-rt
for route tables deployed in the same resource group as vnet
• PlatCon-PRD-EUW-Hub-vnet-R_Default-rt
• PlatCon-PRD-EUW-Hub-vnet-R_GatewaySubnet-rt

<System>-<Env>-<Region>[-Component]-rt
for route tables on app level, like deployed inside NVA resource group
• SAP-PRD-EUW-App1_DB-rt
• SAP-PRD-EUW-App1_FE-rt
Route Route Table <PeeredVnetName>[_#]
for routes pointing to peered vnets, use names of target vnets as route names
• PlatIdty-PRD-EUW-vnet

• SharedSvc-PRD-EUW-vnet_0
• SharedSvc-PRD-EUW-vnet_1
with optional instance numbers when the target vnet has multiple address space

[RouteName]
this format is used for other custom routes
• LAN_10
• LAN_192
• Default
Network Security Group Resource group <parent_vnet_name>[-Component]-nsg
for NSGs deployed in the same resource group as vnet
• SAP-PRD-EUW-vnet-nsg
• PlatCon-PRD-EUW-Hub-vnet-N_Diag-nsg
• PlatCon-PRD-EUW-Hub-vnet-N_Default-nsg

<System>-<Env>-<Region>[-Component]-nsg
for NSGs on app level, when deployed inside the app’s own resource group
• PlatIdty-PRD-EUW-ADDC-nsg
Load Balancer Resource group <System>-<Env>-<Region>[-Component]-lbe
for External Load balancer
• PlatCon-PRD-EUW-NVA_Ext-lbe

<System>-<Env>-<Region>[-Component]-lbi
for Internal Load balancer
• PlatCon-PRD-EUW-NVA_Ext-lbi
Load Balancer configuration Load Balancer While names of objects in Load Balancer configuration do not have to be unique outside the Load Balancer, the config itself might get quite complex and would benefit from using descriptive and well-thought names.

<FE_Name>-fe
for Load balancer FrontEnd
• FrontEnd1-fe

<Probe_Name>-probe
for Load balancer Probe
• SSH-probe

<Rule_Name>-rule
for Load balancer Rule
• HA-rule

<BE_Name>-be
for Load balancer BackEnd
• BackEnd1-be
Public IP Resource group <parent_name>[-PIP_Name]-pip
Below are examples of various situations when PIPs are used

• PlatCon-PRD-EUW-Hub-vnet-bas-pip single PIP attached to a bastion
• PlatCon-PRD-EUW-Hub-vnet-vngv-IP2-pip multiple PIPs attached to a VPN gateway
• PlatCon-PRD-EUW-NVA-N_Ext-lbe-pip signle PIP attached to a load balancer
• App1-PRD-EUW-FrontEnd-lbe-IP24-pip multiple PIPs attached to a load balancer
• ADPEUWDC01-nic-pip single PIP attached to a VM with a single interface
• NVAEUWROS1-N_Mgmt-nic-pip single PIP attached to a VM with multiple interfaces
DNS Label Global <FreeText>-iro
Should be unique accross all customers in the region, it might need to include a company differentiator to distinguish from other customers
• NVAEUWROS1-iro
Virtual Machines
Virtual Machine Resource group
but actually you might want to have it unique within your network		 Names of VM resources on Azure should match OS hostnames running on those VMs for consistency. To quote Microsoft: Keeping Azure VM names shorter than the naming restrictions of the OS helps create consistency, improve communication when discussing resources, and reduce confusion when you’re working in the Azure portal while being signed in to the VM itself.

OS hostnames, in their turn, should follow existing corporate naming standards and comply with restrictions of operating systems, like using reduced character set (A-Z, 0-9, and ‘-’ only), and length up to 15 characters (to be compatible with both NETBIOS and DNS).

However, if you have a luxuary of starting from a scratch, here is my suggestion:

<SYS><ENV><REG><ROLE><##[#]>
where:
- SYS: system abbreviation, 3-4 characters, like SAP, AD, NVA
- ENV: environment, 1-2 chars like S,D,Q,P
- REG: region, 2-3 chars like EUW, EUN
- ROLE: abbreviation of role of server in the system
- ## - 2-3 digits of intance counter

• ADPEUWDC01 AD Prod EU_West DC 01
• NVAPEUWFW01 NVA Prod EU_West Firewall 01
• SAPPEUWBWA01 SAP Prod EU_West BW Application 01

Note: Hostnames use only UPPERCASE for a reason, this helps visual accesibility when working with FQDNs, where domain names are traditionally lowercase, you get FQDN in the format HOSTNAME.domain.name
NIC Resource group <parent_vm_name>[-Nic_Name]-nic

• ADPEUWDC01-nic
• NVAPEUWFW01-N_Int-nic
• NVAPEUWFW01_N_Ext-nic
Managed Disk Resource group <parent_vm_name>[-Disk_Name]-md

• ADPEUWDC01-D_OS-md
•IAUDEUWBT001-D_LUN1-md
Availability Set Resource group <System>-<Env>-<Region>[-Component]-as

• PlatIdty-PRD-EUW-ADDC-as
• PlatCon-PRD-EUW-NVA-as
• SAP-PRD-EUW-BWA-as
Storage
Storage account Global This type of extremely popular resource has the strictest restrictions on naming: needs to be globally unique across all customers and regions of Azure Cloud, and use only 24 alphanumeric lowercase characters (a-z, 0-9). This makes storage account naming the toughest to make it human-readable. If nothing changes in Azure platform, at some point in time it could be required to use GUID-like storage account names and use different ways (like tags and friendly name aliases) to identify storage accounts.

Below is the proposed approach to keep storage account names as human-accessible as possible.

<sys><env><reg>[comp]irosa
To comply with SA restrictions, shorter naming segments (like for hostnames) should be used:
- sys: abbreviation of system, like shsvc, pcon
- env: environment, like pr, np, qa
- reg: region, like euw, eun
- comp: component abbreviation, like files, diag
- iro: company abbreviation to reduce conflicts with other customers
- sa: storage account resurce type

• shsvcpreuwfilesirosa Shared_Services Prod EU_West Files
• shsvcpreuwdiagirosa Shared_Services Prod EU_West VM_Diagnistics
• sappreuwbwdatairosa SAP Prod EU_West BW_Data
Recovery Service Vault Resource group <System>-<Env>-<Region>[-Component]-rsv
alphanumerics and hyphens only
• PlatIdty-PRD-EUW-rsv
• SAP-NPR-EUW-BackupLRS-rsv
• SAP-PRD-EUW-BackupGRS-rsv
Key Vault
Key Vault Global <System>-<Env>-<Region>[-Component]-irokv
Like storage accounts, name is up to 24 characters, but you can use hyphens and alphanumerics in both lower and UPPER registers, which helps with reading accessibility.

Might need the same solution as for storage accounts using GUID-like names with using other ways to provide human-friendly identification.

• PlatIdty-PRD-EUW-irokv
• ShSvc-PRD-EUW-Sec1-irokv
• IA-PRD-EUW-Enc-irokv
• SAP-PRD-EUW-01-irokv
In specific cases naming parts can be truncated more to accommodate KV naming restrictions
Key Vault objects Key Vault <Key_Name>-key
for keys
• DefaultDiskEncryption-key

<Secret_Name>-secret
for secrets
• DomainJoinPass-secret
Common and Management resources
Log Analytics workspace Resource group <System>-<Env>-<Region>[-Component]-log

• PlatMgmt-PRD-EUW-Operations-log
• PlatMgmt-PRD-EUW-Security-log
Automation Account Resource group <System>-<Env>-<Region>[-Component]-aa

• PlatMgmt-PRD-EUW-Mgmt-aa
Private Endpoint Resource group <parent_name>[-service]-pe

• shsvcpreuwfilesirosa-file-pe
PaaS services
Azure Cache for Redis Global <system>-<env>-<region>[-component]-iroredis
up to 63 chars, lowercase letters, numbers, and hyphens
• sap-prd-euw-bwcache-iroredis
Azure SQL Database Global <system><env><region>[component]-irosql
up to 63 chars, lowercase letters, numbers, and hyphens
• sap-prd-euw-bwdata-irosql
.. and so on .. … …

Comparison with CAF convention

What happens if CAF convention is followed literally

You probably know this picture? I see it cited all the time, like a bible. The issue with this picture is that it is an example, not a bible. Its intended purpose is to show the important naming parts, not to propose the exact naming convention.

Components of an Azure resource name

This is what happens when customers take this picture literally and turn it into their naming convention:

  • Resource type is used as a prefix
  • Resources on Azure Portal are sorted by resource type by default
  • Parent-child relationships between resources are not visible, however you see mixed resources from different systems and environments together, which may lead to confusion and operating mistakes
[expand to see] the pictures...

naming-caf1 naming-caf2


How the proposed convention looks in real life

  • Names constructed to reflect relations between resources, the resource type is used as a suffix
  • You can easily search resources and see related ‘child’ resources
  • You can still sort by resource type if needed
  • The names that Azure generates automatically (and you cannot change them) look pretty similar

I can’t share screenshots from customers’ environments due to NDA restrictions and will update this post with screenshots from my lab environment when I get it rebuilt. Meanwhile, here is a list of typical resources of a small Landing Zone environment using the suggested naming convention, in YAML format:

[expand to see] sample-landing-zone.yaml... 
PlatCon-PRD-sub: # platform connectivity subscription
  - PlatCon-PRD-EUW-Network-rg:
      - PlatCon-PRD-EUW-Hub-vnet
      - PlatCon-PRD-EUW-Hub-vnet-afw # firewall
      - PlatCon-PRD-EUW-Hub-vnet-afw-pip
      - PlatCon-PRD-EUW-Hub-vnet-afw-Pol_1-afwp
      - PlatCon-PRD-EUW-Hub-vnet-afw-Pol_2-afwp
      - PlatCon-PRD-EUW-Hub-vnet-agw # app gateway
      - PlatCon-PRD-EUW-Hub-vnet-agw-mid
      - PlatCon-PRD-EUW-Hub-vnet-agw-pip
      - PlatCon-PRD-EUW-Hub-vnet-bas # bastion
      - PlatCon-PRD-EUW-Hub-vnet-bas-nsg
      - PlatCon-PRD-EUW-Hub-vnet-bas-pip
      - PlatCon-PRD-EUW-Hub-vnet-N_Diag-nsg # nsg
      - PlatCon-PRD-EUW-Hub-vnet-N_Default-nsg
      - PlatCon-PRD-EUW-Hub-vnet-R_GatewaySubnet-rt # route table
      - PlatCon-PRD-EUW-Hub-vnet-R_Default-rt
      - PlatCon-PRD-EUW-Hub-vnet-vngv # vpn gateway
      - PlatCon-PRD-EUW-Hub-vnet-vngv-IP1-pip
      - PlatCon-PRD-EUW-Hub-vnet-vngv-IP2-pip
      - PlatCon-PRD-EUW-Hub-vnet-vngv-S_Home-lng
      - PlatCon-PRD-EUW-nw # network watcher
      - pconpeuwhubirosa # storage
  - PlatCon-PRD-EUW-NVA-rg:
      - PlatCon-PRD-EUW-NVA-I_CHR_6.46.5-img
      - PlatCon-PRD-EUW-NVA-I_CHR_7.2.1-img
      - PlatCon-PRD-EUW-NVA-N_Ext-asg
      - PlatCon-PRD-EUW-NVA-N_Ext-lbe
      - PlatCon-PRD-EUW-NVA-N_Ext-lbe-pip
      - PlatCon-PRD-EUW-NVA-N_Int-asg
      - PlatCon-PRD-EUW-NVA-N_Int-lbi
      - PlatCon-PRD-EUW-NVA-N_Mgmt-asg
      - PlatCon-PRD-EUW-NVA-nsg
      - PlatCon-PRD-EUW-NVA-ROS-as
      - pconpeuwnvairosa # storage
      - NVAPEUWROS1 #NVA VM1
      - NVAPEUWROS1-D_OS-md
      - NVAPEUWROS1-N_Ext-nic
      - NVAPEUWROS1-N_Int-nic
      - NVAPEUWROS1-N_Mgmt-nic
      - NVAPEUWROS1-N_Mgmt-nic-pip
      - NVAPEUWROS2 #NVA VM2
      - NVAPEUWROS2-D_OS-md
      - NVAPEUWROS2-N_Ext-nic
      - NVAPEUWROS2-N_Int-nic
      - NVAPEUWROS2-N_Mgmt-nic
      - NVAPEUWROS2-N_Mgmt-nic-pip      

PlatMgmt-PRD-sub: # platform management subscription 
  - PlatMgmt-PRD-EUW-Network-rg:
      - PlatMgmt-PRD-EUW-vnet
      - PlatMgmt-PRD-EUW-vnet-nsg
      - PlatMgmt-PRD-EUW-vnet-rt
      - PlatMgmt-PRD-EUW-nw
  - PlatMgmt-PRD-EUW-Ops-rg:
      - PlatMgmt-PRD-EUW-Ops-aa
      - PlatMgmt-PRD-EUW-Ops-log

PlatIdty-PRD-sub: # platform identity subscription
  - PlatIdty-PRD-EUW-Network-rg:
      - PlatIdty-PRD-EUW-vnet
      - PlatIdty-PRD-EUW-vnet-nsg
      - PlatIdty-PRD-EUW-vnet-rt
      - PlatIdty-PRD-EUW-nw
  - PlatIdty-PRD-EUW-ADDC-rg:
      - ADPEUWDC01 #DC VM1
      - ADPEUWDC01-D_OS-md
      - ADPEUWDC01-D_LUN1-md
      - ADPEUWDC01-nic
      - ADPEUWDC02 #DC VM2
      - ADPEUWDC02-D_OS-md
      - ADPEUWDC02-D_LUN1-md
      - ADPEUWDC02-nic
      - PlatIdty-PRD-EUW-ADDC-as # availability set
      - PlatIdty-PRD-EUW-ADDC-nsg
      - pidpeuwdiagirosa # diagnostics storage

SharedSvc-PRD-sub: # shared services subscription
  - SharedSvc-PRD-EUW-Network-rg:
      - SharedSvc-PRD-EUW-AKS-vnet
      - SharedSvc-PRD-EUW-AKS-vnet-Cluster2_Main-nsg
      - SharedSvc-PRD-EUW-AKS-vnet-Cluster2_Virtual-nsg
      - SharedSvc-PRD-EUW-Apps-vnet
      - SharedSvc-PRD-EUW-Apps-vnet-nsg
      - SharedSvc-PRD-EUW-Apps-vnet-rt
      - SharedSvc-PRD-EUW-nw
  - SharedSvc-PRD-EUW-AKS_Cluster1-rg: []
  - SharedSvc-PRD-EUW-AKS_Cluster2-rg: []
  - SharedSvc-PRD-EUW-App1_FE-rg: []
  - SharedSvc-PRD-EUW-App1_BE-rg: []

Change my mind

The cover picture in this post is not a complete joke. Even though I’ve been using and refining this convention for so many years and customers, I’m eager to hear your opinion and change my mind if you propose justified improvements.

I have not decided on the exact comment implementation for this blog yet, so in the meantime, you are very welcome to discuss this topic in LinkedIn comments.