Best practices for naming your Microsoft Azure resources

[Sonia Cuff]

When talking about Cloud infrastructure, you might have come across the phrase “Pets versus cattle.” It appeared around 2012 when Bill Baker used it to differentiate between servers that can never be down and servers that are easily replaceable (e.g. part of a cluster, built with automated tools etc). Traditionally, we’ve know our “pet” servers by name, we’ve watched them closely through each update and we’ve rushed to their aid if they’ve had any health problems. With cattle though, each server is disposable and another new virtual machine can easily take over the workload, minimizing downtime. From a consumer standpoint, Software-as-a-Service runs on cattle. I usually don’t know the name of the server I’m connecting to and if it fails, I expect the provider will have another one waiting (or easily spun up) to continue my service availability.

I worked for the Dairy Industry for a little while, so here’s a fun fact: Cattle have names too. Farmers track them by name, keep record of whether they’ve had their vaccinations and monitor the health of their cattle so they can selectively breed out deficiencies and improve the blood line. They’re usually not named Daisy or George, but may be a unique reference number instead. With Infrastructure-as-a-Service, not only do we need to name our cattle, but we need to name all the associated things that a cattle server comes with.

On-premises practices
If you’re not starting out new in the Cloud, you probably have some on-premises resources you are managing already and hopefully some structure around how you name those things. Even if you don’t have any existing servers, you should at least have naming standards for the other devices in your organization (e.g. laptops, desktops and printers.)

A common naming standard might look like:
S, W or L, P – Server, workstation, laptop or printer
+ Cost center code
+ Company abbreviation
+ Unique number
Which would give us names like S0800ABC001 and L0519ABC009.

Structuring names with a standard makes it easy to tell what kind of device it is and where it is located. That’s important when we are viewing systems on a monitoring dashboard or running scripts on systems. If I see an S named machine is in red, I’m going to prioritize a response to that much quicker than an L machine.

You might even throw in a special identifier for a certain application (e.g. M for an e-mail server) or an operating system identifier if you are running a mixture of Windows and Linux.

If you haven’t formalized a naming standard yet, it’s worth doing. Many small companies start out with servers and laptops named Luke, Leia and Yoda, then find this makes operational management harder as they grow, especially when they have multiple office locations.

In an Active Directory environment, you may even have structured Organizational Units (OUs) to help group certain kinds of devices, to apply policies to or to control whether they sync with Azure Active Directory.

So do these naming standards work in a Cloud world? And if we’re shifting some workloads to the Cloud but keeping others on-premises, how do we tackle naming then? Let’s take a look at some of the Cloud resource naming challenges.

All the resources
Even with virtualization, we’re used to a virtual machine being one entity – a virtual hard disk file. That file contains settings that define things like the virtual network adaptor. In Microsoft Azure, a virtual machine is a combination of multiple resources: a virtual machine, a storage account, virtual disks, a virtual network, a network interface and optionally a public IP address. To learn more, check out the free Create a Windows virtual machine in Azure module at Microsoft Learn. All of those resources need names, and ideally we’d bundle them together in one, appropriately named resource group. 

But virtual machines in Microsoft Azure are just the start. We’ve also got automation accounts, runbooks, CDN profiles, cognitive services, web app bots and availability sets, just to name a few! These also show up in the All Resources area of the Azure portal.

If you have a larger IT department, with pockets of specialists creating or maintaining specific applications, you might lose control of how those new resources get named when they are created. Well-defined and communicated standards are very important here, before your resource list looks like an uncontrolled file and folder share.

Tips for a solid naming structure
Every organization handles naming differently, but they should all have the same goals in mind.

Set the standards early, because names are difficult to change later (if they can be changed at all).

Define a structure that reflects your organization and its operational IT needs. That can include differentiating between production and QA Cloud environments, aligning resources by business unit or bundling services under the same legal jurisdiction.

Ensure it is easy to tell the difference between Azure resource types, just by looking at the name. Although the All resources section of the Azure portal will include their type, that’s not visible when you’re running commands in Cloud Shell.

Using our on-prem example above, it’s unclear whether S0800ABC001 is a server or a storage account. A better name for a virtual server might be 0800-VM-001 with a storage account of 80vm01stor.

Prefixes and suffixes are your key to useful names, including hyphens (where allowed). Just watch that you don’t exceed the maximum number of characters allowed for a resource name, which varies between resource types. For example, a storage account name can be between 3-24 characters, while a container name can be up to 63 characters long.

My best tips for naming Azure resources are:
Standardize what you will use to identify the different resource types. I commonly use -VM (virtual machine), -Vnet (virtual network) - Pip (public IP address), -RG (resource group), -NIC (network interface) etc.

Don’t be afraid to mix and match, for example, using 0800VM001-RG as the resource group name for all the resources that make up the 0800-VM-001 virtual machine.

To learn more about the best practices for naming standards, including the allowed characters for the different resource names, see the naming conventions at docs.microsoft.com

But wait, there’s more!
In addition to individual resources, there are a few more Azure-specific things that require a name. After your Azure tenancy (which is most likely named after your organization’s email domain), you might segregate your billing by Subscription.

Then you can bundle subscriptions into Management Groups (logical groupings like Organizational Units - again, needing names) to apply policies, role based access control and templates. Policy Initiatives (a collection of policies) and Azure Blueprints (a collection of policies, roles, templates and resources) also need names.

And finally, resource tagging allows you to set another grouping identifier, which is useful in applying policies, reporting and cost management. That tag might be a department name or a project name, and can apply to all of the relevant resources, regardless of their type.

To complete the picture
Naming standards form one small part of Azure Governance, enabling you to structure and manage your Cloud resources in alignment with your organizational requirements. If set up correctly, resource creation, management, monitoring and cost analysis is made much easier.

For more information, visit our Azure Governance documentation and check out the Azure Enterprise Scaffold.