InnerWorks Logo
Return to main siteReturn to main site
Blogs

Azure Resource Naming Tips 2022

Azure Resource Naming Tips 2022

Cogworks

20 Oct 2021 • 6 min read

HowToEnsure-your-azure-portal-resourcesareWELLNAMED

Hello, youve stumbled into the old Cogblog archives

We've switched our blogging focus to our new Innerworks content, where tech community members can share inspiring stories, content, and top tips. Because of this, old Cogworks blogs will soon be deleted from the site, so enjoy it while you can. A few of these might refer to images in the text, but those have been deleted already sorry. Some of these subjects will return, some aren't relevant anymore, and some just don't fit the unbiased community initiative of Innerworks.

If you'd like to take on this subject yourself please submit a new blog!

Farewell Cogworks Blog 💚

"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 group 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 are 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 a 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 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 Azure 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.

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.

Community tech aid

Innerworks and Cogworks are proud to partner with Community TechAid who aim to enable sustainable access to technology and skills needed to ensure digital inclusion for all. Any support you can give is hugely appreciated.