In my previous blog article, I touched already slightly on this topic, the need to have a naming convention for the different Azure Resources. Probably not the fanciest topic to write about, and often underestimated its importance. Maybe there is reason why it’s worth spending some time on it? Defining some naming patterns before you deploy resources in Azure (or any cloud) is vital because…
- … it can be difficult (or not possible without delete and re-create) to change a name later;
- … management and troubleshooting can become easier;
- … names must meet the requirements of the specific resource type.
Unfortunately, most of the concepts used today are optimized for an on-premises world only and aren’t easily extensible nor adaptable to the public cloud. Luckily Microsoft has released a great article on naming convention which provides excellent insights and works perfectly fine as a starting point.
If you can’t say something nice, say it in French.
― Anonymous
Most Common Resources to name
Each resource or service type in Azure enforces a set of naming restrictions and scope. Any naming convention or pattern must adhere to the requisite naming rules and scope.
An extended copy of this table has been added below – you probably notice immediately the different rules applied to the resources or entity:
| Resource or Entity | Length | Casing | Valid Characters |
| Subscription | Case insensitive | Alphanumeric, hyphens, parentheses and underscores | |
| Resource Group | 1-64 | Case insensitive | Alphanumeric, hyphens, parentheses, periods and underscores |
| Availability Set | 1-80 | Case insensitive | Alphanumeric, hyphens and underscores |
| Virtual Machine | 1-15 (Windows) 1-64 (Linux) | Case insensitive | Alphanumeric, hyphens and underscores |
| Storage Account name | 3-24 | Lower case | Alphanumeric |
| Container name | 3-63 | Lower case | Alphanumeric and hyphens |
| Blob name | 1-1024 | Case sensitive | Alphanumeric and hyphens |
| Queue name | 3-63 | Lower case | Alphanumeric and hyphens |
| Recovery Services Vault | 2-50 | Case-insensitive | Alphanumeric and hyphens |
| Virtual Network (VNet) | 2-64 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Subnet | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Network Interface | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Network Security Group | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Network Security Rules | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Public IP Address | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Load Balancer | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| VNet Peering | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Azure Application Gateway | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| Traffic Manager Profile | 1-63 | Case-insensitive | Alphanumeric, hyphens and periods |
| Network Virtual Appliance | 1-63 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
| ExpressRoute Circuit | 1-80 | Case-insensitive | Alphanumeric, hyphens, periods and underscores |
The usage of Special Characters
Besides length and “cASinG”, the use of special characters can be very confusing. A good rule of thumb, avoid having any special characters as the first or last character in any name. These characters will cause most validation rules to fail.
Also, understand which !exact! characters are and are not available for which resource:
| Characters | Value |
| Alphanumeric, letters and numbers | abc…xyz 123…890 |
| Hyphen | – |
| Period | . |
| Underscore | _ |
| Parentheses | ( ) |
Some documentation mention “dash” instead of “hyphen”. Probably just a confusion of names for those special characters, but still something to pay attention on:
There’s just one more thing…
While a name of a virtual machine object could be up to 64 characters, there is a limitation of 15 characters for virtual machines using Windows. Some background on this – a virtual machine resource has two distinct names: a name for the virtual machine, the Azure resource, and a name for the computer, the name used in the operating system. When you deploy machine from the Azure Portal, the same name will be used for both objects.
So where is the limitation of 15 characters limits coming from? This restriction is entirely due to NetBIOS. Yes, I said NetBIOS – that old NetBIOS. As some components still rely on those components, we are bound to the limitation of the computer name, 15 characters.
After reading this great article of yours and taking into account the other side of the coin explained in , my team and I ended up exactly with this nice dilemma of wandering if a naming convention is really needed. We are stuck in hey! There’s no abbrev for hostpool, let’s use hp. Or, hey! Do we really need to include a region affix? So different approches like the one at or the one slightly different at seems to support the idea that tagging is more relevant than naming.