A cloud tagging strategy is a written tagging policy: it fixes which keys are mandatory, which values are allowed, how keys are spelled, on which resources they sit and who maintains the list. A single tag allocates nothing on its own. Only when every team sets the same key, spelled the same way, with values from the same list, can a cost report group cleanly by team, product or cost centre. Without a policy one attribute splits into several columns, and allocation coverage stays low even though people are tagging. How tags reach the billing data, and the length and character limits, is covered in tags and labels; this page covers the rules on top.
How it works
AWS, Microsoft and Google describe the same building blocks. AWS writes a tagging schema, a table of keys with allowed values, resource types and scope, kept in a version-controlled repository. Microsoft's Cloud Adoption Framework builds on a naming convention and sorts tags into functional, classification, accounting, purpose and ownership tags. Google recommends a formal labelling policy that records per key the values, the stakeholder, the target resource and the exceptions.
What the guidance fixes
| Topic | AWS | Microsoft | Google Cloud |
|---|---|---|---|
| Mandatory and optional | agree the mandatory keys, marked as such in the schema | core tags set centrally, optional tags left to teams | decide per key whether it is mandatory and where exceptions apply |
| Casing and spelling | keys and values are case sensitive; define spelling, case and punctuation | names case insensitive, values case sensitive; lowercase keys | lowercase letters, digits, underscores and dashes only |
| Values | a list, or a prefix with a wildcard such as 123-* | consistent capitalisation of values | a set of values per key |
| Namespace | an organisation prefix such as example-inc: | no prefix given | a company prefix, altostrat- in the example |
| Size | start small, grow as needed | no number given | try not to use more than ten labels |
| Personal data | do not store it in tags | no sensitive values, tags are plain text | no personal or confidential information |
Mandatory keys and their values
The providers' examples share four attributes: who owns the resource (owner or team), which environment it runs in (environment), which application or product it serves (application) and which cost centre carries it (cost-center). Each mandatory key needs a value list or a value source. A fixed list works for environments. Cost centres and teams change with the organisation, so the policy can point to the system that holds them instead, such as the finance team's cost centre list. How team and cost centre relate is covered in cost centres and team ownership.
One spelling for three providers
Keys that must work everywhere are bound by the narrowest rule, which is Google's: a label key starts with a lowercase letter or an international character and contains only lowercase letters, digits, underscores and dashes. The colon prefixes in the AWS guidance, such as example-inc:cost-allocation:CostCenter, cannot be set as Google labels. On AWS costcenter and CostCenter are two keys, and AWS points out that spelling separates them too: costcenter and the British costcentre are different keys. Azure ignores case in tag names for operations but shows the stored casing in cost reports. A policy spanning providers therefore ends up with lowercase keys with a single kind of separator, written out once, and list values in the same form.
Scope and enforcement
The policy states where each key sits. An attribute that holds for a whole subscription or project can sit there. On Azure it then reaches the resources' usage data through tag inheritance in Cost Management, or through an Azure Policy definition that copies the tag from the resource group or subscription onto the resources (modify effect); on Google Cloud it appears as a project label in a separate field of the export. Whatever changes from resource to resource sits on the resource.
Enforcement happens outside billing. AWS Organizations expresses the policy as a tag policy that fixes allowed values and the preferred case treatment per key and can block noncompliant tagging operations for chosen resource types. For a key marked as required, CloudFormation, Terraform and Pulumi can check a deployment before its resources are created and warn about or block it if the key is missing. Azure Policy ships built-in definitions that require a tag (deny effect), add one or copy it from the resource group or subscription (modify effect). Preventive and detective controls of this kind are covered in guardrails and approval thresholds.
What it means for your cost
In the billing data a policy shows up as a few tag columns whose values come from known lists. A cost report groups by them without clean-up, and any value outside the list stands out as a group of its own. The policy also defines what is measured: coverage per mandatory key, in money, as tag coverage and untagged cost explains.
Every change leaves a mark in the history. A renamed key is a new key on AWS that has to be activated as a cost allocation tag, while past months keep the old one. A backfill, which the management account can request for up to twelve months, fills in only tags the resources carried at the time. Old and new key can therefore only be joined by a rule that reads both, as virtual tags and allocation rules describes.
Who maintains the list is a question of roles. AWS suggests recording ownership of the schema, for example in a RACI matrix; the roles themselves are covered in FinOps roles and responsibilities.
An owner tag holding a person's name or email address appears in every cost export and every report that shows the column. All three providers advise against storing personal data in tags, and Microsoft notes that tags are plain text, visible in cost reports, API responses, deployment histories and logs. Whether such a value is permissible under the GDPR is for whoever handles data protection in the company to judge; a team or role name contains no person's name.
Where it goes wrong
- Two spellings of one key. Symptom:
costcenterandcostcentreappear as two columns, each incomplete. Cause: AWS treats every character of a key as significant, and the policy never wrote the spelling out. - An AWS template carried over to Google Cloud. Symptom: the key cannot be set as a label, and teams invent variants. Cause: Google labels allow neither colons nor capital letters.
- Free text instead of a value list. Symptom:
prod,Prodandproductionshow up as three environments. Cause: values are case sensitive on AWS and Azure, and without a list each team writes its own form. - Compliant on paper, still untagged. Symptom: the tag policy compliance report is clean while allocation coverage is low. Cause: the AWS compliance report lists only resources that have carried at least one tag, and it flags a missing key only where the tag policy marks that key as required for the resource type; a resource that never had a tag does not appear as noncompliant.
- People in the owner tag. Symptom: email addresses appear in every cost export and in reports for the whole organisation. Cause: the policy allows personal values although tags are plain text everywhere.
Sources
Read on 2026-10-16. AWS Best Practices for Tagging AWS Resources, with its sections what are tags?, building your tagging strategy and defining and publishing a tagging schema, tag policies in AWS Organizations, report tagging compliance, enforce required tag keys with IaC and backfill cost allocation tags; Microsoft define your tagging strategy, use tags to organize your Azure resources, group and allocate costs using tag inheritance and assign policy definitions for tag compliance; Google Cloud best practices for labels and structure of Standard data export.