Azure Naming Conventions: The Complete CAF Guide (2026)

Inconsistent Azure resource names are more than an aesthetic problem. They make automation scripts brittle, dashboards confusing, and cost reports impossible to filter by workload. Microsoft’s Cloud Adoption Framework (CAF) addresses this with a structured naming standard — and it’s the closest thing the Azure ecosystem has to an official convention.

This guide covers the full CAF naming standard: its components, ordering rules, character restrictions, and real examples you can use today.

Why naming conventions matter

Once an Azure resource is deployed, most names cannot be changed. A Storage Account named mystorageaccount123 is stuck that way — renaming it means deleting and recreating it, which means downtime and data migration. Getting naming right before deployment is far cheaper than fixing it later.

Beyond immutability, consistent names enable:

Cost allocation — filter by workload or environment in Cost Management
Automation — scripts and pipelines can derive names programmatically
Governance — Azure Policy can enforce naming patterns
Onboarding — new team members can infer what a resource is from its name alone

The CAF naming components

CAF defines five standard components that combine to form a resource name:

Component	Description	Example
Resource type	CAF abbreviation for the service	`kv`, `st`, `aks`
Workload / Application	The system or app this resource serves	`payments`, `api`
Environment	Deployment environment	`prod`, `dev`, `stg`
Azure region	Where the resource is deployed	`eus`, `weu`
Instance	Differentiates multiple identical resources	`001`, `002`

CAF intentionally keeps the component list short. Two additional components — company and department — are common extensions for larger organisations that need to namespace resources across business units.

Component order and separator

The recommended order is:

{type}-{workload}-{environment}-{region}-{instance}

With company and department added:

{type}-{company}-{department}-{workload}-{environment}-{region}-{instance}

The separator is a hyphen (-) for most resources. Some resource types (Storage Accounts, for example) don’t allow hyphens — in those cases, components are concatenated directly.

Environment abbreviations

CAF doesn’t mandate specific abbreviations but community consensus has settled on:

Environment	Abbreviation
Production	`prod`
Development	`dev`
Staging	`stg`
Test	`test`
UAT	`uat`
QA	`qa`

Region abbreviations

CAF uses full region names in its official documentation (eastus, westeurope), but practitioners almost universally shorten them to save characters — especially important for resources with tight length limits. Common community abbreviations:

Region	Abbreviation
East US	`eus`
East US 2	`eus2`
West US	`wus`
West Europe	`weu`
North Europe	`neu`
UK South	`uks`
Southeast Asia	`sea`
Australia East	`aue`

When characters are tight, the abbreviated form is preferred. When names have room, full region names (eastus) are unambiguous and match what the Azure portal shows.

Character rules and length limits

Every Azure resource type has its own rules. The most common restrictions:

Resource type	Abbreviation	Max length	Characters allowed
Key Vault	`kv`	24	Alphanumerics + hyphens
Storage Account	`st`	24	Lowercase alphanumerics only
Virtual Machine (Windows)	`vm`	15	Alphanumerics + hyphens
AKS Cluster	`aks`	63	Alphanumerics + hyphens
Resource Group	`rg`	90	Alphanumerics + hyphens + underscores
App Service	`app`	60	Alphanumerics + hyphens

The 24-character limits on Key Vault and Storage Account are the most common pain points. A name like kv-contoso-payments-prod-eus-001 is 32 characters — over the limit. The solution is to drop lower-priority components: remove department, then company, then shorten the workload until it fits.

Real naming examples

Assuming: company contoso, workload payments, environment prod, region eus, instance 001:

Resource	Generated name
Resource Group	`rg-contoso-payments-prod-eus-001`
Key Vault	`kv-contoso-payments-prod-001`
Storage Account	`stcontosopaymentsprod001`
AKS Cluster	`aks-contoso-payments-prod-eus-001`
App Service	`app-contoso-payments-prod-eus-001`
SQL Server	`sql-contoso-payments-prod-eus-001`
Virtual Network	`vnet-contoso-payments-prod-eus-001`

Notice that Key Vault dropped the region to fit within 24 characters, and Storage Account has no hyphens and is all lowercase.

Common mistakes

Using free-form descriptions instead of abbreviations. Names like production-key-vault-for-payments are longer, inconsistent, and don’t sort well. Use the CAF abbreviation as the type prefix.

Ignoring length limits until deployment. A naming template that works for most resources will break on Storage Accounts and Key Vaults. Design for the tightest limits first.

Mixing conventions across teams. Half the organisation uses prod and the other half uses prd. Standardise environment abbreviations in a document before deploying anything.

Not including instance numbers. Even if you only expect one instance, adding 001 now means you never need to rename when a second one appears.

Using a generator

Tracking 203 resource type rules manually is impractical. AzureNamer generates CAF-compliant names for all Azure resource types, applies smart truncation when length limits are hit, and lets you export a full list as CSV.

Try AzureNamer →