Creating a Naming Convention for Azure

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 naming convention without adapting it. This created issues since the naming conventions, which were designed to be used for on-premise systems, didn’t support new resource types that are created in cloud environments such as Azure. This article goes through the basic concepts and recommendations related to creating a naming convention for Azure. A detailed example of a “Naming Convention Guideline” for Azure is also provided to newsletter subscribers.

Challenge

Naming conventions have been used by IT departments for a long time. Initially, many naming conventions were based on science-fiction, fantasy or similar themes. This changed gradually 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. This also makes it easier to add or remove virtual servers when the demand for capacity changes, to analyze logs when responding to security incidents, and to perform system monitoring.

By keeping on using the same naming convention in new cloud environments, while not following Microsoft best pracises and recommendations, the result is that the same type of resources are given very different names based on who names them. The consequence of this is that in many cases there still isn’t any real structure to a Azure environment, or to specific solutions, especially given how easy it is to create resources in Azure by default. It can be difficult to understand what different subscriptions are used for, who should have access to certain resource groups, or which resources are actually used and when. This in turn makes it more difficult to work with governance and security since the goal of this is to establish control over subscriptions, resource groups, and the resources therein. It also tends to lead to increased costs since it’s also more difficult to work with Cost Management.

Perspective

This article is based on the concepts and recommendations related to creating a naming convention for Azure specifically. Creating a naming convention 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 resource 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

Purpose

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 a naming convention. 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 information 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 organizations 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 used
• Reduce risk of unintentional downtime due to human error

Naming components

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 naming 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-prd-weeu-001”. While a virtual machine could have the name “vmsharepointprd001”. While different naming patterns are used here, both convey important information about the resource proper.

List of possible naming components to use:

• Resource Type: Unique abbreviation for each resource 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

This means that the naming pattern for the virtual network mentioned above is:
vnet-<”purpose”>-<”role”>-<”environment”>-<”region”>-<###>

While the naming pattern for the virtual machine is:
vm<”unique name”><”environment”><###>

Names for regional resources

One reason behind different naming patterns being used in this example is that virtual networks are usually created in a hub and spoke architecture, in a specific region, to create a “landing zone” for other resources to be deployed in. Multiple virtual networks 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. Virtual machines 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 virtual machines 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 automation

The following is an example of how logic could be applied to create names dynamically based on parameters supplied as input to a script or a Infrastructure as Code template. 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 = “vmnewserviceprd”
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 999 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 + 00 + x

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

else if x is more 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 vmnewserviceprd001, vmnewserviceprd009 and vmnewserviceprd012.

Anti-patterns

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 planning, architecture, and design.
• 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 at better case for going back to using the on-premise servers standing in your room.
• 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 private 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 replace a server with a new one. At least not before 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 is if there seems to be a naming convention in use, and if it’s being applied consistently. This provides a lot of insights how the organization is working with governance and security, and what other potential issues I’ll likely see as I dig deeper.

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

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. If you want to use the Naming Convention Guideline 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:

• Define your naming convention

• Abbreviation examples for Azure resources

• AzNamingTool