Azure Naming Guidelines

 

 

"If you cannot name something then you have not understood its purpose" - Enkat Subramin

We have been working with Azure from its very inception and have seen many client Azure subscriptions. We have seen a lot of interesting attempts at naming Azure resources/services.

The main Azure resource list is typically a big mess of everything in your subscription. Everything is listed in alphabetical order, and it is typically hard to find what you are looking for.

 

What Clients Tend To Do

Clients typically go with TitleCase because that's what they are used to when dealing with Microsoft technologies. There's also people who go with camelCase. The problem is that Azure has internal inconsistencies. For example, Azure only allows lowercase for some resources.

There is another quirk with Azure naming where hyphens are allowed in most cases, but not in some (eg. storage account naming). Some clients have opted to just never use hyphens at all. The problem with this is that longresourcenamesarehardtoread.

Azure also auto-generates some naming. For example TitleCase, name-with-hyphens, lowercasenohyphens. It's a mess!

Add to this, the slight problem that many Azure names need to be globally unique within Azure’s entire infrastructure. So you can’t have a storage account called “cnn”, as that’s already taken!

 

Our Azure Naming Recommendations 

We have had many heated discussions about Azure naming since its very inception. We believe that balanced naming convention is the answer. 

Firstly, we have a few rules:

  • Use lowercase
  • Use hyphens where permitted
  • Prefix resources with the resource type
  • Suffix resource group/container/folder names (more info below)

 

Globally Unique Azure Naming

Azure requires some services to be public and globally unique. These look a bit complicated, but once you see the examples we hope it will all make sense. 

Our naming convention concepts:

  • Resource / service common name
    • Resource : Things such as App Services, Database Servers, Storage accounts. Where there is no "typical" abbreviation or documented convention, we make our own suggestions. For example, App Service can be abbreviated to app
    • Service Common Name: Items with generally accepted abbreviations. For example, Virtual Network is typically abbreviated to vnet in Azure documentation, where as Virtual Machine is typically abbreviated to VM.
  • Project 
    • Project: Typically used for internal projects. For example, you may have a project with a code such as COG0123.
    • Client "Projects" can be similarly named. For example, MSN0123
  • Environment / Label
    • Environment: Most companies and agencies have dev and staging environments
    • Label can be a branch name, or a release version
  • Container / Folder / Group
    • Resource Group is an example of a container/folder/group
    • App Service Plan is an example a container/folder/group

 

Our naming conventions are as follows... 

General Services
<resource/service common name>-<project>-<environment/label>-<organisation>

Groups/Containers
<resource/service common name>-<project/client>-<environment/label>-<organisation>-<container/folder/group>

  

App Services - Example

app-<project>-<environment>-<organisation>.azurewebsites.net 

Note: There is a 40 character limit for App Service Plan names.

Parameters

  • project: internal-0123
  • label: v1-2-3
  • organisation: good-names

As you can see the App Service, and the App Service Plan appear adjacent in the resource list.

 

App Service Name
app-internal-0123-v1-2-3-good-names

App Service Plan
app-internal-0123-v1-2-3-good-names-asp

Resource Group
app-internal-0123-v1-2-3-good-names-rg

Public URL
app-internal-0123-v1-2-3-good-names​.azurewebsites.net

 

Database Servers - Example

Example

<db type>-<environment><-pool<number>><organisation>.database.windows.net

Parameters

  • db type: sql
  • pool & number: pool01
  • organisation: good-names

As you can see, the pool and database server appear adjacent in the resource list.

 

SQL Server Name
sql-dev-good-names 

Elastic SQL Pool
sql-dev-pool01-good-names

Resource Group
sql-dev-good-names-rg

Public URL
sql-dev-good-names.database.windows.net

 

Databases - Example

db-<project>_<purpose>_<environment>

Example 1

Parameters

  • project: internal
  • purpose: umbraco
  • environment: staging

 

Database Name
db-internal-0123_umbraco_staging

 

Example 2

Parameters

  • project: internal
  • purpose: custom-data
  • environment: v5-1-0

 

Database Name
db-internal_custom-data_v5-1-0

 

 

Storage Accounts - Example

Unfortunately Azure storage accounts only allow lowercase with no hyphens. Just close your eyes to this :(

storage<purpose(optional)><organisation>

 

Example

Parameters

  • purpose: public (publically accessible)
  • organisation: goodnames

 

Storage Account Name
storagepublicgoodnames

Resource Group
storagepublicgoodnames-rg 

Public URL
storagepublicgoodnames.core.windows.net

 

 

Internal Infrastructure

These following services do NOT require globally unique Azure naming per se. So we have a slightly different approach. However the concepts are very similar.

Unfortunately Windows VMs have a character limit, so we recommend to abbreviate the organisation name for all internal resources

We generally use: <service>-<organisation>-<descriptor><number>

 

Virtual Machines - Example

vm-<organisation>-<os><number>

 

Example 1

Parameters

  • organisation: gn
  • os: win (Windows)
  • number: 01

As you can see, Azure automatically creates a disk, network interface, public IP, network security group, and a vnet. Prefixing the name with "vm" allows all VMs to be ordered in the resource list.

 

VM Name
vm-gn-win01

Resource Group
vm-gn-win01-rg

DNS
vm-gn-win01-<autogenerated number>.westeurope.cloudapp.azure.com

 

Example 2

Parameters

  • organisation: gn
  • os: ubn (Ubuntu)
  • number: 01

 

VM Name
vm-gn-ubn01

Resource Group
vm-gn-ubn01-rg

 

Virtual Networks - Example

For stand-alone networks, NOT directly associated with Virtual Gateways. 

vnet-<organisation>-<environment><number>

 

Example

Parameters

  • organisation: gn
  • environment: vnet
  • number: 01

 

VNet Name
vnet-gn-vnet01

Resource Group
vnet-gn-vnet01-rg

 

 

Virtual Network Gateways - Example

vnetg-<organisation>-<environment><number>

 

Example 

Parameters

  • organisation: gn
  • environment: vnet
  • number: 01​

 

VNetGateway Name
vnetg-gn-vnetg01 

Public IP
vnetg-gn-vnetg01-publicip

Resource Group
vnet-gn-vnet01-rg

Note: VNet Gateways in Azure require that the Vnet and VnetGateway exist in the same resource group. Since you must create the VNet first, then the VNet Gateway would be added to the VNet's resource group. So as you see the Resource group in this case is actually the resource group of the VNet, and not the VNet Gateway.

 

To Sum it all up

As you hopefully can see, these guidelines can allow you to more effectively see and find your resources. The purpose of these naming guidelines is to group your resources together as much as possible. 

Azure will still try to automatically create various resources. For example, Disks will still be named poorly. However, if you are serious about getting your house in order, then you will get a lot more granular control if you use the Azure API via Powershell. We'll cover that in a future blog post.

Another thing to note is character limits. Some items such as App Service Plans have a 40 character limit. In our experience, it's best to keep everything to 40 characters in general, unless you are dealing with Windows Virtual Machines which limit you to 12 characters.

We hope you found this article useful.

 

Article by Anthony Dang (@anthonydotnet)