Cloud Resource Naming Convention (Azure)

In any organisation it is important to get a standard naming convention in place for most things, but especially with cloud-based resources.

As many types of cloud resources require globally unique names (due to platform DNS resolution), it’s important to have a strategy that will give you a good chance of achieving global uniqueness, but also as helpful as possible to human beings, as well as codifiable in DevOps CD pipelines.

The easiest thing would be to have some horrendous code or GUID that is either unreadable and/or requires copious looking up of codes in code tables to decipher what and where the resource is.

After years of using Azure, I thought I would share my preferred naming convention. I believe it to be intuitive, human readable and provides a good level of information and … a reasonable chance of first attempt anyway, of global uniqueness.

The Convention


or without hyphens


The examples above would be the first instance (001) of the Storage Account (sa) for my organisation’s (nerr) project (test) diagnostics and logging data (diag) in the development environment (dev) that will be hosted in the UK South region (uks).

The order and number of elements is not accidental. It will become clear when you have multiple environments in multiple regions!

The ‘codes’ should be kept as small as possible. Somewhere between 3 and 8 characters ideally.

See the examples below.

The Elements

Name PartDescription
This is your identifiable organisation name short-code.

Don’t make it too generic a word, but this will be key to
maximising you names global uniqueness.

It is also useful if you support multiple divisions or
organisations to easily differentiate between them.

For Example:
McDonalds might use ‘mcd’ or ‘mcdon’
Microsoft might use ‘ms’
Oracle might use ‘orcl’

Mine is ‘nerr’
Project short codeThis is the project, product, or platform identifier.
This needs to be unique in your organisation.

Here I have used ‘test’, meaning this is my test project

hint: removing all vowels from a name can be a way to create a good code
Resource type code This is a code that represents the Azure (or other cloud providers) resource type.
See the list below.
App codeThis is the name of the workload, purpose, or app that the resource supports.
e.g. ‘Customer Function API’ would shorten to ‘cust’
and related resources, such as storage etc., would have the same code
and only vary by resource type.
Environment codeThis refers to the deployment environments.
Such as Development, Test or Production.

Recommended codes are:

– dev
– qa
– sit
– pre
– prod
Region codeThis refers to the regional data centre that the resource is deployed to.

see the list below for Azure
Instance no[Optional]
This is only required when you will be instantiating multiples of the same resource.

E.g. multiple VM’s in a cluster

I would use one leading zero, as this allows good sorting for up to
99 instances of something.

e.g. ’01’, ’02’. In large really large environments even 3 leading zero’s’001′

Key Principles

  1. All names should be lowercase or Pascal Case (Camel Case with the first character uppercase) if allowed
  2. Use and update the tables below for short-codes
  3. Use hyphens when possible
  4. If no environment is specified in the name, then Production is assumed
  5. try and keep the name length concise
  6. Do not use any non URL safe charters anywhere
  7. Do NOT use any special characters at the start or end of the name
  8. If you name turns out to not be unique then alter the ‘Product Code’ to be more unusual.


For a one of my test apps called Customer I may have an Function API, A SQL Azure database and a Storage account all in a Resource Group. Development in North Europe and Production in West Europe. The naming would be as follows:

  • nerr-test-rg-dev-ne
    • nerr-test-func-cust-dev-ne
    • nerr-test-sql-cust-dev-ne
    • nerr-test-st-diag-dev-ne
  • ner-test-rg-prod-we
    • nerr-test-func-cust-prod-we
    • nerr-test-sql-cust-prod-we
    • nerr-test-st-diag-prod-we

Some Resource Type Codes (Azure)

This is not a comprehensive list but should give you the idea. If you want to contribute here, please send me your codes 😉

ResourceCodeHyphens Allowed
Resource Grouprgyes
Application Service Planapsyes
Container Registrycrno
Storage Accountstno
Data Factorydfyes
Databricks Workspacedbwyes
Function Appfuncyes
Azure SQL Serversqlyes
Virtual Machinevmyes
Virtual Networkvnetyes
Search Servicesrchyes
Web App Servicewayes
API App Serviceapiyes
Data Lake Storedslno
Network Security Groupnsgyes
Public IP Addresspipyes
Load Balancerlbyes
Availability Setlayes
Recovery Services Vaultvltyes
Key Vaultkvyes
DevTest Lablabyes
Application Service Planaspyes
Kubernetes Serviceaksyes
Local Network Gatewaylngyes
Virtual Network Gatewayvngyes
Service Bus Namespacesbnyes
Synapse Analytics Workspacessynwyes
Synapse Analytics SQL Dedicated Poolsyndpyes
Synapse Analytics Spark Poolsynspyes

For Microsoft’s recommended abbreviations see Abbreviation examples for Azure resources – Cloud Adoption Framework | Microsoft Learn

Environment Codes

QA / Testqa
System Integration Testingsit
User Acceptance Testuat

Region Codes (Azure)

Exceptions, Variations and Restrictions

Storage Accounts

Storage accounts must be between 3 and 24 characters in length and not contain ‘-‘ dashes.

When we account for the other elements


In my case we can see that the maximum length of the {AppName} is 7, 8 or 9 characters depending on location and environments.

Any creation pipeline must concatenate the {PlatformShortCode}{AppName}.

Key Vault Secrets

One Key Vault exists for each security boundary. The security boundary may incorporate several applications and databases. So, it important the keys are explicit, descriptive, and unique across the estate to ensure everyone can identify them and that they can be used, unambiguously in release pipelines.

There will be a Key Vault for each environment and is essential that the key is identical between environments, so does not include the environment short-code at all.

Service Bus and Message Queue Names

Messages often carry information that pass the baton of handling certain steps in a workflow or a processing chain to a different role inside a system. Those messages, like a purchase order or a monetary account transfer record, may express significant inherent monetary value. That value may be lost and/or very difficult to recover if such a message were somehow lost in transfer.

Events are also messages, but they don’t convey a publisher intent, other than to inform. An event captures a fact and conveys that fact. A consumer of the event can process the fact as it pleases and doesn’t fulfill any specific expectations held by the publisher.

{service | workload | subject}-{event | purpose | Intent}-{message type or contract}-sbq



Topic Names

{service | workload | subject}-{event | purpose | intent}-{message type or contract}-sbt



here the message or contract is an identity object. This kind of object may be the same used in many queues, topics or events.

SQL Servers and database names

In the world of micro-services the name of the database should reflect the microservice it is associated with.


Including the Platform ShortCode allows databases to be aggregated onto shared database servers if required.


Database Name Examples:

  • testcustomer
  • testoffer


Since producing this scheme, Microsoft have published their own advice which you can find at

and detailed information on Naming rules and restrictions for Azure resources can be found at

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.