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.




I don't believe 0800VM001-ST-001 would be a valid storage account name.  They must be alphanumeric and lowercase (and I believe starting with a letter).  Something like vmst0800001 may be a better alternative, though possibly likely to conflict with others as it's somewhat generic and the names are globally unique.


Ah, good catch, I forgot to remove the hyphens! They can start with a number though.


Why, please explain to me why you have to put 0 (zeros) in front of the numbers? I keep fighting users keep using this naming conventions, sometimes they put one zero, sometimes they put 2 zeros. As soon as I see this pattern I immediately see person who never automated in their life. Try to iterate when your number have leading zeros in powershell, as soon as you try you will realize you accomplished absolutely nothing with putting zeros in front of number. You accomplished exactly ZERO with putting ZERO in front of the name and yet you shortened already dwindling number of total variations can be had for your resources since those zeros just take up space and causing all sort of issues with scripts which needs to simply enumerate resources. 

I read through the article hoping that somebody will finally explain to me why people keep doing that since article actually called "best practices in naming". 

Here is enumerating servers from 1 to 20 in powershell in normal scenario. Please write powershell which will do the same when you have leading zeros. Not saying it's impossible or difficult but bigger question why. Or even for more crazyness with this advice to have zeros in front of numbers, try to write ARM template to add 20 disks to VMs with names having leading zeros. 

1..20 | %{"Server$_"}



@Gregory Suvalian Thanks for sharing your feedback. Leading zeros have come from a background of making displays and reporting easier, especially lists, so you don't end up with vm1, vm11, vm2 etc. You raise a good point re the scripts enumeration and ARM templates though. I'll pass that back to the teams, as leading zeros are even used in our examples at docs.microsoft.com on Azure naming conventions.  


I tried as well. Don't think it's going anywhere since I keep seeing this in various demos/docs etc as you mentioned with no clear explanation as to why.



Occasional Visitor

@Gregory Suvalian - I like left-padding numbers with zeros :-)

Good to the eyes and perception (at least to mine), they align well. Easier to text-parse if ever needed.

The problem is that one needs to estimate the number of digits that will accommodate the maximum number.

In some cases, abbreviations can be defined, as in IPv6.


PS: This does not necessarily mean I prefer monospaced fonts ;-)


How left padding with 0s help with text-parsing? It's horrible for both pattern match and manual string parsing. I have very limited understanding how left padding with 0s helps with anything at this point. Yes it will keep total number of characters in instance name constant, but is it ever usefull for any sort of non-human interpretation? 

Occasional Visitor

I meant in general.


Take the convention set as simply VM + <number>:

(i) With padding: VM001, VM002, VM003, ..., VM036, VM037, ..., VM571, ..., VM622, ... 

(ii) No padding: VM1, VM2, VM3, ..., VM36, VM37, ..., VM571, ..., VM622, ... 


Now, in Excel if you want to split the number part it is quite easier for (i) (simply =RIGHT(x, 3)) compared to how you would do it for the case in (ii). Fixed length of each component helps here. But without padding (hence no fixed-length components), with more complex constructs, e.g. when two components that only contain numbers are concatenated, it may become impossible to derive components.


And, in lists and reports padded numbers will look better and easier to perceive the components within the concatenated text.


I agree, mostly for human interpretation, but yet humans do look at these and we often use concatenation of multiple components when coming up with names. And for non-humans, I guess they do not care anyway :-)


And, I believe this may be deemed as just a matter of personal liking.


I challenge anybody who thinks that it's acceptable to have 0s padding on a left to write a ARM template to create 20 resource names with that convention in place.