Naming Cloud Resources Standards

Standard Metadata

  • Area: Security
  • Owner: Cloud & DevOps group
  • Last reviewed: 2026-09-09
  • Next review due from: 2026-12-01
  • Enforcement: Code review
  • Status: Active

Overview

Naming conventions for resources in a cloud provider play a crucial role in maintaining a well-organized and easily manageable environment. By adhering to these guidelines, we can ensure consistency, clarity, and efficiency across all Audacia projects both ones hosted by us and ones hosted by our clients.

Determine the appropriate naming convention based on the project’s context:

  • For a new project or environment - use this naming convention.
  • For an existing project or environment without a clear convention - use this naming convention for new resources.
  • For an existing project or environment with a clear convention - use the existing naming convention.

Cloud resources must have descriptive and meaningful names · CLOUD-01.1 · MUST · DEV

Use names that accurately describe the resource’s purpose, function, or role. Avoid ambiguous or generic names that may lead to confusion or misinterpretation. Ensure names convey relevant information without being overly long or complex.

Example 1:

  • Good: olympus-dev-vm
  • Bad: vm1

Example 2:

  • Good: olympus-dev-asp-functions
  • Bad: app-service-plan

Example 3:

  • Good: olympusdevst
  • Bad: storageaccount

Cloud resources must be named consistently · CLOUD-01.2 · MUST · DEV

Establish a consistent naming convention that is applied uniformly across all resources. Include all relevant teams and stakeholders in the development of the naming standard to ensure buy-in and alignment.

Good:

  • olympus-dev-asp-functions
  • olympus-qa-asp-functions
  • olympus-uat-asp-functions

Bad:

  • olympus-dev-service-plan-functions
  • olympus-qa-asp-functions
  • olympus-uat-app-service-plan-functions

Resource names must use lowercase letters and numbers · CLOUD-01.3 · MUST · DEV

Stick to lowercase letters and numbers to avoid potential case sensitivity issues and ensure consistency. Avoid using special characters, spaces, or uppercase letters in resource names.

Resource names must include an environment indicator · CLOUD-01.4 · MUST · DEV

Include environment indicators to differentiate resources across development, production, staging, or testing environments. Use abbreviations or standardized keywords such as “dev”, “prod”, “staging” or “qa”.

Generic: {project}-{environment}-*

Examples:

  • olympus-dev-*
  • olympus-qa-*
  • olympus-uat-*
  • olympus-prod-*

Resource names must include purpose or resource type indicators · CLOUD-01.5 · MUST · DEV

Use the purpose and the type of the resource to categorize the resources based on their purpose, department, or function. Prefixes provide a quick way to identify resource types and aid in navigation and management.

Generic: {project}-{environment}-{purpose*}-{resource}-*

purpose*: A prefix indicating the purpose of the resource in the context of the system.

Examples:

  • olympus-qa-portal-api
  • olympus-qa-public-api
  • olympus-qa-orders-func
  • olympus-qa-timers-func
  • olympus-qa-customers-sqldb
  • olympus-qa-sales-sqldb
  • olympus-qa-language-vnet
  • olympus-qa-build-vnet

Resource names must include a location indicator · CLOUD-01.6 · MUST · DEV

Include location indicators for resources deployed across multiple regions or geographical locations. Use standardized location abbreviations or keywords to maintain consistency.

Generic: {project}-{environment}-{resource}-{location}

  • olympus-qa-sqldb-uksouth
  • olympus-qa-sqldb-westeu
  • olympus-qa-cosmos-westus
  • olympus-qa-cosmos-usva

Resource names must be concise and clear · CLOUD-01.7 · MUST · DEV

Keep resource names concise while maintaining clarity and conveying relevant information. Avoid excessively long or cryptic names that may hinder readability and management.

Project-specific conventions must be documented · CLOUD-01.8 · MUST · DEV

If the project requires a different naming convention this should be documented and distributed among relevant teams and stakeholders. Provide clear guidelines, examples, and explanations to ensure proper understanding and adoption of the naming standard. Conduct training or workshops to educate teams on the importance of adhering to the naming conventions.

Appendix - Common Abbreviations

Azure Resources

Category Resource Abbreviation Example
General Resource Group rg {project}-{env}-rg
Compute and Web Virtual Machine vm {project}-{env}-vm
Compute and Web App Service Plan asp {project}-{env}-asp / {project}-{env}-asp-functions
Compute and Web Web App web {project}-{env}-{name}-app
Compute and Web Function App func {project}-{env}-{name}-func
Compute and Web Availability Set avail {project}-avail
Databases Database db {project}-{env}-sqldb / {project}-{env}-cosmos
Databases Azure Cache for Redis instance redis {project}-redis
Integration Service Bus sbns {project}-{env}-sbns
Integration Service Bus Queue sbq {project}-sbq
Integration Service Bus Topic sbt {project}-sbt
Integration Logic App logic {project}-logic
Management and Governance Azure Monitor Action Group ag {project}-ag
Security Key Vault kv {project}-kv
Storage Storage Account st {project}{env}st / {project}{env}st{name}
Analytics Log Analytics workspace log-analytics {project}-{env}-log-analytics
Analytics Application Insights appinsights {project}-{env}-app-insights
Networking DNS zone dns {project}-{env}-dns
Networking Virtual Network vnet {project}-{env}-vnet
Networking Subnet snet {project}-{env}-snet
Networking Network Security Group nsg {project}-{env}-nsg / {project}-{env}-nsg-{type}
Networking Front Door (Standard/Premium) profile afd {project}-afd
Networking Front Door (Standard/Premium) endpoint fde {project}-fde
Networking Front Door firewall policy fdfp {project}-fdfp
Networking Front Door (classic) afd {project}-afd
AI & ML Azure Cognitive Search srch {project}-{env}-srch
AI & ML Azure Cognitive Services cog {project}-{env}-cog

For Azure resources that are not in the above table, refer to here for guidance.