An Azure tagging strategy people will actually follow
The document is called something like "Cloud Resource Tagging Standard v2.1". It
specifies eleven mandatory tags including BusinessUnit, DataClassification
and CostCentreSubCode. It was approved in March. By June the newest resources
have three tags, two of which are misspelt, and the tag report is the thing
nobody opens.
An azure tagging strategy fails for one of two reasons. Either it asks for information the person creating the resource does not have, or it is not enforced, which makes it a suggestion. Usually both.
An azure tagging strategy of four tags, and why these four
Every tag you require is a small tax on creating a resource. Charge as little as possible, and only for things you will actually use.
owner. An email address, not a team name. Teams reorganise and their names
change; a mailbox either resolves or it does not. This is the single most
valuable tag because it converts "what is this" into a question you can ask
somebody.
cost-centre. Whatever finance actually uses. Not a name you invented, and
not a hierarchy: a flat code that matches what appears on an internal recharge,
because a tag finance cannot map to their own system is a tag with no purpose.
environment. prod, nonprod, or whatever two or three values you really
distinguish. Resist five. The value of this tag is that it makes "can I switch
this off" answerable, and that question only has two interesting answers.
expires. A date, on anything temporary. This is the one most standards
omit and the one that does the most work, because it turns
the idle VM conversation from a negotiation into a
diary entry. A machine tagged expires: 2026-03-31 in a resource group called
rg-poc needs no discussion in April.
Four tags. Anything else you want, add later once these four are actually present, which will take longer than you expect.
Enforcement rather than nagging
A tag policy enforced by reminders is not a policy, it is a recurring disappointment. Azure Policy has three effects worth knowing here, and choosing between them is the whole design.
Audit flags non-compliant resources without stopping anything. Useful for finding out how bad it is, useless for stopping it getting worse.
Modify adds or inherits a tag automatically. This is the underrated one.
Inheriting cost-centre from the resource group means nobody has to type it,
which means nobody types it wrong. Microsoft's
tag governance documentation
covers the built-in definitions for inheritance, and they cover most of what a
small estate needs without writing custom policy.
Deny blocks creation of a resource without the tag. Correct for owner on
anything expensive, and a good way to make yourself unpopular if applied to
everything at once.
The sequence that works: Modify for anything inheritable, Deny for owner on
new resource groups only, Audit for the rest, and revisit in a quarter. Deny on
day one across a live subscription breaks somebody's deployment pipeline within
the hour, and the policy gets removed rather than fixed.
The retrofit problem
New resources are the easy half. The existing several hundred are the reason most tagging efforts stall.
Do not try to tag everything. Sort by cost, tag the top twenty resources by hand, and accept that a long tail of cheap resources will stay untagged indefinitely. Tagging a load balancer that costs nothing achieves nothing except making a percentage look better.
Where resources are grouped sensibly, tag the resource group and let inheritance do the work. Where they are not, the fastest route is usually to fix the grouping rather than the tags, which is a bigger job and worth knowing about before you promise a deadline.
When the report says untagged 61 percent
At which point somebody will ask you to get it to 100, and that is the moment to push back with a better metric.
Percentage of resources tagged is a vanity number. It treats a 4 pence public IP and a 900 pound SQL instance as equal, and it can be improved by tagging cheap things, which is effort with no outcome. The number that matters is percentage of monthly spend attributable, which is the same query weighted by cost.
Untagged 61 percent of resources but only 8 percent of spend is a well-run estate with a long tail. Untagged 12 percent of resources but 40 percent of spend means one large untagged thing, and you should go and find out what it is right now.
That reframing also gives you a finish line. Attributing 95 percent of spend is achievable and useful. Tagging every object is neither.
Reporting spend by tag
Once cost-centre is populated on the expensive things, the Cost Management
API will group by tag directly and you can produce the report finance keeps
asking for. Two practical notes learned the hard way.
Tags are case-preserving but comparisons are not always case-insensitive
depending on the surface you query, so Prod and prod will bite you at some
point. Pick lower case, enforce it in policy, and normalise on the way in.
And a tag applied today does not retroactively tag last month's usage. Cost data is stamped with the tags that were present when the usage occurred, so the first month after a tagging push will still look mostly unattributed. That is not a bug and it is worth warning people about before they see the report and conclude the exercise failed.
AzClean Reporting handles the spend-by-tag output and the attribution percentage, which is the version worth showing somebody rather than the raw compliance count.
The one rule
A tag nobody consumes will not survive, however well enforced. Before adding a tag to the standard, name the query that reads it and the person who runs that query. If you cannot, the tag is documentation of an intention rather than infrastructure metadata, and it will be wrong within two quarters.
That is why owner and expires outlast DataClassification in practice.
Somebody uses them every month.
If you are starting from nothing, the order that works is: run the orphan sweep first so you are not tagging things you are about to delete, then tag the twenty most expensive survivors by hand, then turn on inheritance. Tagging before deleting is how estates end up with a tidy inventory of waste.