Azure Resource Naming Convention: Strategies and Examples

Microsoft Azure is one of the leading cloud providers in the world. Organizations using Azure often create different types of resources to manage their workloads. Applying uniform and scalable naming standards to identify essential resource metadata, like region, environment, business unit, etc., is crucial. Having a resource naming convention also helps programmatically generate names for deploying resources in bulk. This article covers some of the points you should consider when designing and implementing resource naming conventions.

Summary of Azure resource naming convention best practices

The table below summarizes the Azure resource naming convention strategies for all types of organizations.

How should you name your Azure resources?

You should use resource names to store vital information about a resource so users can quickly identify a resource’s where/what/who/how questions. For example,

• Where is it being used? Environment- Dev, UAT, Production, etc.
• What type of resource is it? Workload type- VM, Database, VNet, etc. 
• What is it being used for? Use case- API, Automated Job, Logging, etc.
• Who owns it? Business unit- HR, Finance, IT, etc.
• How critical is it? Criticality- High, Medium, Low, etc.

Identify information that needs to be part of a resource name

Different organizations have different structures and practices. A good resource naming convention doesn’t mean the one that large tech giant companies are using, but that fits all of your organization’s use cases. A combination of necessary technical and operational information in a resource name has more impact.

After identifying the pieces of information, arrange them to make it simpler to sort and group them. A good order is to start from the left and move towards the right with the increasing uniqueness of the information piece. Something expected, like a business unit, would be the first piece, and the last would be something unique, like a unique sequence of characters, instance count, or anything which adds uniqueness to the resource name. 

Note: If infrastructure deployment is closely linked with continuous deployments, consider using instance count instead of random characters at the end of resource names. Using random characters will lead to the provisioning of duplicate resources with each deployment. To prevent this, ensure your deployment pipelines have appropriate checks in place.

Define standard resource prefixes and document them

Once you identify the information you want in the name, you can determine relevant abbreviations for practicality. These abbreviations need to be agreed upon or enforced upon all the teams which provision resources to meet organizational standards. Document the final list of agreed abbreviations to align all the teams. For example, if a virtual machine resource needs to be named, it should have “VM” as a workload identifier for all the teams.

Microsoft has an excellent document for abbreviations of resource types. To prepare a similar document for your organization’s abbreviations of operations-specific terms, consider the following, 

• Keep the abbreviations as short as possible to avoid resource name length limits. 
• Make the document easily accessible for the development and admin teams to have the same source of truth for collecting information while naming a resource.

Consider resource name limitations

Different types of resources in Azure have different sets of allowed characters in their names. You can find the entire list of naming rules for all resources here- Naming rules and restrictions for Azure resources. Understanding the rules relevant to resource usage are essential, as having a good naming convention doesn’t necessarily mean it works in Azure. Resource names need to be unique within their respective scopes. For example, a global scope means that the resource name needs to be unique within Microsoft Azure. If you miss these considerations during design, it could cause errors during deployment. Examples of such limitations include:

• Storage account names can only have lowercase letters and numbers up to 3-24 characters.
• Key Vault secrets can have up to 127 alphanumeric and hyphens.
• Azure Container Instances can only have lowercase letters, numbers, and hyphens, but consecutive hyphens are not allowed.

Examples of Azure resource naming conventions

Based on the points above, here are some examples-

• Single tenant setup with different business units- <Business Unit>-<Environment>-<Region>-<Resource Type>-<Workload>-<Instance Count/Random Characters>
  • VM-hr-dev-usw-vm-job-terklo
  • Storage Account-finproduswstjob001

• Single tenant setup with criticality- <Business Unit>-<Criticality>-<Environment>-<Region>-<Resource Type>-<Workload>-<Instance Count/Random Characters> (1=High, 2=Medium, 3=Low)
  • AKS cluster-hr-1-prod-neu-aks-ws-asdzxc
  • Azure Data Factory-fin-2-uat-neu-adf-ingest-001

• Multi-tenant setup- <Tenant Name>-<Environment>-<Region>-<Resource Type>-<Workload>-<Instance Count/Random Characters> (Resources specific to a client “Contoso”)
  • Function App-cnts-prod-usw-func-api-lkjhgf
  • Azure SQL server-cnts-prod-usw-sql-dump-001

Best practices in Azure resource naming conventions 

Defining naming conventions alone is not enough. You need to enforce it systematically across your organization. The following best practices will help you get the most out of your Azure resource names.

#1 Define naming conventions in the design phase

One common mistake you should avoid is designing and introducing a naming convention during development. Developers are focused on building things and may miss the value of a good convention to the overall architecture.

Instead, you can define naming conventions during architecture design to ensure that the same naming standards are used across teams and departments. You can also design policies and automation for naming conventions while considering the limitations of each resource type. Architects also have a good idea of the solution at scale and can plan scalable naming conventions in advance.

Working on naming conventions during the design phase helps developers get a lead on setting up these things correctly. For example, before provisioning resources, they can 

• Define policy as code
• Ensure correct configurations
• Derive names automatically from resource type

#2 Implement policies to enforce Azure resource naming conventions

Policies help ensure all the resources comply with rules set by the organization for security and administration purposes. Tools like Azure Policy or Paladin Cloud scan all the resources against the defined policies and flag the non-compliant ones. 

While policies can be used to define and implement many different rules, it is vital to identify which team is responsible for checking naming conventions. Some teams use policies for focusing only on security configurations, and administrative rules like checking for naming conventions might be out of their scope as it could raise false alarms in their compliance reports. If resource names need to be checked as part of compliance, find out what makes a resource non-compliant. For example, the absence of region, environment, or criticality should be flagged as non-compliant.

Paladin Cloud is a great tool that works with Azure Policy to ensure best practices. Here is an elementary example of a Azure policy definition that ensures the name of a storage account always ends with “stg”. By creating a custom policy in Paladin Cloud monitoring of this naming policy can be extended to multiple cloud providers.

{
  "mode": "All",
  "policyRule": {
    "if": {
      "allOf": [
        {
          "field": "type",
          "equals": "Microsoft.Storage/storageAccounts"
        },
        {
          "field": "name",
          "notLike": "*stg"
        }
      ]
    },
    "then": {
      "effect": "deny"
    }
  },
  "parameters": {}
}

A policy definition enforcing storage account names to end with “stg”

#3 Use tools to generate names

Azure resource naming conventions are complex, and it can be challenging to incorporate them uniformly. Instead, you should consider tools like Microsoft’s AzNamingTool, which is open-source, freely available, and easy to install. Admins use the tool to:

• Configure components and their orders.
• Configure allowed/disallowed values in different components.
• Reduce overheads of checking limitations of different resource types, as the generated names always align with Azure’s limitations.

The tool also exposes API endpoints to integrate name generation into your automation. Pass the response from these endpoints as inputs to Infrastructure As Code (IaC) pipelines. Incorporating IaC with resource name generation supports end-to-end automation of resource provisioning while ensuring organizational and industrial best practices.

Components and their order can be configured in AzNamingTool (Source)

How do resource tags fit into the Azure resource naming conventions?

Names contain information that makes a resource easily identifiable. But tags contain information that adds value to operations teams. You can extract desired resources by filtering them based on tags. The combination of tags and names holds vital information about the resource, which is useful during an incident. Operations and security teams can gather maximum information and focus on remediation—resolving incidents faster. 

Example of Azure resource naming conventions with tags

Let’s take an example of an incident about unusual costs incurred in a subscription. Each resource name contains a business unit code, and its tag includes the name of the focal point for that resource. So, suppose the admin team wants to find details of the resources affecting the high cost. In that case, the name can help isolate the scope of analysis to the specific business unit, and the tag can help them reach out to the respective focal point of the resource. If the admin team wants to ensure Dev/Test resources don’t add up to the high cost, they use an “Environment” tag to filter such resources and take quick action to remediate them.

Tools like Paladin Cloud add a great visualization layer on top of the power of tags by letting users create “Asset Groups.” Asset Groups are simply logical containers of resources having the same tag values—Paladin Cloud UI scopes to the specific asset group for better visibility.

Asset Groups in Paladin Cloud provide are a powerful way to group related resources. 

Conclusion

A logical Azure resource naming convention is essential as it impacts different teams like developers, security, and operations. It should add value to all these teams while ensuring it scales well with the entire architecture. You must define your naming rules from the start of your cloud project while considering the critical information your users require and Azure name limits. You systematically enforce naming policies using tools and documentation. Combining naming conventions with resource tags maximizes benefits by increasing resource filtering capabilities. Open source tools like AzNamingTool and Paladin Cloud can help you automate Azure naming convention implementation to get the most out of this strategy!