Cloud Naming Convention

Consistent naming strategy is important and should be an essential part of any cloud effort, especially as the number of managed resources grows in an organization. Unfortunately, it is often overlooked by users across domains. Consistent cloud naming strategy is the first step in achieving even basic levels of consistency and prerequisite to establishing any sort of cloud governance. Good could naming conventions also help associate cloud usage costs with business teams via chargeback and showback accounting mechanisms.

Naming standard

One of the main benefits of the cloud is that you can deploy and tear down whole environments rapidly, spinning up environments only when needed. Incorporating that into the culture, is key to keeping cloud costs down.  Since environments are "temporal" having a naming convention that incorporates the environment will help you with readability, so you know what application, a set of resources belong to, and where in the lifecycle are they. In addition to discoverability, a well thought out naming convention consistently applied, allows you to leverage automation to better manage your environment for both deployment and maintenance.

Naming Convention

If you walk away with only one thought from this article, it should be that a good naming convention has to be ordered by significance and should be unique.

What does ordered by significance mean?

From left to right your elements in the name should be of decreasing significance. For example – Division-Group-Member-status.

A division is comprised of many groups, which have several members and each member has a status.

By using decreasing significance resources that work together and are sorted together by name enhances readability.

The next key aspect of a naming convention is uniqueness. Your naming convention must allow you to uniquely name both globally named resources like storage accounts and locally named resources in a resource group, so you don’t have a naming conflict that would prevent deployment. An example of this is, if you create a resource group to house a hub of virtual networks used to peer multiple geographies, you will need to add the region element into your naming convention so the virtual network names are unique.

If you need a naming convention that is cross-cloud or independent of deployment environment (subscription), you might want to consider adding those elements to the below convention.

When considering adding elements, add them only if they are necessary. The more you add, the harder it is to gain adoption and to use them consistently with character constrained lengths. For example, Virtual Machines have a limitation of 15 characters.

This convention applies to all Cloud elements (management groups, subscription names, resource groups and all the resources). It does not apply to names of elements within a resource like Storage Account containers, SQL Database names or Network Security Rule names.

Note: Some Azure services deploy their own resources and use a default naming convention (e.g., Network Watcher creates the NetworkWatcherRG resource group). 



Naming convention recommendation

In this example, elements of the name are in order of significance as this will naturally group similar resources by what you deem most significant. Unless otherwise advised, the proposed naming convention for all foundational deployed resources will be used as follows:

[ ] means optional

Examples - MSTdcvm01dev MDIdcvm01dev
MDIhmsvm01prod
123456789012345

Note: In the VM name case above, we had to drop the hyphens in order to stay under the 15-character limit. It is recommended not to use hyphens in VM names period.

If you are to deploy multiple locations in the same resource group, you would also require location to be part of the name after resource type and before environment.

Convention: 

<App>-<component>-<type>[###]-<environment> or

<App>-<component>-<type>[###]-<region>-<environment> if multiple regions of the same resource are in the same rg like may be done for a Gateway

Example: SeedTrk-web001-app-prod,  seedtrksaprod, SeedTrkJBvmprod

 Note: Storage accounts “sa” have special naming consideration as they have limited character set, global scope and length (24)

Note: VM's have a 15-character name limit

In case your organization is looking for an expert guidance to successfully navigate changing infrastructures and innovation opportunities with custom cloud solutions and strategies, visit our solutions page.

Frequently Asked Questions (FAQs)

Why is cloud naming convention important?

Consistent naming strategy is foundational to cloud governance and is often overlooked as infrastructure grows. Good naming conventions: provide discoverability (knowing what resources belong to which applications), enable automation for deployment and maintenance, support chargeback and showback accounting by associating cloud costs with business teams, and improve readability when managing multiple environments. Without it, managing rapidly deployed and torn-down cloud environments becomes chaotic.

What does "ordered by significance" mean?

"Ordered by significance" means elements in your naming convention should decrease from left to right. For example: Division-Group-Member-Status. A division contains many groups, groups contain many members, and each member has a status. By ordering this way, resources working together are sorted together by name, enhancing readability and discoverability. This natural grouping makes it easier for teams to understand resource relationships at a glance.

What is the uniqueness requirement in naming conventions?

Your naming convention must allow you to uniquely name both globally-scoped resources (like storage accounts and key vaults) and locally-scoped resources (within resource groups). If you deploy resources across multiple regions in the same resource group, you must include the region in the naming convention to avoid conflicts. Adding a region ensures names remain unique and deployments don't fail due to naming collisions.

What's the recommended cloud naming convention format?

The recommended format is: <App>-<component>-<region>-<environment>-<resource type>[##]

Where:

• <App> = Application or function name (ProductQuote, Shipping)

• <component> = System component (portal, query, trans, AI)

• [<region>] = Optional region code (wus, eus, scus) for multi-region deployments

• <environment> = Environment stage (dev, test, prod, stage, uat, perf)

• <resource type> = Azure resource suffix (sql, vnet, vm, nsg, rg)

• [##] = Optional numeric suffix (01, 02, 03 or Z1, Z2, Z3 for zonal deployments)

Example: SeedTrk-web-eus-prod-app or MST-dcvm-prod (with hyphens removed for 15-character limit)

How do I handle special character constraints?

Two resources have specific constraints:

(1) Virtual Machines - 15-character limit. Remove hyphens to stay within limit. Example: MSTdcvm01dev instead of MST-dc-vm-01-dev

(2) Storage Accounts - 24-character limit, only lowercase letters and numbers allowed (no hyphens). Example: seedtrksaprod (no delimiters)

Only add necessary elements to names. The more you add, the harder adoption and consistency become, especially with character-constrained resources.

Should I include region in my naming convention?

Include regions only if necessary. You must include a region if: your application deploys across multiple regions, you need to ensure global resource uniqueness (storage accounts, key vaults), or multiple instances of the same resource type exist in the same resource group. Use Azure region codes (wus=West US, eus=East US, scus=South Central US, eaus=East Australia, saus=Southeast Australia).

What environments should I include in naming?

The minimal set is based on your deployment lifecycle (dev → test → uat → prod). Additional environments depend on your testing and production support needs: performance testing (perf), scale testing (scale), staging (stage), A/B testing, or deployment slots (Slot1, Slot2). Define environments based on your actual deployment process to ensure consistency.

How do I ensure consistent application of naming conventions?

Three steps: 

(1) Document clearly - publish your naming convention with examples for each resource type. 

(2) Automate enforcement - use Azure Policy or deployment templates to enforce naming patterns during resource creation. 

(3) Make adoption easy - keep conventions simple, use templates developers can copy, and provide clear examples. The more complex your convention, the harder consistent adoption becomes.