Skip to main content

Azure naming convention

Naming components​

  1. Resource type: An abbreviation that represents the type of Azure resource or asset. It is recommended to use the official abbreviation recommendations for Azure resources.

  2. Workload, application, or project: The name of the workload, application, or project that the resource is part of.

  3. Environment: The stage of the lifecycle for the workload that the resource supports, for example:

    • dev for Development
    • stg for Staging
    • prod for Production

    In case we use deployment slots for a given resource (this is possible for App Services and Azure Functions) we can keep the actual environment in the app name (e.g. func-test-function-prod-weu). This means that this resource and its deployment slots are intended for production usage. The slots can be named func-test-function-prod-weu/staging or even better func-test-function-prod-weu/preprod. The resource should be named func-test-function-stg-weu, only if its whole lifecycle is in the staging stage.

  4. Region: A short abbreviation for the Azure region or cloud provider location where the resource is deployed (for example, weu for West Europe).

  5. (Optional) Instance: If there is already a resource with the same name, an instance number should be added at the end, the padding convention is a fixed length of 3 (e.g. 001, 042, 101).

Naming convention pattern​

Resources​

When naming an Azure resource, use the following convention as closely as possible. The name has the 4 (or 5) basic components in kebab-case with the exact above order, all lowercase, separated by hyphens (-).

The general pattern is:

<resource-type>-<workload-or-project>-<environment>-<region>(-<instance>)

The instance segment is optional and only used when needed.

Storage accounts​

Storage accounts have the peculiarity of using just lowercase alphanumeric case so we still have to follow the resources rule without hyphens.

<resource-type><workloadorproject><environment><region>(<instance>)

Resource groups​

Resource groups should follow the same pattern as resources.

rg-<workload-or-project>-<environment>-<region>(-<instance>)

Tagging strategy​

Complementary to the naming convention a tagging strategy should be followed as well, to better filter services mainly for cost management.

The required tags are the following:

  1. businessname: A human-readable form of the name (e.g. Third Party Message Receiver).
  2. solutionname: The corresponding solution project (e.g. People.IoT.MessageReceiver). If there is no such project leave it empty.
  3. app: The application that it is part of.
  4. environment: The lifecycle stage.
  5. owner: The owner who is primarily the creator and main contributor (e.g. Konstantinos Ioannou). They can change in the future.
  6. team: The development team responsible (e.g. tms-ai).
  7. user: (Optional) Used for Virtual Machine resources for us to know which is the root user assigned.

Make sure that the values of these fields are consistent, because even minor deviations can defeat the purpose of tagging.

Example​

You want to deploy an Azure Container Apps resource for the TMS application that hosts a service called "routing". The environment is production and the region is West Europe.

  1. Azure Container Apps is abbreviated to ca as the Azure resource abbreviation recommendations.
  2. The workload/application name combines tms and the service name routing, resulting in tms-routing.
  3. The environment code is prod for Production.
  4. The region abbreviation is weu for West Europe.

Putting this together, the name is:

ca-tms-routing-prod-weu

If this name is already a resource with the same name, use an instance number:

ca-tms-routing-prod-weu-001

The tags are: businessname: TMS AI Routing Service, solutionname: /tms/routing/, app: tms, environment: prod, owner: georgios frangias, team: ai

Sources​

It is highly recommended you check in detail Azure's own manual on defining a naming convention. The pages from which these naming conventions are mainly drawn are the following:

  1. Define your naming convention - Cloud Adoption Framework | Microsoft Learn

  2. Abbreviation recommendations for Azure resources - Cloud Adoption Framework | Microsoft Learn