Naming standardOne 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 ConventionIf 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 recommendationIn 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
|
Element |
Examples |
Notes |
Specific ex |
|
<App or Function> |
ProductQuote, Shipping, PickList, OrderTracker |
Project, function or program short name |
MST |
|
- |
- |
Delimiter (n/a for storage account names, virtual machines) |
|
|
<component> |
portal, query, trans, AI, rpt, config |
This is the component of the system not necessarily the resource type. If you have a transactional, log and audit database this would distinguish them. (trans, audit, log) |
For VMs |
|
- |
- |
Delimiter (n/a for storage account names) |
|
|
[<region>] |
wus, eus, scus, eaus, saus |
If your app has multi-region deployment you will need to ensure uniqueness of the name for globally unique resources like key vaults and storage accounts |
|
|
- |
- |
Delimiter (n/a for storage account names) |
|
|
<environment> |
dev, test, prod, stage, perf, scale, uat, sandbox |
Depending on the purpose and name of each environment. In general the minimal set is based on your deployment lifecycle (ex dev>test>uat>prod) ancillary ones are typically based on different testing environments (perf, scale) or production support env (stage, A/B, Slot1/Slot2) |
dev |
|
- |
- |
Delimiter (n/a for storage account names) |
|
|
<resource type> |
sql, vnet, ip, nsg, vm, vmss, rg, aa |
Azure type suffix (see list of abbreviations for more) |
vm |
|
[##] |
01, 02, 03, etc. Z1, Z2, Z3 |
Optional, used for scaling out resources Generally, two digits – with leading zeroes if < 10 With zonal deployments for scale and HA use Z1,Z2,Z3 as currently there are only 3 zones |
01 |
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.
