Being organized and being able to search and browse for azure resources is key to being productive in managing your azure infrastructure.

I believe a pragmatic naming convention should be

• Descriptive enough to know what the resource is in the context of the infrastructure
• Easy to remember and follow.
• Well adopted by other cloud team members.
• Need to balance between naming convention sophistication and simplicity.

Here is my recommendation on employing a naming convention for small to medium size enterprises.

[workload name]-[resource type]-[environment]-{regioncode}

Examples

storeapp-webapp-dev-cc

storeapp-sqlserver-dev-cc

storeapp-sqldb-dev-cc

storeapp-webapp-prd-cc

Resource Name Segment	Description	Required?
workload name	The name of the workload, service, system or application.	Yes
resource type	The resource type. This should be best as an abbreviation or short form name. Examples of abreviations are vm for virtual machine, sqldb for Azure sql database and Examples of short form are vnet for virtual network, stor for storage account and sqlserver for Azure Sql Server. A list of resource type short forms for reference can be found in these pages: Resource Abbreviations Example names for Compute and Web I follow this in general, but I like make my own short form names as I see fit. I try make these names less than 6 characters as best as I can. For resource types that are not commonly known I would opt for longer names such as trafficmgr for traffic manager instead of tm. For your organization, you should come up with a list of resource type short forms that everyone can easily follow and easily reference.	Yes
environment	I recommend 3 char and only up to 3 characters. This can be poc (proof of concept), dev (development), sit (system integration test), uat (user acceptance test), stg (production staging) and prd (production). It is important to have a fixed character length because character limits for names are different among resource types. If you had a name length that differed among environments, then you may not be able to fit the name due to max character length. For example, if you had a name storeapp-webapp-uat and that is the max character length, then when creating the resource for production with storeapp-webapp-prod, then you wouldn’t be able to create with this name. If prod important to keep, you had to compensate and compromise the other segment with something like storeap-web-prod. Keep this name segment the same length across each environment.	Yes
region code	Regional identifier in short form. Examples: cc for canada central, eu for east us. You can find the Azure region codes by running Az cli command az account list-locations If your resources are geographically dispersed in a solution, then recommend to include region codes. Regions for network related resources are important such as for vnets and load balancers. Network resources are highly coupled to regions due to latency and proximity. Some network resources can’t work together in different regions and so making the distinction in the name is essential. Try to keep region codes up to 4 character length where possible.	Optional but highly recommended Yes for network related resources
Numeral identifier	A numeric identifier for resources that are replicas in a clustered architecture. For example, virtual machines in an availability set and/or behind a load balancer. The numeric identifier can be 1, 2 or 3 digits. I think that most resources you will only have one in a logical set and therefore no need to have a “01” identifier all the time. Only when applicable.	Optional
resource group names	I typically don’t include rg names as they are hard to abbreviate and don’t provide much value. I typically view a list of resource by resource group anyways.	Optional – Low use
subscription name	For small and medium size enterprises, I usually see 1-3 subscriptions and not practical to include for each resource.	Optional – Low use
Business unit, group or project name	These name segments would help in a very large organization. I normally don’t employ this or seen it. This is mentioned in Microsoft’s guidance to naming conventions. Even so, they can rather be captured as resource tags. E.g. storeapp-webapp-prod-cc-retail	Optional

Note about Storage accounts: Storage accounts are one of the first resource types in the Azure platform and so they have more stringent requirements for naming convention with only lower characters and can’t include ‘-‘ to separate name segments. Therefore, I just exclude ‘-‘ as an exception for storage accounts.

Hope my guide and can help determine a productive naming convention for you and your team.

Microsoft Documentation References:

Defining your naming convention

Resource Abbreviations