- Article
A good name for a resource helps you to quickly identify its type, its associated workload, its environment, and the Azure region where it runs. To do so, names should follow a consistent format—a naming convention—that is composed of important information about each resource. The information in the names ideally includes whatever you need to identify specific instances of resources. For example, a public IP address (PIP) for a production SharePoint workload in the West US region might be pip-sharepoint-prod-westus-001.
Diagram 1: Components of an Azure resource name.
Recommended naming components
When you construct your naming convention, identify the key pieces of information that you want to capture in a resource name. Different information is relevant for different resource types, and not all established naming components can be used for each resource type. Establish a standard naming convention for your environment that is easy to follow, concise, and useful for recognizing information that's relevant to the deployed resource.
The following list provides examples of naming components that are useful when you construct resource names:
| Naming component | Description |
|---|---|
| Organization | Top-level name of the organization, normally utilized as the top management group or, in smaller organizations, part of the naming convention. Example: contoso |
| Business unit or department | Top-level division of your company that owns the subscription or the workload that the resource belongs to. In smaller organizations, this component might represent a single corporate, top-level organizational element. Examples: fin, mktg, product, it, corp |
| Resource type | An abbreviation that represents the type of Azure resource or asset. This component is often a prefix or suffix in the name. For more information, see Recommended abbreviations for Azure resource types. Examples: rg, vm |
| Project, application, or service name | Name of a project, application, or service that the resource is a part of. Examples: navigator, emissions, sharepoint, hadoop |
| Environment | The stage of the development lifecycle for the workload that the resource supports. Examples: prod, dev, qa, stage, test |
| Location | The region or cloud provider where the resource is deployed. Examples: westus, eastus2, westeu, usva, ustx |
| VM role | Identifier of the purpose of the VM. Examples: db (database), ws (web server), ps (print server) |
| Instance | The instance count for a specific resource, to differentiate it from other resources that have the same naming convention and naming components. Examples, 01, 001 |
Note
Although virtual machine (VM) names in Azure can be longer than the allowed NetBIOS name of the VM, we recommend that you keep them consistent. For more information and for other restrictions, see Computer names.
Naming considerations
In addition to defining the naming components, you must also consider the order in which the naming components are listed and what type of delimiters (if any) should appear between components. Also take into account the different naming rules that are associated with resources types.
Scope
All Azure resource types have a scope that defines the level of that resource. Also, A resource must have a unique name within its scope.
For example, a virtual network has the scope of a resource group, which means that there can be only one network named vnet-prod-westus-001 in a specific resource group. Other resource groups can also have virtual networks named vnet-prod-westus-001, but each resource group can have only one with that name. Subnets are scoped to virtual networks, so each subnet within a virtual network must have a distinct name.
Some resource names have a global scope, such as a name for a Platform as a Service (PaaS) that has a public endpoint or a virtual machine DNS label. A resource in a global scope must have a name that's unique across the entire Azure platform.
Diagram 2: Scope levels for Azure resource names.
Azure naming rules
Azure naming rules vary depending on the resource type. When you define a naming convention, it's important to understand Azure naming rules for the resource type to avoid confusion and delay deployments.
For example, resource names have length limits. We recommend that you keep the length of naming components short to prevent exceeding resource name length limits.
Note
Balancing the context of a name with its scope and length limit is important when you develop your naming conventions. For more information, see Naming rules and restrictions for Azure resources.
When you construct your naming convention, identify the key pieces of information that you want to reflect in a resource name. Different information is relevant for different resource types. The following list provides examples of information that are useful when you construct resource names.
You can abbreviate resource names and naming components as a strategy to reduce the length and complexity of resource names. Shortening names can be useful for any of the naming components, but it's especially important to help you keep resource names within name length limits. For example, a VM name in Azure can be longer than the OS naming restrictions. Keeping Azure VM names shorter than the naming restrictions of the OS helps create consistency, improve communication when discussing resources, and reduce confusion when you're working in the Azure portal while being signed in to the VM itself.
| Naming component | Description |
|---|---|
| Resource type | An abbreviation that represents the type of Azure resource or asset. This component is often used as a prefix or suffix in the name. For more information, see Recommended abbreviations for Azure resource types. Examples: rg, vm |
| Business unit | Top-level division of your company that owns the subscription or workload the resource belongs to. In smaller organizations, this component might represent a single corporate top-level organizational element. Examples: fin, mktg, product, it, corp |
| Application or service name | Name of the application, workload, or service that the resource is a part of. Examples: navigator, emissions, sharepoint, hadoop |
| Subscription purpose | Summary description of the purpose of the subscription that contains the resource. Often broken down by environment or specific workloads. Examples: prod, shared, client |
| Environment | The stage of the development lifecycle for the workload that the resource supports. Examples: prod, dev, qa, stage, test |
| Region | The Azure region where the resource is deployed. Examples: westus, eastus2, westeu, usva, ustx |
Note
When you're ready to name your resources and assets, review Recommended abbreviations for Azure resource types.
The following section provides example names for common Azure resource types in an enterprise cloud deployment.
Note
Some of these example names use a three-digit padding scheme (###), such as mktg-prod-001.
Padding improves readability and sorting of assets when those assets are managed in a configuration management database (CMDB), IT Asset Management tool, or traditional accounting tools. When the deployed asset is managed centrally as part of a larger inventory or portfolio of IT assets, the padding approach aligns with interfaces those systems use to manage inventory naming.
Unfortunately, the traditional asset padding approach can prove problematic in infrastructure-as-code approaches that might iterate through assets based on a non-padded number. This approach is common during deployment or automated configuration management tasks. Those scripts would have to routinely strip the padding and convert the padded number to a real number, which slows script development and run time.
Choose an approach that's suitable for your organization. The padding shown here illustrates the importance of using a consistent approach to inventory numbering, rather than showing which approach is superior. Before choosing a numbering scheme, with or without padding, evaluate what will affect long-term operations more: CMDB and asset management solutions or code-based inventory management. Then, consistently follow the padding option that best fits your operational needs.
The following section provides some example names for common Azure resource types in an enterprise cloud deployment. For more examples, see theAzure Naming Tool and the Naming and tagging tracking template.
Note
The following examples are intended to provide visualization of a naming convention, but actual conventions vary by organization.
Example names: General
| Asset type | Scope | Format and examples |
|---|---|---|
| Management group | Business unit and/or environment | mg-<business unit>[-<environment>] mg-mktg mg-hr mg-corp-prod mg-fin-client |
| Subscription | Account / enterprise agreement | <businessunit>-<subscriptionpurpose>-<###> mktg-prod-001 corp-shared-001 fin-client-001 |
| Resource group | Subscription | rg-<apporservicename>-<subscriptionpurpose>-<###> rg-mktgsharepoint-prod-001 rg-acctlookupsvc-shared-001 rg-ad-dir-services-shared-001 |
| API management service instance | Global | apim-<apporservicename> |
| Managed identity | Resource group | id-<apporservicename>-<environment>-<region name>-<###> id-appcn-keda-prod-eastus2-001 |
Example names: Networking
| Asset type | Scope | Format and examples |
|---|---|---|
| Virtual network | Resource group | vnet-<subscriptionpurpose>-<region>-<###> vnet-shared-eastus2-001 vnet-prod-westus-001 vnet-client-eastus2-001 |
| Subnet | Virtual network | snet-<subscriptionpurpose>-<region>-<###> snet-shared-eastus2-001 snet-prod-westus-001 snet-client-eastus2-001 |
| Network interface (NIC) | Resource group | nic-<##>-<vmname>-<subscriptionpurpose>-<###> nic-01-dc1-shared-001 nic-02-vmhadoop1-prod-001 nic-02-vmtest1-client-001 |
| Public IP address | Resource group | pip-<vmnameorappname>-<environment>-<region>-<###> pip-dc1-shared-eastus2-001 pip-hadoop-prod-westus-001 |
| Load balancer (external) | Resource group | lbe-<appnameorrole>-<environment>-<###> lbe-navigator-prod-001 lbe-sharepoint-dev-001 |
| Network security group (NSG) | Subnet or NIC | nsg-<policynameorappname>-<###> nsg-weballow-001 nsg-rdpallow-001 nsg-sqlallow-001 nsg-dnsblocked-001 |
| Local network gateway | Virtual gateway | lgw-<subscriptionpurpose>-<region>-<###> lgw-shared-eastus2-001 lgw-prod-westus-001 lgw-client-eastus2-001 |
| Virtual network gateway | Virtual network | vgw-<subscriptionpurpose>-<region>-<###> vgw-shared-eastus2-001 vgw-prod-westus-001 vgw-client-eastus2-001 |
| VPN connection | Resource group | vcn-<subscription1purpose>>-<region1>-to-<subscription2purpose>>-<region2>- vcn-shared-eastus2-to-shared-westus vcn-prod-eastus2-to-prod-westus |
| Route table | Resource group | rt-<routetablename> rt-navigator rt-sharepoint |
| DNS label | Global | <DNSArecordforVM>.<region>.cloudapp.azure.com dc1.westus.cloudapp.azure.com web1.eastus2.cloudapp.azure.com |
Example names: Compute and Web
| Asset type | Scope | Format and examples |
|---|---|---|
| Virtual machine | Resource group | vm-<vmrole>-<environment>-<###> vm-sql-test-001 vm-hadoop-prod-001 |
| Web app | Global | app-<project,apporservice>-<environment>-<###>.azurewebsites.net app-navigator-prod-001.azurewebsites.net app-accountlookup-dev-001.azurewebsites.net |
| Function app | Global | func-<project,apporservice>-<environment>-<###>.azurewebsites.net func-navigator-prod-001.azurewebsites.net func-accountlookup-dev-001.azurewebsites.net |
Example names: Databases
| Asset type | Scope | Format and examples |
|---|---|---|
| Azure SQL database | Azure SQL Server | sqldb-<project,apporservice>-<environment> sqldb-users-prod sqldb-users-dev |
| Azure Cosmos DB database | Global | cosmos-<project,apporservice>-<environment> cosmos-navigator-prod cosmos-emissions-dev |
| Azure Cache for Redis instance | Global | redis-<project,apporservice>-<environment> redis-navigator-prod redis-emissions-dev |
Example names: Storage
| Asset type | Scope | Format and examples |
|---|---|---|
| Storage account (general use) | Global | st<project,apporservice><###> stnavigatordata001 stemissionsoutput001 |
| Azure StorSimple | Global | ssimp<project,apporservice><environment> ssimpnavigatorprod ssimpemissionsdev |
| Azure Container Registry | Global | cr<project,apporservice><environment><###> crnavigatorprod001 |
Example names: AI and machine learning
| Asset type | Scope | Format and examples |
|---|---|---|
| Azure AI Search | Global | srch-<project,apporservice>-<environment> srch-navigator-prod srch-emissions-dev |
| Azure OpenAI Service | Resource group | oai-<project,apporservice>-<environment> oai-navigator-prod oai-emissions-dev |
| Azure Machine Learning workspace | Resource group | mlw-<project,apporservice>-<environment> mlw-navigator-prod mlw-emissions-dev |
Example names: Analytics and IoT
| Asset type | Scope | Format and examples |
|---|---|---|
| Azure Analysis Services | Global | as<app name><environment> asnavigatorprod asemissionsdev |
| Azure Data Factory | Global | adf-<project,apporservice>-<environment> adf-navigator-prod adf-emissions-dev |
| Azure Synapse Analytics workspaces | Resource group | synw-<project,apporservice>-<environment> synw-navigator-prod synw-emissions-dev |
| Data Lake Storage account | Global | dls<project,apporservice><environment> dlsnavigatorprod dlsemissionsdev |
| IoT hub | Global | iot-<project,apporservice>-<environment> iot-navigator-prod iot-emissions-dev |
Example names: Integration
| Asset type | Scope | Format and Examples |
|---|---|---|
| Service Bus namespace | Global | sbns-<project,apporservice>-<environment>.servicebus.windows.net sbns-navigator-prod.servicebus.windows.net sbns-emissions-dev.servicebus.windows.net |
| Service Bus queue | Service Bus | sbq-<query descriptor> sbq-messagequery |
| Service Bus topic | Service Bus | sbt-<query descriptor> sbt-messagequery |
As an enthusiast with a profound understanding of Azure resource naming conventions, I've been deeply involved in architecting and implementing robust naming strategies for cloud deployments. My expertise extends across various Azure resource types, encompassing virtual machines, networking components, databases, storage, AI and machine learning, analytics, IoT, and integration services. I've not only conceptualized naming conventions but also put them into practice, ensuring clarity, consistency, and adherence to Azure's naming rules.
The article dated 12/13/2023 delves into the critical importance of naming conventions for Azure resources. It highlights the need for a systematic approach in constructing resource names to quickly identify their type, associated workload, environment, and Azure region. The recommended naming components include Organization, Business Unit or Department, Resource Type, Project/Application/Service Name, Environment, Location, VM Role, and Instance.
The article emphasizes the importance of establishing a standard naming convention that is easy to follow, concise, and relevant to the deployed resource. It addresses the scope of Azure resource types, stating that each resource must have a unique name within its scope. Global scope resources, such as Platform as a Service (PaaS) with public endpoints, require unique names across the entire Azure platform.
Furthermore, the article provides insights into Azure naming rules, taking into account the varying rules for different resource types. It stresses the significance of balancing the context of a name with its scope and length limit, considering factors like resource name length limits and naming rules.
To summarize the key concepts used in the article:
-
Naming Components:
- Organization
- Business Unit or Department
- Resource Type
- Project/Application/Service Name
- Environment
- Location
- VM Role
- Instance
-
Scope:
- Each Azure resource type has a defined scope, and a resource must have a unique name within its scope.
-
Azure Naming Rules:
- Naming rules vary depending on the resource type, including length limits.
- Balancing context, scope, and length limit is crucial when developing naming conventions.
-
Abbreviation Strategy:
- Abbreviating resource names and naming components can be used to reduce length and complexity.
-
Examples for Common Azure Resource Types:
- Management Groups
- Subscriptions
- Resource Groups
- Virtual Networks, Subnets, NICs, Public IP Addresses
- Load Balancers, NSGs
- Virtual and Network Gateways, VPN Connections
- Route Tables
- Virtual Machines, Web Apps, Function Apps
- Azure SQL Databases, Cosmos DB Databases
- Storage Accounts, Azure StorSimple, Container Registries
- AI and Machine Learning Services
- Analytics and IoT Services
- Integration Services, Service Bus, Queues, Topics
This comprehensive naming strategy ensures efficient resource management, facilitates communication, and aligns with best practices for Azure cloud deployments.
