| title | description | author | ms.date | pnp.series.title |
|---|---|---|---|---|
Naming conventions for Azure resources |
Naming conventions for Azure resources. How to name virtual machines, storage accounts, networks, virtual networks, subnets and other Azure entities |
telmosampaio |
05/18/2017 |
Best Practices |
[!INCLUDE header]
This article is a summary of the naming rules and restrictions for Azure resources and a baseline set of recommendations for naming conventions. You can use these recommendations as a starting point for your own conventions specific to your needs.
The choice of a name for any resource in Microsoft Azure is important because:
- It is difficult to change a name later.
- Names must meet the requirements of their specific resource type.
Consistent naming conventions make resources easier to locate. They can also indicate the role of a resource in a solution.
The key to success with naming conventions is establishing and following them across your applications and organizations.
When naming Azure subscriptions, verbose names make understanding the context and purpose of each subscription clear. When working in an environment with many subscriptions, following a shared naming convention can improve clarity.
A recommended pattern for naming subscriptions is:
<Company> <Department (optional)> <Product Line (optional)> <Environment>
- Company would usually be the same for each subscription. However, some companies may have child companies within the organizational structure. These companies may be managed by a central IT group. In these cases, they could be differentiated by having both the parent company name (Contoso) and child company name (Northwind).
- Department is a name within the organization where a group of individuals work. This item within the namespace as optional.
- Product line is a specific name for a product or function that is performed from within the department. This is generally optional for internal-facing services and applications. However, it is highly recommended to use for public-facing services that require easy separation and identification (such as for clear separation of billing records).
- Environment is the name that describes the deployment lifecycle of the applications or services, such as Dev, QA, or Prod.
| Company | Department | Product Line or Service | Environment | Full Name |
|---|---|---|---|---|
| Contoso | SocialGaming | AwesomeService | Production | Contoso SocialGaming AwesomeService Production |
| Contoso | SocialGaming | AwesomeService | Dev | Contoso SocialGaming AwesomeService Dev |
| Contoso | IT | InternalApps | Production | Contoso IT InternalApps Production |
| Contoso | IT | InternalApps | Dev | Contoso IT InternalApps Dev |
For more information on how to organize subscriptions for larger enterprises, read our prescriptive subscription governance guidance.
When naming resources in Azure, it is recommended to use common prefixes or suffixes to identify the type and context of the resource. While all the information about type, metadata, context, is available programmatically, applying common affixes simplifies visual identification. When incorporating affixes into your naming convention, it is important to clearly specify whether the affix is at the beginning of the name (prefix) or at the end (suffix).
For instance, here are two possible names for a service hosting a calculation engine:
- SvcCalculationEngine (prefix)
- CalculationEngineSvc (suffix)
Affixes can refer to different aspects that describe the particular resources. The following table shows some examples typically used.
| Aspect | Example | Notes |
|---|---|---|
| Environment | dev, prod, QA | Identifies the environment for the resource |
| Location | uw (US West), ue (US East) | Identifies the region into which the resource is deployed |
| Instance | 01, 02 | For resources that have more than one named instance (web servers, etc.). |
| Product or Service | service | Identifies the product, application, or service that the resource supports |
| Role | sql, web, messaging | Identifies the role of the associated resource |
When developing a specific naming convention for your company or projects, it is importantly to choose a common set of affixes and their position (suffix or prefix).
Each resource or service type in Azure enforces a set of naming restrictions and scope; any naming convention or pattern must adhere to the requisite naming rules and scope. For example, while the name of a VM maps to a DNS name (and is thus required to be unique across all of Azure), the name of a VNET is scoped to the Resource Group that it is created within.
In general, avoid having any special characters (- or _) as the first or last character in any name. These characters will cause most validation rules to fail.
| Entity | Scope | Length | Casing | Valid Characters | Suggested Pattern | Example |
|---|---|---|---|---|---|---|
| Resource Group | Subscription | 1-90 | Case insensitive | Alphanumeric, underscore, parentheses, hyphen, and period (except at end) | <service short name>-<environment>-rg |
profx-prod-rg |
| Availability Set | Resource Group | 1-80 | Case insensitive | Alphanumeric, underscore, and hyphen | <service-short-name>-<context>-as |
profx-sql-as |
| Tag | Associated Entity | 512 (name), 256 (value) | Case insensitive | Alphanumeric | "key" : "value" |
"department" : "Central IT" |
| Entity | Scope | Length | Casing | Valid Characters | Suggested Pattern | Example |
|---|---|---|---|---|---|---|
| Virtual Machine | Resource Group | 1-15 (Windows), 1-64 (Linux) | Case insensitive | Alphanumeric, underscore, and hyphen | <name>-<role>-vm<number> |
profx-sql-vm1 |
| Function App | Global | 1-60 | Case insensitive | Alphanumeric and hyphen | <name>-func |
calcprofit-func |
Note
Virtual machines in Azure have two distinct names: virtual machine name, and host name. When you create a VM in the portal, the same name is used for both the host name, and the virtual machine resource name. The restrictions above are for the host name. The actual resource name can have up to 64 characters.
| Entity | Scope | Length | Casing | Valid Characters | Suggested Pattern | Example |
|---|---|---|---|---|---|---|
| Storage account name (data) | Global | 3-24 | Lowercase | Alphanumeric | <globally unique name><number> (use a function to calculate a unique guid for naming storage accounts) |
profxdata001 |
| Storage account name (disks) | Global | 3-24 | Lowercase | Alphanumeric | <vm name without hyphens>st<number> |
profxsql001st0 |
| Container name | Storage account | 3-63 | Lowercase | Alphanumeric and hyphen | <context> |
logs |
| Blob name | Container | 1-1024 | Case sensitive | Any URL characters | <variable based on blob usage> |
<variable based on blob usage> |
| Queue name | Storage account | 3-63 | Lowercase | Alphanumeric and hyphen | <service short name>-<context>-<num> |
awesomeservice-messages-001 |
| Table name | Storage account | 3-63 | Case insensitive | Alphanumeric | <service short name><context> |
awesomeservicelogs |
| File name | Storage account | 3-63 | Lowercase | Alphanumeric | <variable based on blob usage> |
<variable based on blob usage> |
| Data Lake Store | Global | 3-24 | Lowercase | Alphanumeric | <name>dls |
telemetrydls |
| Entity | Scope | Length | Casing | Valid Characters | Suggested Pattern | Example |
|---|---|---|---|---|---|---|
| Virtual Network (VNet) | Resource Group | 2-64 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <service short name>-vnet |
profx-vnet |
| Subnet | Parent VNet | 2-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <descriptive context> |
web |
| Network Interface | Resource Group | 1-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <vmname>-nic<num> |
profx-sql1-nic1 |
| Network Security Group | Resource Group | 1-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <service short name>-<context>-nsg |
profx-app-nsg |
| Network Security Group Rule | Resource Group | 1-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <descriptive context> |
sql-allow |
| Public IP Address | Resource Group | 1-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <vm or service name>-pip |
profx-sql1-pip |
| Load Balancer | Resource Group | 1-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <service or role>-lb |
profx-lb |
| Load Balanced Rules Config | Load Balancer | 1-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <descriptive context> |
http |
| Azure Application Gateway | Resource Group | 1-80 | Case insensitive | Alphanumeric, hyphen, underscore, and period | <service or role>-agw |
profx-agw |
| Traffic Manager Profile | Resource Group | 1-63 | Case insensitive | Alphanumeric, hyphen, and period | <descriptive context> |
app1 |
The Azure Resource Manager supports tagging entities with arbitrary
text strings to identify context and streamline automation. For example, the tag "sqlVersion: "sql2014ee" could identify VMs in a deployment running SQL Server 2014 Enterprise Edition for running an automated script against them. Tags should be used to augment and enhance context along side of the naming conventions chosen.
Tip
One other advantage of tags is that tags span resource groups, allowing you to link and correlate entities across disparate deployments.
Each resource or resource group can have a maximum of 15 tags. The tag name is limited to 512 characters, and the tag value is limited to 256 characters.
For more information on resource tagging, refer to Using tags to organize your Azure resources.
Some of the common tagging use cases are:
- Billing; Grouping resources and associating them with billing or charge back codes.
- Service Context Identification; Identify groups of resources across Resource Groups for common operations and grouping
- Access Control and Security Context; Administrative role identification based on portfolio, system, service, app, instance, etc.
Tip
Tag early - tag often. Better to have a baseline tagging scheme in place and adjust over time rather than having to retrofit after the fact.
An example of some common tagging approaches:
| Tag Name | Key | Example | Comment |
|---|---|---|---|
| Bill To / Internal Chargeback ID | billTo | IT-Chargeback-1234 |
An internal I/O or billing code |
| Operator or Directly Responsible Individual (DRI) | managedBy | [email protected] |
Alias or email address |
| Project Name | projectName | myproject |
Name of the project or product line |
| Project Version | projectVersion | 3.4 |
Version of the project or product line |
| Environment | environment | <Production, Staging, QA > |
Environmental identifier |
| Tier | tier | Front End, Back End, Data |
Tier or role/context identification |
| Data Profile | dataProfile | Public, Confidential, Restricted, Internal |
Sensitivity of data stored in the resource |
Some types of resources may require additional care on naming and conventions.
Especially in larger topologies, carefully naming virtual machines streamlines identifying the role and purpose of each machine, and enabling more predictable scripting.
There are two primary use cases for storage accounts - backing disks for VMs, and storing data in blobs, queues and tables. Storage accounts used for VM disks should follow the naming convention of associating them with the parent VM name (and with the potential need for multiple storage accounts for high-end VM SKUs, also apply a number suffix).
Tip
Storage accounts - whether for data or disks - should follow a naming convention that allows for multiple storage accounts to be leveraged (i.e. always using a numeric suffix).
It's possible to configure a custom domain name for accessing blob data in your Azure Storage account. The default endpoint for the Blob service is https://.blob.core.windows.net`.
But if you map a custom domain (such as www.contoso.com) to the blob endpoint for your storage account, you can also access blob data in your storage account by using that domain. For example, with a custom domain name, http://mystorage.blob.core.windows.net/mycontainer/myblob could be accessed as
http://www.contoso.com/mycontainer/myblob.
For more information about configuring this feature, refer to Configure a custom domain name for your Blob storage endpoint.
For more information on naming blobs, containers and tables, refer to the following list:
A blob name can contain any combination of characters, but reserved URL characters must be properly escaped. Avoid blob names that end with a period (.), a forward slash (/), or a sequence or combination of the two. By convention, the forward slash is the virtual directory separator. Do not use a backward slash (\) in a blob name. The client APIs may allow it, but then fail to hash properly, and the signatures will not match.
It is not possible to modify the name of a storage account or container after it has been created. If you want to use a new name, you must delete it and create a new one.
Tip
We recommend that you establish a naming convention for all storage accounts and types before embarking on the development of a new service or application.