Commercial and channel
Tagging
Azure tagging
Azure tagging is the practice of attaching metadata, in the form of key-value pairs, to Azure resources, resource groups, and subscriptions. Tags have no effect on how a resource actually functions, but they are the primary mechanism Azure provides for organising, governing, and, critically for cost purposes, attributing spend across a cloud estate that would otherwise present as a flat, largely undifferentiated list of resources and their costs.
Why Tagging matters in a Microsoft estate
Tagging matters because Microsoft estate decisions often have a commercial owner as well as a technical owner. Clear cost, licence, and partner language helps teams prove value, reclaim waste, and agree the next action before spend becomes harder to challenge.
How Tagging shows up in practice
A typical tagging scheme captures dimensions like cost centre, project or application name, environment (production versus development versus test), and owner. Once applied consistently, those tags become the basis for cost allocation reports in Cost Management that break spend down by department or project rather than only by resource type or resource group. They also drive automation that acts on a tag's value, such as scripts that automatically shut down resources tagged as non-production outside business hours to control cost, and governance policies that can require, restrict, or default specific tag values as resources are created. The gap between tagging's theoretical usefulness and its practical value in most real estates comes down almost entirely to consistency, and it is the single most common failure mode organisations run into.
Tags applied inconsistently, missing entirely on a meaningful fraction of resources, or applied with inconsistent casing and naming, CostCentre against cost-centre against Cost_Centre, produce cost and governance reports with real, sometimes substantial gaps and inaccuracies. Because Cost Management and most downstream reporting tools treat tag values as literal strings rather than normalising variants, those inconsistencies do not resolve themselves; they compound as more resources are created without enforcement. Azure Policy is the practical mechanism most organisations rely on to close that gap. It can enforce a required tag at resource creation time, deny creation of untagged resources in specific categories, or automatically inherit a tag value from a resource's parent resource group or subscription.
This matters because tag inheritance in Azure is otherwise limited and does not propagate automatically without such a policy in place. It is also worth noting that tags are not free of cost or limits. There is a maximum number of tags per resource and per-tag length limits that occasionally require thought in the naming scheme itself, and some resource types have restrictions on which tags propagate to their billing line items. Both of these are worth checking early when designing a tagging taxonomy, rather than discovering them after the scheme is already in wide use across an estate.