Azure Resource Tagging Strategy
Mandatory and optional tag keys for Azure resources, how they build on a naming convention rather than replace it, and the rules that keep cost reports and policy enforcement reliable.
Tags are key-value metadata attached to resources, resource groups, and subscriptions. Where a naming strategy tells you what a resource is at a glance, a tagging strategy carries the business context that doesn’t fit in a name: who owns it, which cost centre pays for it, how sensitive the data is, and which environment it belongs to. Tags are what make cost reports, Azure Policy enforcement, and automation actually useful. Without them, cost and ownership questions turn into manual digging through resource groups.
The two strategies are meant to reuse each other. Tagging should reuse the workload and environment codes already defined in the naming convention (webapp, hrportal, prod/uat/dev) rather than inventing separate values for the same thing.
Mandatory tags
Applied to every resource group, and inherited down where Azure supports tag inheritance:
| Tag key | Purpose | Example value |
|---|---|---|
environment | Deployment stage | prod, uat, dev |
workload | Ties the resource back to the naming convention’s workload code | webapp, hrportal |
owner | Person or team accountable for the resource | cloudops |
costcenter | Billing attribution | ecommerce, hr |
dataclassification | Sensitivity of data the resource handles | public, internal, confidential |
Optional tags
Applied where relevant:
| Tag key | Purpose | Example value |
|---|---|---|
businessimpact | How critical the resource is to the business | high, medium, low |
reviewdate | When the resource should next be reviewed for decommission | 2027-02-01 |
Rules that keep it working:
- Tag names (keys) are always lowercase. Tag names are case-insensitive in Azure, but fixing the casing removes any ambiguity.
- Tag values follow a fixed, documented list per key, no free text for
environmentordataclassification, so cost reports and policy filters stay reliable. - Tags are applied at the resource group level first, then only overridden at the individual resource level where that resource genuinely needs a different value (for example, a storage account holding more sensitive data than the rest of its workload).
Worked example
Continuing the web app platform from the naming strategy:
| Scope | Tags applied |
|---|---|
rg-webapp-prod-uks-01 | environment=prod, workload=webapp, owner=cloudops, costcenter=ecommerce, dataclassification=internal |
stwebappprod01 (product images) | inherits group tags, dataclassification=public (product images aren’t sensitive, so this overrides the group default) |
sqldb-webapp-prod-uks-01 (orders and customer data) | inherits group tags, dataclassification=confidential (contains customer PII and payment references) |
Where a whole workload handles sensitive data by default, set dataclassification=confidential once at the resource group and leave it to inherit everywhere, rather than repeating it per resource.
Key points and gotchas
- Tags aren’t secure storage. They’re stored as plain text and show up in cost reports, exported templates, and deployment history. Never put credentials or personal data in a tag value, even though
dataclassificationtells you the resource contains sensitive data. - Not every resource supports tags. Check Tag support for Azure resources before assuming a resource can be tagged the same way as its peers.
- Tag values are case-sensitive, tag names aren’t.
environment=prodandEnvironment=prodare the same tag;environment=Prodandenvironment=prodare treated as different values in reports. Fix casing in the convention, not per deployment. - Enforce with Azure Policy, don’t rely on discipline. A tagging strategy that isn’t enforced decays fast. Use policy assignments to require mandatory tags at resource creation.
- Tagging builds on naming, not instead of it. Don’t use tags to compensate for a weak naming convention, or vice versa. They answer different questions: what is this, versus who does it belong to.