Azure Naming Standards
Consistent naming conventions are critical for managing Azure resources at scale. Well-defined standards improve automation, clarity, and governance, especially in enterprise and DevOps environments.
Key Principles
Consistency: Use the same pattern across all resource types and environments.
Readability: Names should be easy to understand for engineers and automation tools.
Scalability: Support for multiple environments, regions, and projects.
Automation-Friendly: Avoid special characters and use lowercase where required (e.g., storage accounts).
Recommended Naming Pattern
resource-type-abbr
: Short code for the resource type (see table below)app/project
: Application or project nameenv
: Environment (dev, test, prod, qa, uat, etc.)region
: Azure region short code (e.g., weu for West Europe, eus for East US)instance
: Optional numeric or descriptive instance (e.g., 01, db, web)
Common Abbreviations
Resource Group
rg
Virtual Network
vnet
Subnet
sn
Network Interface
nic
Network Security Grp
nsg
Virtual Machine
vm
Storage Account
st
Key Vault
kv
App Service
app
SQL Server
sql
SQL Database
sqldb
Cosmos DB
cdb
Function App
func
Application Gateway
agw
Firewall
fw
Log Analytics
log
Real-Life Examples
Resource Group:
rg-myapp-prod-weu
VM:
vm-myapp-dev-weu-01
Storage Account:
stmyappprdweu01
(lowercase, no dashes)Key Vault:
kv-myapp-prod-weu
App Service:
app-myapp-test-eus
SQL Database:
sqldb-myapp-prod-weu
Automation Example (Terraform)
Automation Example (Azure CLI)
Best Practices
Document your naming convention and enforce it with Azure Policy or CI/CD checks.
Use tags for additional metadata (e.g., owner, cost center, environment).
Avoid using personally identifiable information (PII) in resource names.
Common Pitfalls
Inconsistent abbreviations or region codes.
Exceeding Azure's resource name length limits.
Using unsupported characters (e.g., uppercase, special symbols).
Joke: Why did the Azure VM get a short name? Because it couldn't handle the character limit!
Last updated