Before you can tag your subscriptions, resources and groups, you need to name them. The same principles of consistency and scalability that apply to tags should also apply to your naming convention. Microsoft has some solid guidelines in place for naming Azure resources, but there are a lot of restrictions and requirements worth familiarizing yourself with before you get started. This article will provide a quick overview of the main things to keep in mind.
Why should I spend time developing a naming convention? Does it really matter?
How you name your Azure subscriptions, storage volumes, virtual machines and other resources isn’t something to make up on the spot as you go along. (And as bland as bos-sql-04 might be, keep in mind that resource names should be designed for function and universality, not self-expression. Save the obscure pop culture references for your CNAMEs if you really can't resist.)
Among other benefits, having a consistent, documented naming convention:
Makes it easy to locate resources and understand their role at a glance
Prevents your environments from devolving into a cluttered mess of inconsistently named assets
Ensures that everyone names the resources they create according to the same logical pattern, making it easier to collaborate across departments and teams
Naming your Azure subscriptions
Microsoft suggests using the following pattern for naming subscriptions:
<Company> <Department (optional)> <Product Line (optional)> <Environment>
This is a good option for most use cases. Some quick considerations:
Decide on the order of each component in the pattern. Putting the department before the company name or vice versa will have an impact on filtering.
The Company component may be the same for all subscriptions, but if your business is set up as a series of child companies under a single parent company, you can use the first part of your subscription names to distinguish between them.
Keep things short: a good rule of thumb is to pick a two-letter abbreviation to refer to your company (or companies), a two-letter abbreviation for each department and product line, and a single-letter abbreviation for each environment.
Naming your Azure resources
Start by making a list of standard abbreviations for the different types of resources and services you’re working with. This will come in handy for monitoring purposes. Keep your abbreviations as short as possible, for example:
vmfor virtual machines
rgfor resource groups
It's a good idea to specify the location of each resource with a shortcode (e.g.
euw for western Europe,
cus for central US). To build your list of location codes for your naming convention, refer to the list of Azure datacenter regions and define a two- or three-letter code for each relevant location.
Because the requirements for names vary a lot between resource types (and between cloud providers, if you're working in a multi-cloud environment), it's always a good idea to stick to the lowest common denominator so your system stays as universally applicable as possible. If you’re using numbers to identify sequences/resource counts, specify exactly how to format them (i.e. should you use
01?). Most importantly, write everything down!
Keep in mind:
You can’t rename a resource in Azure without deleting it and then recreating it with the new name.
Different resource types have different naming restrictions. View the full list of Azure naming specifications here.
Some resource names have to be globally unique across all of Azure (because they live as a DNS record on Microsoft namespace)
Some resource types can have capital letters in their name, but all of them support lowercase. We suggest sticking to all lowercase.
Use hyphens when permitted; it makes labels easier to parse at a glance.
Enforcing your Azure naming convention
Now that you've put all this thought into your naming convention, it'd be a shame if it got shelved six months from now because no one ended up following it. One way to make sure everyone plays ball is to set up an Azure Policy that enforces your naming rules each time someone creates a new resource.
An easy way to do this is to tweak the Enforce like pattern for naming conventions policy template to your liking, then deploy it via the Azure Portal, Azure CLI, or PowerShell.
Naming convention + tags = an organized, scalable Azure environment
Your naming convention is a great foundation for keeping your Azure resources and subscriptions in order, but, as you can see from the above limitations and particularities, it's fairly inflexible on its own.
That's why we strongly recommend taking the time to build a comprehensive tagging strategy to complement your naming rules. Together, your naming convention and tagging system will give you maximal visibility over your resources, allowing you to understand what's going on in your environment at a glance and enabling you to quickly retrieve information on ownership, location, usage and costs.
Did you run into any roadblocks or challenges when designing your Azure naming convention? Tell us about it in the comments, or tweet us @sharegatetools.