During a recent project, I was caught out by a lack of consistency in naming for Azure resources (and an inability to rename some of them afterwards). Some resources had underscores in their names (_), some had hyphens (-) – and then there were the inconsistencies in case. For someone who generally pays attention to details like this, I found it all very frustrating.
So I started to look into what a standard for naming Azure resources might look like (I also asked Microsoft for advice). The general advice I received was, “stick to numbers and letters – no special characters because some resources won’t accept them”. Then, whilst naming a subnet and starting with a number I found that subnet names can’t start with a number or a space.
So, lets make that “use letters and numbers only, in lower case, and always starting with a letter”.
Now, consider uniqueness – some resources have an associated DNS name (e.g. *.cloudapp.net) that needs to be available for use.
I generally advise against including organisation names in resources like server names (because resources often outlive organisation names) but, in this case, the organisation name is likely to provide some uniqueness. So, let’s try “use letters and numbers only, in lower case, prefixed with an abbreviation for the organisation name, starting with a letter”.
Then, lets think about the naming for the resources themselves – a two letter code for the resource type (rr) and a suitable number of digits to count the instances (nn) – something like:
orgrrnn
This has two characters for the digits on the end, though three, or even four, may be better depending on the size of the organisation (remember to plan for growth!). You’ll also need to consider the total length of the name – between 3 and 15 characters appears to be the sweet spot (some may be longer, few may be shorter).
Resource types might be:
| Two-letter code | Meaning |
|---|---|
| ad | Active Directory |
| cs | Cloud Service |
| db | Database |
| gw | Gateway |
| ln | Local Network |
| ms | Media Service |
| rg | Resource Group |
| sg | Storage Account |
| sp | App Service Plan |
| sn | Subnet |
| tm | Traffic Manager |
| vm | Virtual Machine |
| vn | Virtual Network |
| wa | Web App (App Service) |
For my recent batch of resources when I was studying for an exam, that led to names like:
- exam70534ms01 (Media Service 01)
- exam70534db02 (Database 02)
(illustrated here for both ASM and ARM)
That looks to me to be unique, consistent and meaningful, but I’m sure there are other considerations too! Indeed the Azure documentation has some quite complex recommended naming conventions for Azure resources. My concerns with these are that they are not consistent (remember that not all resources can include certain characters), whereas the naming approach I’ve outlined in this post is.
I had some interesting feedback on this topic in an internal discussion at work, including an important point I forgot to make in the above – we need to be treating resources like cattle and not pets. For those who aren’t familiar with the cattle not pets analogy, this might help: http://www.lauradhamilton.com/servers-pets-versus-cattle – and it gets more important as the estate gets larger. It’s not new either – for years many organisations have just named workstations by asset tag.
In Azure, it’s the “making sure no one else is using your nomenclature” that trips you up – go to register a DNS name that’s already taken and your carefully crafted automation will fail. Certainly a lot of thought needed – there is an argument that the proposal above gives too much away about the purpose of each resource.
Maybe we should just use a unique identifier (in lower case alphabetical characters) and some digits – for example mw000823.