This blogpost is part of a series of Azure Virtual Datacenter Concept blog posts.
Let’s talk about one of the key pilars from the Azure Governance scaffold: naming conventions
Understanding which resource, what is does and where it is located
Naming standards and conventions have been around for decades.
They are commonly used to identify objects and are used in most industries.
Let’s take car manufacturer BMW as an example, their cars are named with certain key characteristics in mind.
BMW 118D Hatch
Brand = BMW
Motorization = 1800 CC
Fuel Type = Diesel
Bodywork = Hatch (5 doors)
Pretty simple example on how a well defined naming standard can immediately give you the necessary info about a certain object. In essence, that’s why naming conventions are used.
Azure Naming conventions
As with regular industry naming conventions, standardizing the way you define your Azure Resources is crucial.
Microsoft has a predefined set of “policies” that need to be met with regards to naming your resources, the following docs article gives you an overview on how naming standards can be applied.
Below you can find a couple of commonly used resources that need to be uniquely identified globally across Microsoft Azure.
! We will need some kind of generalization to keep our resources unique
| Entity | Scope |
| API management | Global |
| Key vault | Global |
| Function app | Global |
| Web app | Global |
| Storage account name (data) | Global |
| Storage account name (disks) | Global |
| Data Lake Storage | Global |
| Container registry | Global |
| Service Bus namespace | Global |
| Event Hubs namespace | Global |
| Log Analytics Workspace | Global |
Taking the above information into account, we’ve generated a set of scripts that allow you to easily define a naming policy.
Input variables
To start building our naming conventions we first need a couple of input variables that are unique to our setup.
##################################################################################### # # This script provides you with an overview of all naming conventions that are being used in the Virtual Datacenter Concept # Version: 0.1 # Author: Yannick Dils # ##################################################################################### ##################################################################################### # # Below is a set of variables that is being used in order to populate the naming conventions # ##################################################################################### # Variable abbreviation for the resource group that will be used for central shared services $RG_PurposeHUB = "hub" # Variable abbreviation for the resource group that will be used for production workloads $RG_PurposePRD = "prd" # Variable abbreviation for the resource group that will be used for acceptance workloads $RG_PurposeACC = "acc" # Variable abbreviation for the resource group that will be used for test workloads $RG_PurposeTST = "tst" # Variable abbreviation for the resource group that will be used for development workloads $RG_PurposeDEV = "dev" # Variable abbreviation for the customer / environment $Cus = "<proj>" # Variable abbreviation for the resource location $Location = "weu" # Variable which provides the desired resource location $FullLocation = "WestEurope" # Variable abbreviation for the resource owner $owner = "YD" # Variable abbreviation for the environment tier # 1 : HUB + PRD # 2 : HUB + PRD + ACC # 3 : HUB + PRD + ACC + TST # 4 : HUB + PRD + ACC + TST + DEV $EnvironmentTier = "4" # Variable required for resource generalization $Guid = [guid]::NewGuid() $MyGUID = $Guid.Guid.Remove(8) ##################################################################################### #####################################################################################
Resource Groups
Resource group naming conventions are provided as per below. A resource group should be able to clearly define the customer or project, the type of environment and the purpose of the resources that are being created in the resource group.
| Customer or project (3 letter abbreviation) | – | Tier (3 letter abbreviation of the Tier, HUB; PRD, TST, ACC, DEV) | Purpose (Resource Group Purpose Abbreviation) | – | Resource Purpose | |
| <proj> | – | hub | – | identity | – | rg |
Powershell script
$HUBRGID = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-rg'
Networking
Networking related naming conventions are provided as per below. In order to be able to perform smart discovery over your networking resources, Virtual Networks (VLANs), Subnets, Network Security Groups are named according to the endpoints and services that are located in the specified network topology.
Virtual Networks
| Customer or project (3 letter abbreviation) | – | Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV) | – | Location (3 letter abbreviation of the location) | – | Resource Purpose |
| <proj> | – | hub | – | weu | – | vn |
Powershell script
$virtualnetworkHUBname = $Cus + '-' + $RG_PurposeHUB + '-' + $Location + '-vn'
Subnets
| Customer or project (3 letter abbreviation) | – | Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV) | – | Subnet purpose | – | Resource Purpose |
| <proj> | – | hub | – | identity | – | sn |
Powershell script
$hubsubnetname1identity = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-sn'
Network Security Groups
| Customer or project (3 letter abbreviation) | – | Tier (3 letter abbreviation of the Tier, PRD, TST, ACC, DEV) | – | Subnet purpose | – | Resource Purpose |
| <proj> | – | hub | – | identity | – | nsg |
Powershell script
$hubnsgid = $Cus + '-' + $RG_PurposeHUB + '-' + 'identity' + '-' +'nsg'
Public IP addresses
| Public IP usage | – | Public IP abbreviation |
| resourcename | – | pip |
Powershell script
$vmpip = $VirtMachName + '-pip'
Load Balancing
Azure provides several cloud native load balancing solutions, as with other Azure Resources, they require a logical naming convention.
Internal Load Balancer
| Internal Load Balancer | – | Purpose |
| ilb | – | adfs |
| ilb | – | sql |
Powershell script
$adfsintlb = 'ilb-' + 'adfs'
External Load Balancer
| External Load Balancer | – | Purpose |
| elb | – | adfswap |
| elb | – | rdgw |
Powershell script
$adfsextlb = 'elb-' + 'adfswap'
General Compute Resources
Compute resources contain virtual machines, availability sets, storage and everything related to the infrastructure you need to run your apps.
Storage Accounts
| Storage Account | Redundancy level | Customer Abbreviation | Location | Tier | Purpose |
| st | lrs | <proj> | weu | prd | logs |
Powershell script
$SA_Logs = 'stlrs' + $Cus + $location + $RG_PurposeHUB + 'logs'
Availability Sets
| Customer Abbreviation | – | Tier | – | Purpose | – | Resource Purpose |
| <proj> | – | hub | – | sql | – | as |
Powershell script
#$hubavsql = $Cus + '-' + $RG_PurposeHUB + '-' + 'sql' + '-' + 'as'
Virtual Machines
| Customer Abbreviation | Location | Optional Tier | Purpose | ## |
| <proj> | weu | prd | sql | 01 |
Powershell script
$VMShortName = "sql01" $VirtMachName = $Cus.ToLower() + $location.ToLower() + $RG_PurposePRD + $VMShortName
Virtual Machine Disks
| Virtual Machine Name | – | Disk drive letter |
| <vmname> | – | c |
| <vmname> | – | e |
Powershell script
$OSDiskName = $VirtMachName + '-c'
Summary
In this blogpost, we’ve provided some guidance with regards to naming conventions and standards. The powershell “script” provided can be used for your convenience. In the upcoming series of posts we will be re-using these variables in order to build our Virtual Datacenter Concept topology.
Checkout our previous blogpost to recap on the Virtual Datacenter Concept.
What’s next?
The following aspects of the virtual datacenter concept will be highlighted in the following upcoming posts:
- Virtual Datacenter Concept – 2 of 10 – Governance
- Virtual Datacenter Concept – 3 of 10 – Resource Groups
- Virtual Datacenter Concept – 4 of 10 – Virtual Networking
- Virtual Datacenter Concept – 5 of 10 – Cloud Storage
- Virtual Datacenter Concept – 6 of 10 – Identity Options
- Virtual Datacenter Concept – 7 of 10 – Log Analytics
- Virtual Datacenter Concept – 8 of 10 – Security
- Virtual Datacenter Concept – 9 of 10 – Business Continuity
- Virtual Datacenter Concept – 10 of 10 – Automation