I'm fairly new to Azure and am trying to make sense of the many resource types and services. In on-premises environments, I usually named systems based on their location, whether they were physical or virtual, and their role. What naming pattern do you use for Azure resources so they remain clear, consistent, and easy to document?
4 Answers
A hybrid approach is usually the most practical: combine your organization’s existing naming standards with Azure’s Cloud Adoption Framework recommendations. Keep the name focused on information people regularly need when searching or troubleshooting, and use tags for metadata such as owner, department, cost center, data classification, and lifecycle. Also check each service’s length, character, and uniqueness requirements before finalizing the pattern.
We use company-system-location-environment-resource. For example, an ordering application might have names like acme-order-uscentral-prd-rg, acme-order-uscentral-prd-cosmos, and acme-order-uscentral-prd-appsvc. A defined pattern makes infrastructure-as-code and deployment pipelines more consistent, and it helps people understand resources at a glance in the portal.
A simple pattern that works well is resource type, application, environment, location, and instance number. For example: afw-hub-prod-uks-01. Keeping the abbreviations short and consistent makes resource lists much easier to scan. A maintained Azure resource abbreviation reference can also help keep the team aligned.
That kind of reference is useful, although it may not cover every newer resource type, so I’d keep an internal list and update it as needed.
A good starting point is Microsoft’s Cloud Adoption Framework guidance for Azure naming conventions and resource abbreviations. It covers common components such as resource type, workload, environment, region, and instance number. Treat it as a baseline, though—some services have special naming rules, and certain names become part of globally unique hostnames, so copying one template everywhere can cause problems.
Exactly. I’d use the framework as a reference rather than a strict formula, especially for services with globally unique names or hostname restrictions.
We use a similar structure, but leave out parts that are already obvious from the resource group. We put ownership, cost center, and other less-visible details in tags instead of making names unnecessarily long.