In my experience most IT people believe that a naming convention is needed everywhere to ensure a consistent structure in resource names.

One of the root causes of this, I believe, is the NetBIOS protocol (1983) which limits a computer name to 15 characters and does not provide a built-in way to associate metadata to a name.

Computer/server names

Having been limited to only 15 characters for all information for decades has spawned numerous attempts by IT people to cram as much information into those 15 characters has possible.

Common needs include:

  • Short company name or prefix (s, ms, etc.)
  • Prefix denoting server or client (cl, pc, s, svr etc.)
  • Placement in data center or rack or VM host (dk1, nl2, etc.)
  • Primary use (db, sql, web, host, mail)
  • Numeric serial 3-6 numbers, possibly with 0-padding (000123, 456)
  • Environment (prod/test/dev) (p, t, tst, prod)
  • Liberal use of dashes

From the list above here are some possible combinations:

  • mssvrmail01
  • s-sql-01-dk1
  • svr-dk1-host-42
  • svrnl2mail12
  • ms-pc-000123
  • dk1-web-452
  • prodweb01-dk1

Except maybe for the primary use of a server, none of these elements provide any value what so ever for the users of a system.

If you need to access a server directly (hopefully very rare), you need to know the full name anyway, and at that point you probably also know what the server does.

If a server is moved to another host or data center, would we then have to change it’s name?

Based on this I would recommend the following (very simple) naming convention for clients and servers:

Server + serial number, e.g. server1, server2, …, server42.

Naming will be unique across the entire organization and names are super easy to remember and relay over a phone.

Azure naming conventions

In Microsoft Azure there are numerous naming rules for example:

Primary source:

Resource type Scope Naming rules Length Examples
Resource group Subscription ^[-\w\._\(\)]+$ 1-90  
Tag Associated Entity ^[^<>%&\\\?/]+$ 1-512 (key), 1-256 (value) { "owner": "" }
Virtual machine Resource group Alphanumeric and hyphen 1-15 (Windows), 1-64 (Linux) server42
Web app Global Alphanumeric and hyphen 1-60
Storage account Global Alphanumeric 3-24
Container Registry Global Alphanumeric 5-50  
Service Bus Namespace Global Alphanumeric and hyphen (must start with a letter) 6-50  

Resources with a global scope will result in public endpoints, these should always be lowercase.


Businesses will very often try to create a global naming convention, i.e. one which should be applied on all resources. This will often if not always result in a lowest common denominator approach like:

  • 1-15 characters
  • alphanumeric (must start with a letter)
  • lowercase only
  • globally unique

I addition name must include information about:

  • Company name (shortened)
  • Resource type
  • Environment type
  • Region (data center)
  • Product/service/solution name
  • Serial number

This results in names like:

  • drgr001dimension
  • rg001dimension
  • web001dimension
  • sqlsharepoint002

Consequences of naming conventions for resources

Naming with lowest common denominator with required parts will

  • Severely limit the ability for DevOps engineers to use names which make sense to them and/or their team.
  • Introduce unnecessary readability issues – all lowercase compound words are much harder to read than camelCase, pascalCase or hyphened-words.
  • Add redundant information – we already know what a resource is.
  • Confuse people: What’s the standard? How do I apply it? Why? I can’t read that??!?!

Also, resources auto-generated by Azure like managed disks ([VM name]_OsDisk_1_25fbb34c5b074882bcd1179ee8b87eeb) or supporting resource group for Azure Kubernetes Service (MC__[Resource group name]) will not follow the naming conventions.

The maintenance/abbreviation nightmare

As mentioned above a naming convention will undoubtedly contain a number of prefix/suffix abbreviations which will have to be both understood and maintained.

In many cases a fixed length has also been enforced as a requirement. This makes matters a lot worse as common abbreviations for certain resources are two letters while others are three or maybe four. What do we do with the white-space? Or how do we shorten an already established abbreviation.

Have a look at the following table:

Name Two-letter Three-letter Longer
East US 2     eastus2
West Europe we weu  
North Europe ne neu  
Denmark dk dnk  
Virtual Machine vm    
Virtual Network     vnet
Network Interface   nic  
IP Address ip    
Database db    
SQL Server   sql  
MySQL Server     mysql
PostgreSQL Server     postgres
Web App ` web  
PowerShell   ps1  
Resource Group rg rgr  
Service Bus sb bus  
Firewall fw    
Application Gateway gw/lb waf  

Now come up with two-letter and/or three-letter meaningful and (preferably) unambiguous abbreviations for the following Azure resources (very incomplete list):

  • Logic App
  • Function App
  • Cosmos DB
  • IOT Hub
  • Notification Hub
  • Event Hub
  • Event Grid
  • Application Insights
  • Stream Analytics Job
  • Databricks
  • HDInsight
  • Blockchain Service
  • DevOps Project
  • Storage Account
  • Data Lake Storage
  • Search
  • Front Door
  • Container Registry

And when your done do the same for 3rd party Azure resources (very incomplete list):

  • Bitnami Elastic Search
  • Bitnami Kafka
  • Bitnami LAMP
  • Barracuda WAF
  • Apache Solr
  • Chef Automate
  • Moodle
  • Sitecore

Maintenance/abbreviation conclusion

This will never scale. It is impossible to come up with meaningful abbreviations for just a subset of the resources above, let alone scaling to more resources as they become used/needed in Azure.

Debunking naming conventions


Resource groups can only be viewed under resource groups or in a table with an explicit “Resource group” header


No need for suffix/prefix for name like “rgr-” or “-rg”.


Resources with a public endpoint already have an FQDN which accurately describes what they are.


Resource type Public endpoint
App Service (web/logic/function app)
Traffic manager
Storage account
Azure SQL
Public IP (load balancer, VM, App Gateway etc.)
Cosmos DB
Service Bus


No need for suffix/prefix for type like “web-” or “-db”.


Resource Groups

The screenshot below shows a list of resource groups in an Azure subscription. The table shows by default the resource type icon, name, subscription, and location of the resource group. Note that resource groups can be filtered on:

  • Name
  • Location
  • Subscription
  • Tags

Azure Portal Resource Groups View Azure Portal Resource Groups View

Resource Group Conclusion

Adding confusion naming pre- or suffixes to a name will not in any way make a resource group easier to find.


The screenshot below shows a list of resources in an Azure subscription. The table shows by default the resource type icon, name, type, resource group, location, and subscription of the resource. Note that resources can be filtered on:

  • Name
  • Subscription
  • Resource group
  • Type
  • Location
  • Tags

Azure Portal Resources View Azure Portal Resources View

Resources Conclusion

Adding confusion naming pre- or suffixes to a name will not in any way make a resource easier to find.

Why a naming convention slows you down

While having a naming convention on a small team where everyone’s on board might work for you, having a company-wide naming convention will only confuse and irritate people. In my experience I have never seen a naming convention which has satisfied anyone but the three people who came up with it. Everyone else wants to change it so support their specific view of the world. Given that most people aren’t around forever it’s quite possible that the naming convention will be an invention of somebody who is no longer with the company.


You need a way to document the naming convention which ensures people see it and follow it - and keep up to date with changes. This requires a lot of work.


If you - as most organizations do - land on a naming conventions fix pre- and suffixes for resource types, you will have to update this whenever there are new resource types being made available - and given the pace at which Microsoft adds features to Azure, this will at minimum be several times a year.

Talking, talking, talking

The worst part about having a naming convention is that no matter how many times you say it, people will think it’s up for debate. Chances are that only the few people who decided on the naming convention will appreciate it (and maybe not even them(!)) - the rest of the organization will most likely hate it and try to fight it or at least bicker about it whenever possible. This is a complete waste of everybody’s time.


When should a naming convention be verified/enforced? A number of options presents themselves:

  1. On create
  2. Scheduled checks
  3. Never (trust)

Ad 1: Requires custom software which can create any type of resource. No users can be allowed to create Azure resources through either the Portal, PowerShell or CLI.

This is clearly not ideal for a number of reasons:

  • Severely limits peoples ability to create new Azure resources
  • Huge development/maintenance task in creating yet another unnecessary custom tool

Ad 2: Requires custom software which can scan all Azure subscriptions and check for naming convention mismatches. This is maybe more appealing than (1) as Azure Automation can be used with a PowerShell script, however we would once again take upon us a development/maintenance task.

Ad 3: Requires nothing except we would have to educate/inform the developers.

This is not ideal either as we would have to spend a lot of time with each developer before giving them access to actually deploy stuff to Azure.

Verification/Enforcement summary

To make matters worse for any kind of enforcement/verification to work one would probably need a combination of all 3 above, i.e. limit creation to using specific tools with naming convention checks, Azure Automation scheduled verification, and training developers in naming before letting them loose.

Verification/Enforcement conclusion

All in all it does not seem feasible or worth it to even try to verify/enforce any kind of naming policy, which makes the whole premise of having one void.

Why not having a naming convention will speed you up

When individual teams are given the freedom to pick names they will not have to consult anyone to get started. With no naming convention there will also not be a naming convention which has changed, resulting in no need to retroactively change names which is mostly not possible in Azure (a resource must be deleted and recreated with the new name).

Finding a resource

Finding a resource by name – and thus determining its type, location, and resource group is very easy using either PowerShell:

Get-AzResource -Name <name> | Format-Table

or the Azure CLI:

az resource list --name <name> --output table

Having shorter meaningful names will also make running these commands a lot faster.


The solution to the naming convention problem has to be the tagging feature in Azure. All resources including resource groups can have a set of tags (key/value pairs) which contain required metadata information.

Naming vs. Tagging

Azure allows adding tags to all resources with the following limitations:

  • At most 15 tags
  • Tag name (key): 1-512 characters
  • Tag value: 1-256 characters

Tags can be enforced on all resources using Azure Policy.

Tags can be used to filter/search/group resources both in the portal and in billing.

This allows to put all information which cannot be contained in a name into tags.

Required (optional?) tags

We suggest that all naming convention information is moved to tags:

Tag Example
Environment Production / Test / Development
Cost center 123456
Product Company Web Site


To conclude I truly believe that no naming convention should be required on any Azure resources except for the ones simple restrictions already enforced by Microsoft.

Here’s my suggested naming convention: Use meaningful names!

Only other limitation which should be blatantly obvious: No profanity or humor.

Instead a very limited set of tags should be enforced using Azure Policy.