Azure Resource Naming Strategy
A CAF-aligned naming pattern for Azure resources — the component breakdown, a worked example, and the rules that keep it consistent as an environment grows.
A naming strategy is a documented, consistent pattern for naming every Azure resource, so anyone (or any script) can tell what a resource is, what it belongs to, and which environment it’s in, just by reading its name. Without one, subscriptions fill up with names like webapp1, prodDB, test-vm-final. That slows down troubleshooting, breaks any automation that relies on naming patterns, and risks collisions in Azure’s globally unique namespaces (storage accounts, Key Vaults, DNS labels). It matters even more once you’re running more than one workload through a shared subscription or landing zone, where resources from different projects need to be identifiable at a glance and never collide.
The pattern
<resource-type>-<workload>-<environment>-<region>-<instance>| Component | Purpose | Example values |
|---|---|---|
| Resource type | Standard Microsoft CAF abbreviation | rg, app, asp, sql, sqldb, kv, st, vnet, nsg, log, appi, func, logic, pep, rsv |
| Workload | Short code for the platform or project | webapp, hrportal |
| Environment | Deployment stage | prod, uat, dev |
| Region | Azure region, shortened | uks (UK South) |
| Instance | Zero-padded count, for when there’s more than one | 01, 02 |
Rules that keep it working:
- All lowercase, hyphen-separated, except resource types that don’t allow hyphens (storage accounts, and a few other globally unique names), which drop separators entirely.
- Storage accounts, Key Vaults, and similar globally unique resources may need a random suffix if the clean name is already taken by another Azure customer.
- Every resource sits in a resource group named for its workload and environment, so ownership is obvious without needing to read tags.
Worked example
A web app platform, deployed to UK South, in production:
| Resource | Type abbreviation | Example name |
|---|---|---|
| Resource group | rg | rg-webapp-prod-uks-01 |
| App Service plan | asp | asp-webapp-prod-uks-01 |
| App Service | app | app-webapp-prod-uks-01 |
| Azure Function (background processing) | func | func-webapp-prod-uks-01 |
| SQL Server | sql | sql-webapp-prod-uks-01 |
| SQL Database | sqldb | sqldb-webapp-prod-uks-01 |
| Storage account | st | stwebappprod01 |
| Key Vault | kv | kv-webapp-prod-01 |
| Virtual network | vnet | vnet-webapp-prod-uks-01 |
| Log Analytics workspace | log | log-webapp-prod-uks-01 |
| Application Insights | appi | appi-webapp-prod-uks-01 |
Storage accounts and Key Vaults drop the hyphens (and sometimes the region or instance too) to fit their tighter character limits — see the gotchas below.
Key points and gotchas
- Globally unique resources break the pattern. Storage accounts (3–24 characters, lowercase letters and numbers only, no hyphens) and Key Vaults (3–24 characters) can’t always fit the full convention. Abbreviate harder, or drop the region or instance first.
- Names are often immutable. Most Azure resources can’t be renamed after creation, so getting it wrong means redeploying, not editing.
- The workload code prevents collisions. In any subscription hosting more than one project, the workload code is what stops two things looking the same at a glance. Never reuse a workload code for a second, unrelated project.
- Case sensitivity is inconsistent. Most resource names are case-insensitive but stored as typed. Decide on lowercase-only up front so it’s never a judgement call mid-deployment.
- Write the convention down before building anything. Retrofitting names later means recreating resources. Agree the pattern before the first deployment, not after.
A naming convention tells you what a resource is. It doesn’t carry ownership, cost, or sensitivity, that’s what a tagging strategy is for, and the two are meant to sit side by side rather than duplicate each other.