Naming and Tagging Baseline

Names and tags answer two different questions. A name answers what is this resource? A tag answers what do we currently know about it? Getting the split right early is cheap; fixing it later means renaming or re-tagging thousands of resources by hand.

Purpose

This page defines a naming and tagging baseline that supports operations, cost management, governance, automation, and security reporting. Naming identifies resources; tags provide metadata. A maintainable platform needs both.

Design Reasoning

The rule that resolves almost every naming question: resource names hold stable information; tags hold metadata that changes over time.

Do not put changing data — owner, cost center, business unit, maintenance window — into resource names. Those values change, and a name cannot. Store them as tags instead. Names should be predictable, short enough for Azure’s per-resource limits, and useful in logs, alerts, and scripts.

Architecture Decision Record

Tradeoff: A fixed naming pattern is occasionally a tight fit for resources with short length limits (storage accounts, Key Vault). Accept a documented abbreviation for those cases rather than abandoning the pattern.

Recommended Configuration

Naming patterns

Required tags

Not every Azure resource type supports tags, and tags are not inherited by default. Plan for both: use Azure Policy with Modify and tag-inheritance policies so resources inherit tags from their resource group or subscription, and use Append/Deny where a tag must be present.

Example Implementation

A resource group created with the full required-tag set in Bicep:

1
param location string = 'switzerlandnorth'
2

3
param tags object = {
4
  environment: 'prod'
5
  owner: 'platform-team'
6
  costCenter: 'IT-100'
7
  workload: 'platform-management'
8
  dataClassification: 'internal'
9
  criticality: 'high'
10
  maintenanceWindow: 'sun-0200-0400'
11
}
12

13
resource rg 'Microsoft.Resources/resourceGroups@2025-04-01' = {
14
  name: 'rg-platform-mgmt-prod-sec-001'
15
  location: location
16
  tags: tags
17
}

Validation Steps

1
# Find resources by tag — missing or wrong tags surface immediately
2
az resource list --tag environment=prod --output table
3

4
# Review predefined tag names and values in the subscription
5
az tag list --output table
6

7
# Summarize policy compliance, including tag policies (policyinsights extension)
8
az policy state summarize --subscription <subscription-id>

Common Mistakes

• Overly long or manually invented names that drift per project.
• Putting owner or cost center into the resource name instead of into tags.
• A different tag schema per team, which makes cost and ownership reporting impossible.
• Assuming every resource supports tags, or that tags inherit automatically — they do not.
• Enforcing tags without defining allowed values, which produces consistent keys with meaningless values.

References

• Define your naming convention — Cloud Adoption Framework
• Abbreviation recommendations for Azure resources
• Develop your naming and tagging strategy
• Assign policy definitions for tag compliance
• Azure Naming Tool (mspnp)