Custom Azure Naming Conventions: Reordering CAF for Your Team

Microsoft’s Cloud Adoption Framework popularized the order type-workload-environment-region-instance, but it is a recommendation, not a rule. You can put the workload first, the type at the end, or drop components you don’t use. The only hard requirements are that your whole estate stays consistent and that you never break Azure’s real per-resource limits on length and characters.

Every team that adopts Azure eventually hits the same debate: do we follow Microsoft’s naming convention exactly, or adapt it to how we work? The good news is that adapting it is not only allowed, it is expected. CAF is a starting point, and the framework itself says to evaluate it against your organization’s needs. This guide covers what you can safely change, what you must never touch, and how to keep a custom convention from turning into chaos.

What CAF actually mandates: almost nothing

CAF is guidance. Azure itself enforces none of the CAF ordering. When you deploy a resource, Azure checks two things: does the name fit the length limit, and does it use only allowed characters. It does not care whether the type abbreviation comes first, last, or not at all. The component order is entirely yours to decide.

What Azure does enforce, and no convention can override:

• Length limits, storage account 24, Key Vault 24, Windows VM computer name 15, and so on
• Allowed characters, lowercase-only for storage accounts, no hyphens for container registries
• Global uniqueness for DNS-backed names like storage accounts, Key Vaults, App Services, and SQL servers

Get creative with the order. Never get creative with these.

The three common orderings

Type first (the CAF default)

kv-payments-prod-eus-001

Groups resources by kind. Every Key Vault starts with kv, so a sorted list clusters all vaults together. This shines anywhere without a filter UI: raw CLI output, terraform state list, cost exports, grep. Because the Azure portal already lets you filter by resource type, the type prefix earns a little less than people assume, but it is still the most portable choice.

Workload first

payments-prod-eus-kv-001

Groups everything for an application together. Sort a resource list and all of payments sits in one block regardless of resource type. This suits teams organized by application or product rather than by infrastructure layer.

Type last

payments-prod-eus-kv-001

A variant of workload-first that keeps the type as a readable suffix. Some engineers find a trailing -kv easier to scan than a leading one, especially in the portal where the workload is what they are looking for first.

The real question: who reads the names, and how?

There is no universally correct order, only the right order for your primary consumer:

• Reading raw CLI or terraform state list output? Type-first groups related resources.
• Living in the portal, which already filters by type? Workload-first keeps an app together.
• Feeding cost exports into a spreadsheet and pivoting by application? Workload-first.
• Grepping logs and pipelines? Whatever prefix you search on most.

Think about who looks at these names and how they look at them, then optimize for that. An old inventory-system mindset, where the identifier front-loads the item type, is not always the best fit for cloud resources that different people consume in different tools.

What else you can customize

Environment abbreviations. prod or prd, stage or stg. Pick one form and never mix them. See the naming mistakes guide for why mixed abbreviations quietly break automation.

Optional components. Company and department are extensions for larger organizations that namespace across business units. A single-team startup can drop them; a multi-business-unit enterprise needs them.

Region format. Full IDs like eastus when names have room, short codes like eus when they don’t. The region abbreviations list covers both.

What you should not customize

Consistency is the entire point, so hold these fixed once chosen:

• The order. Mixing kv-payments and payments-kv in the same estate defeats every benefit of having a convention at all.
• The abbreviation set. One prod, not three variants scattered across teams.
• The separator. A hyphen everywhere it is allowed, concatenation only where the resource forbids hyphens.

A custom convention that everyone follows beats the textbook CAF convention that half the team ignores.

Making a custom convention stick

1. Document it once, with examples, somewhere people actually read: a repo README or the team wiki.
2. Parameterize it in IaC so the pattern lives in one shared locals or variables block, not copy-pasted per resource.
3. Generate names from a tool rather than by hand, so the order and abbreviations are applied identically every time.

Decide early

Like most naming decisions, the order is expensive to change after deployment because most Azure resources cannot be renamed. Choose your convention before the first terraform apply, not after you have 300 resources locked into the old scheme.

Summary

• CAF order is a default; the component order is yours to choose
• Optimize the order for whoever reads the names most
• Never customize Azure’s real length, character, or uniqueness rules
• Consistency beats correctness: document and enforce one scheme

AzureNamer generates the CAF order by default and lets you reorder the components and change the environment abbreviations to match your team’s convention. Your custom convention is saved in your browser and travels in the share link, so you can send your whole team one URL that produces names in your house style. See the complete CAF guide for the standard order it starts from.