Azure Naming Conventions: The Complete CAF Guide (2026)

The CAF naming pattern is {type}-{workload}-{environment}-{region}-{instance}, for example kv-payments-prod-eus-001. Lead with the resource type abbreviation, separate components with hyphens (except where a resource forbids them, like storage accounts), and design around the tightest length limits you will hit.

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, standardized names make auditing and access reviews far easier
• 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.

The type prefix comes from Microsoft’s official abbreviation list. The abbreviations cheat sheet covers all 200+ resource types in one searchable table.

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.

CAF popularized this order, but it isn’t mandatory. Some teams prefer the workload first, so everything for an application groups together, or the type at the end. What matters most is that the whole estate stays consistent. See custom Azure naming conventions for the tradeoffs between orderings. AzureNamer generates the CAF order by default and lets you reorder the components to match your team’s convention.

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. The complete region abbreviations list covers all 40 regions and the common variants.

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	vm	64	Alphanumerics + hyphens
AKS Cluster	aks	63	Alphanumerics + hyphens
Resource Group	rg	90	Alphanumerics + hyphens + underscores
App Service	app	60	Alphanumerics + hyphens

One frequent misconception: Windows VMs are not limited to 15 characters. That cap applies to the computer name inside the OS, while the VM resource name allows 64. The VM naming guide covers how to handle both.

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 200+ 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 exports the full set as CSV or as ready-made Terraform and Bicep, exact names or a variable-driven file for all your environments.

Try AzureNamer →