When naming Azure subscriptions, verbose names make understanding the context and purpose of each resource clear. When working in an environment with many subscriptions and resources, following a shared naming convention can improve clarity. Here are some of the advantages of keeping Azure resource naming clear and consistent.
- Easy to locate
Properly named resources cleary show its position in the hierarchy from the rest of the group: which organization owns it, under which resource group it's belong to, what other resources are dependent to it, etc.
Different resources can have different unique and important properties. By applying affixes, recognizing resource attribute becomes very easy. Knowing its role and purpose without having to view its details becomes possible.
- Separation of context
Sometimes we want to control how we categorize resources. For example, we group resources from the same project/solution based on its environment context (eg : development, production, QA).
Recommended naming convention here are based on Azure guidelines (see Azure Guidance Naming Convention). There are some resources that are not discussed in the documentation, so I will give my own naming recommendation for some resources that are still following and adheres to Official Azure Naming Pattern.
In general, I recommend you to stick to the lowercase letter and avoid having any special characters (
_) as the first or last character in any name. These characters will cause most validation rules to fail.
|Resource Group||Resource Group||<service short name>-<environment>-rg||foobar-prod-rg, cookbook-dev-rg|
|Resource Group||Availability Set||<service short name>-<context>-as||foobar-web-as, cookbook-sql-as|
|Compute||Virtual Machine||<name>-<role>-<vm>||foobar-web-vm1, cookbook-sql-vm2|
|Storage||Storage||Data : <globally unique name><number>
VM Disk : <vm name withour dashes>st<number>
|Storage||Blob||<service short name>.blob.core.windows.net||foobar.blob.core.windows.net, cookbook.blob.core.windows.net|
|Networking||Virtual Network (VNet)||<service short name>-[section]-vnet||foobar-vnet, cookbook-vnet|
|Networking||Network Interface||<vmname>-nic<num>||foobar-web-vm1-nic1, cookbook-sql-vm2-nic3|
|Networking||Network Security Group||<service short name>-<context>-nsg||foobar-app-nsg, cookbook-web-nsg|
|Networking||Public IP Address||<vm or service name>-pip||foobar-web-vm1-pip, cookbook-pip|
|Networking||Load Balancer||<service or role>-lb||foobar-lb, cookbook-web-lb|
|Networking||Application Gateways||<service or role>-aag||foobar-aag, cookbook-aag|
|Networking||Traffic Manager Profile||<descriptive context>||foobar, cookbook|
|Web + Mobile||App Services||Web : <service name>-web
API : <service name>-api
|Web + Mobile||Logic Apps||<service short name>-logic||foobar-logic, cookbook-logic|
|Web + Mobile||Mobile Engagement||<service short name>-me||foobar-me, cookbook-me|
|Databases||SQL Databases||<service short name>-db||foobar-db, cookbook-db|
|Databases||SQL Data Warehouses||<service short name>-dwh||foobar-dwh, cookbook-dwh|
|Databases||SQL Servers||<service short name>-sql||foobar-sql, cookbook-sql|
Context Attribute (Affixes)
If we look carefully on each of the naming rules, almost every one of them contains what we called "affixes" or context attribute. Affixes could exists in two forms: which is prefix (in the beginning of a name) and suffix (in the end of a name). Affixes simplifies visual identification. When incorporating affixes into your naming convention.
Affixes can refer to different aspects that describe the particular resources. The following table shows some examples typically used.
|Environment||dev, prod, QA||Identifies the environment for the resource|
|Location||uw (US West), sea (Southeast Asia)||Identifies the region into which the resource is deployed|
|Instance||1, 02||For resources that have more than one named instance.|
|Product or service||foobar, cookbook||Identifies the product, application, or service that the resource supports|
|Role||sql, web, messaging||Identifies the role of the associated resource|
Properly naming your Azure resources will make your resources clearer, more informative, and manageable. Of course this conventions is not mandatory. In fact, you or your company can create your own (see Azure Infrastructure Naming Guidelines).
If you have any feedback, feel free to fill in the comments section below.