Organisations use naming conventions to make it easier and more efficient to work with governance and security. As organisations started to adopt cloud many kept on using the same convention without adapting it. This created issues since those naming conventions, which were designed to be used for on-premise systems, didn’t support new types of resources that are created in cloud environments such as Azure. This article provides a walkthrough of the basic concepts and recommendations related to creating one for Microsoft Azure. A detailed example of a “Naming Convention Guideline” for Azure is also provided to newsletter subscribers.

Naming Conventions and Cloud Services

Naming conventions have been used by IT departments for a long time. Initially, many conventions were based on science-fiction, fantasy or similar themes. This gradually changed over the years as datacenter principles for standardization, scalability, and automatization were adopted. Instead, more generic names came into use that made it easier to see which workload was running on a server, to add new servers, to analyse logs, etc.

When the same convention was used for the new cloud environments the result was that the same types of resources were given very different names depending on who named them. The consequence of this was that many cloud environments lacked structure and weren’t very orderly. The issues being exacerbated by how easy it is to create cloud resources. It was difficult to understand what each asset was used for, who was accessing it, or even if a asset was actually in use. This in turn made it difficult to work with governance and security since the primary goal is to establish and maintain control. Besides the issue with not following Microsoft’s best practises and recommendations, another consequence was that it also leads to increased costs.

Naming Recommendations for Azure Resources

This article is based on the concepts and recommendations related to creating naming conventions for Azure resources specifically. Creating one for use in AWS and GCP will be different, in part because those Cloud Service Providers have their own recommendations, but mainly due to how cloud services and architectures differ between providers. I’ve created a detailed example of what a Naming Convention Guideline looks like (see screenshot below). Organizations use guidelines such as this to better enforce structure, control, and security in their Azure environment.

Subscribe to our newsletter here and you’ll receive access to the Naming Convention guideline, as well as our Resource Tagging Guideline:

Subscribe to our free newsletter

Scope and Purpose of Azure Naming Conventions

Microsoft states that “An effective naming convention consists of resource names [which are based on] important information about each resource. A good name helps you quickly identify the resource’s type, associated workload, environment, and the Azure region hosting it”, (see the “Define your naming convention” reference at the bottom of this article). There are also other benefits of using one. Along with having a tag management process in place, having a naming convention for Azure is a must have for any organization that wants to impose security requirements or who wants to utilize Azure as efficiently as possible.

The purpose of using a naming convention is therefore to:

• Convey important context about a resource in the portal, script output, spreadsheets, log events, and system monitoring solutions
• Facilitate governance and security by making it easier to ensure that everyone is following the organization’s guidelines
• Avoid duplicate names i.e., the same name being assigned to multiple resources across the environment
• Reduce spending by de-allocating resources used in development, or testing, when they aren’t in use
• Reduce risk of unintentional downtime due to human errors

Naming Azure Resources

All Azure resource names consist of different “naming components” which are in almost all cases separated by the dash/hyphen character. A naming component is a part of the full name that conveys specific information. A naming convention specifies which naming components should be used for a specific resource type, their order, and provides examples of what a name should look like. This means that the convention is in large part a list of naming patterns for each resource type. The naming pattern specifies the naming components that should or may be included, and in what order they should be inserted.

For example, a virtual network could have the name “vnet-shared-hub-prod-weeu-01”. While a virtual machine could have the name “vmnbfeprod01”. While different naming patterns are used here, both convey important information about the resource proper.

Naming Rules and Restrictions for Azure

Besides delimeters, only alphanumeric characters are used in names. It’s important to note that Azure enforces a set of naming restrictions for Azure resources regarding which characters can be used or the maximum length of the name. The service type in Azure enforces this which means that deployment of resources fails if they don’t adhere to the restrictions. Microsoft provides information on character limits so check the references in this article to learn what they are. They have changed over time so they will change in the future also.

Prefixes, Separators and Common Abbreviations used in Resource Naming

List of possible components to use when naming Azure resources:

• Resource Type: Unique abbreviation for Azure resource or service type that is approved and supported for use in the organization
• Unique name: Name of the application, project, or service
• Purpose: Indicates if the resource is “shared” among stakeholders, or if it’s dedicated to one application
• Environment: Unique abbreviation used for the type of environment (dev, test, prod) the resource is deployed in
• Region: Unique abbreviation used for the region the resource is deployed in
• Business Unit: Unique abbreviation used to denote a department such as IT, HR, Finance, Marketing
• Role: Unique abbreviation for specific architectural component such as frontend, middle tier, backend, database, etc.
• Instance: A numeric of a specific length, including padding, which is denoted by “#” characters

A prefix or suffix is recommended, and both are usually used. The resource type is then used as the prefix and the instance number is the suffix. Resources that are created automatically as part of a larger deployment might be named in differently by Azure itself.

Microsoft Azure Resource Types

The resource type prefix is abbreviated to keep the name length to a minimum. Here are some recommended abbreviations:

• Resource Group: rg
• Virtual Network resource: vnet
• Virtual Machine resource: vm
• Virtual Machine Scale Set resource: vmss
• Public IP resource: pip
• Storage Account resource: st

Note: Azure Storage Accounts are a special case when it comes to naming as the can only contain alphanumeric characters.

Delimiters

Several characters could be used as delimiter in names, but most organizations use hyphens as default. The underscore character can be used to increase readability in one of the naming components. The alternative to that is to combine lowercase with a single uppercase character. Special characters are to be avoided as they usually aren’t even supported in Azure.

Naming Virtual Machines

There are restrictions regarding name length when naming Azure virtual machines. The main idea here is to include an application name, application abbreviation or some kind of denominator for an application that is possible to understand. The naming pattern used for a virtual machine named “vmnbfeprod01” is:

vm<”unique name”><”environment”><##>

Naming App Service Web Apps

The naming pattern used for a production web app named “app-nbfe-prod-weeu-01” located in the “West Europe” region is:

<”resource type abbreviation”> - <”unique name”> - <”environment”> - <”region abbreviation”> - <##>

Naming Virtual Networks

The naming pattern used for a hub virtual network called “vnet-shared-hub-prod-weeu-01” is: 

<”resource type abbreviation”> - <”purpose”> - <”role”> - <”environment”>-<”region abbreviation”>-<##>

Naming Network Security Groups

The naming pattern used for a Network Security Group named “nsg-snet_nbfe-prod-weeu-01” that filters traffic for the subnet called “snet_nbfe” is:

<”resource type abbreviation”> - <”filtering scope”> - <”environment”> - <”region abbreviation”> - <##>

Naming SQL Servers and Databases

The naming pattern used for a SQL server named “sql-nubops-prod-weeu-01” is:

<”resource type abbreviation”> - <”unique name”> - <”environment”> - <”region abbreviation”> - <##>

The naming pattern used for a SQL database called “sqldb-nubops-prod-weeu-01” hosted on that server is:

<”resource type abbreviation”> - <”unique name”> - <”environment”> - <”region abbreviation”> - <##>

Exporting Workload Data

Information might be exported from Azure, either using the portal, scripts, Azure SDK’s or an Azure API. Therefore, it’s always good to keep names as short as possible since they might end up in a CSV or Excel spreadsheet. One thing to consider is that names are usually listed in alphabetical order, not only in the Azure portal, but in files or data that is exported from Azure.

Names as Metadata

A good name should convey information and context as a type of metadata. The idea is that the metadata is automatically provided wherever names might appear, such as in logs, alerts, monitoring systems etc. When reading a name, that has been created according to a convention, it’s should be easy to understand where that resource is located, how critical it might be and what it’s used for.

Names for Subscriptions and Azure Resource Groups

Azure subscriptions should be named in a way that makes it easy to understand what any given subscription is used for. This is especially crucial in larger organizations who have many subscriptions, some of which are shared while others are dedicated to running an isolated solution.

Azure resource groups contain all resources that are created in Azure to group them together for management and security purposes. A name within a resource group has to be unique, but this also means that resources in different resource groups could end up with the same names. This becomes avoidable when naming resources in a structured way. Another consideration is that resource groups might contain resources located in different Azure regions, which means that a region abbreviation shouldn’t normally be included in their names. There might be situations when it could be considered, but it’s not the norm.

Names for Resources in Different Azure Regions

One reason behind wanting to include region abbreviations in naming patterns is that virtual networks for example are often created in a hub and spoke architecture. Virtual networks are created in a specific region as part of a “landing zone” where other resources can be deployed in. The hub virtual networks (in different regions) are then peered together to provide network connectivity for all the resources, but also to support load balancing, fail over, and disaster recovery scenarios.

Names for Transient Resources

Virtual networks are static in the sense that they are created in one region and not moved to another region afterwards. Servers however can be moved from one region to another. This means that the “region” naming component isn’t desirable to include, since names can’t be changed once a resource has been created. For servers it’s also the case that the VM name is included in the other resources that are created along with it i.e. network interface, public IP address, OS disk, data disk. This is the reason why no hyphens are included in the naming pattern for virtual machines as it improves readability of other resource type names.

Implications for Resource Tagging

Resource tags are key value attributes that are added to resources to facilitate governance and security. Using tags to organize your environment is a standard best practise. Azure also assigns some tags automatically to resources during deployment. A resource, or it’s resource group, usually is assigned the tag with a key “environment” and a tag value that might “dev”, “test”, “prod” for example. The metadata in the tags should be consistent with the name. If not, then it’s likely that a mistake has been made.

Implications for Globally Unique Resources

The names of some resource types must be unique across all of Azure, not only your environment. Since they have to be named uniquely it’s important to consider the implications if their names are too easy to guess. Enumeration of assets and running services is usually performed in the initial reconnaissance stage when threat actors are preparing to carry out an attack. Considerations needs to be made to make these unique names difficult to guess. One technique might be to avoid using a word or phrase that is used by your organization publicly. Another might be to insert a random combination of alphanumeric characters in a name. 

Naming unique Key Vaults

The naming pattern used for a key vault named “kv-myapp_xh7b-prod-weeu-01” is:

<”resource type abbreviation”> - <”unique name”> _ <”4 random alphanumeric”> - <”environment”> - <”region abbreviation”> - <##>

Naming unique Storage Accounts

The naming pattern used for a storage account named “stinfralogsprodweeuxh7b” is:

<”resource type abbreviation”><”purpose”><”environment”><”region abbreviation”><”4 random alphanumeric”> 

Implications for Automation using PowerShell or Azure CLI

The following is an example of how logic could be applied to create names dynamically based on parameters supplied as input to a script. Based on the assumption that you are managing your environment using a command-line is some way or situation. If you are using Infrastructure as Code templates either those native to Azure, Terraform or Biceps then this is a different matter which I won’t cover here. 

In the case where 12 virtual machines should be created to host a load balanced application called “newservice”, in a production subscription, the two parameters would be:

name = “vmabcdprod” nr = 12

The logic of the script would be similar to this in the case where you want to re-use the code snippet between scripts and implement some sort of safe-guard on how many resource instances can be created as a maximum:

if nr is more than 99 then exit script

for x is 1; increment x by 1; until x is equal to nr

resourceName = name

if x is less than 10 then resourceName = resourceName + 0 + x

else if x is more or equal to 10 and x is less than 100 then resourceName = resourceName + x

create resource using resourceName as name

This means that this script would create virtual machines with names such as vmabcdprod01 and vmabcdprod12.

Azure Naming Anti-patterns when Deploying and Organizing Resources

The following are examples of what someone could want to achieve by not using a naming convention:

• Ensure that the Azure environment is unstructured and that no one knows, or can easily find out, what subscriptions, resource groups, and resources are used for. This means that you’ll need to spend less time on architecture, design, and scripting.
• Make it difficult to differentiate between environments so that appropriate policies, restrictions, and cost management controls can’t be implemented. This will also drive up cloud costs for the organization, so that you can make a better case for going back to using the on-premise servers under your desk at the office.
• Assign resources a name which makes it more probable that no one will ever dare to remove it, since they’ll think that it could be running something important. Even more so after you’ve left the company.
• Make sure to give resources a name that makes it easier to expose it to the Internet in an insecure way. This saves time when accessing the resource from the comfort of your own home using your own laptop.
• Ensure that monitoring, security monitoring, and security reviews are less likely to identify non-compliance and issues or will require more effort. This will result in you having to do less work with remediation/mitigation and can spend more time experimenting with cool new tech instead.
• Assign server names based on fantasy books, science fiction, Marvel heroes, planets, countries, etc. Never replacing a server with a new one means you can work less, and also that your expertise will be required for all upgrades since they would otherwise cause the application to crash. At least until the operating system isn’t supported by Microsoft any longer.
• To avoid having to change a server name, you should always do in place upgrades on the same server, in the production environment, and troubleshoot until it works again after the upgrade. Use backups as the primary failsafe, but don’t verify if the backup can be used to restore the server as that takes too much time.

Performing reviews

When I perform a review of an environment, one of the first things I always start out by checking in the Azure portal is if there seems to be a naming convention in Azure has been used, and if it has been applied consistently. This provides a lot of insights into how the organization is working with governance and security, and what other potential issues I’ll likely see as I dig deeper. I’ve seen many Azure environments where a naming convention hasn’t been used or not used consistently across the organizations subscriptions.

Possible issues:

• There are no restrictions in place, or approvals required, to deploy resources to the environment
• Resource configurations differ and it’s unlikely that the people who deployed the resource followed best practices and security recommendations

Possible conclusions:

• Work is done ad hoc (CMM level 1)
• There is no well-functioning Change Management process within the organization
• There is no-one who is accountable and responsible for IT security who performs verification and issues approvals
• Unnecessary costs are accrued due to a lack of automated deallocation of resources when they aren’t needed

Final note: Microsoft Azure Resource Naming Conventions

In this article I’ve tried to explain why a naming convention for Azure needs to be different than one used for on-premise environments, what the benefits are, and how it can be done to gain control over your Azure environment. I hope this article will help with understanding the background, the benefits and how to implement it all as naming requirements need to be put in place. You should always establish a naming convention from the get go if you are creating a green-field environment. If you are responsible for brown-field environment, then it will take time to implement as resources in Azure can’t be renamed. If possible, enforce naming restrictions also. Resource naming should be consistent across all subscriptions if possible. Consistent naming makes it possible to verify that everyone is aware of established guidelines and policies within the organization. Proper naming of resources has been best practise for on-premise environments, and it also needs to be applied when using Azure.

If you want to use the Naming Convention Guideline to name a resource or resource groups, then you’ll need to go through it and clear out all resource types that you aren’t using at the moment. It will likely be the case that you’ll need to adopt the naming convention over a long period of time. In most cases you’ll only have the opportunity to change a name when a resource is decommissioned and is to be replaced by another.

As a reminder if you haven’t done so already, subscribe to our newsletter here and you’ll receive access to the Naming Convention Guideline:

Subscribe to our free newsletter

References

Azure recommendations:

• Cloud Adoption Framework

• Tutorial: Define your naming convention

• Abbreviations suggested by Microsoft: Abbreviation examples for Azure resources

• Azure Naming tool: AzNamingTool