A tag is a key-value pair attached to a cloud resource that the provider copies onto every usage line that resource produces in the billing data; Google Cloud calls the same thing a label. Without it the bill knows only the account, the service and the region. The tag is what says which team, product and cost centre a line belongs to, and what breaks an invoice into reports per owner. The share of cost that reaches an owner this way is the tag coverage, the number every tagging practice is measured by, and one part of allocation coverage, which also counts what accounts and rules assign.

How it works

Three things hold everywhere. A tag is set on the resource, not in the billing system. It applies from the moment it is set and never backwards. And it reaches the cost data with a delay.

AWS

An AWS tag is a key and a value, each key once per resource. Setting it is not enough: a key has to be activated as a cost allocation tag in the Billing and Cost Management console before it shows up in Cost Explorer, in the Cost and Usage Report or in the cost allocation report. Only the organisation's management account can do that, and AWS documents up to 24 hours before tags appear in the console. Activated user-defined keys carry the prefix user: in the reports, AWS-generated tags the prefix aws:. The main one, aws:createdBy, records which principal created a resource, but it is applied only to resources created after it was activated, only for the documented services and regions, and on a best-effort basis from CloudTrail events. The limits: at most 50 user-created tags per resource, keys of 1 to 128 characters, values of 0 to 256, both case sensitive, and at most 500 active cost allocation keys per payer account.

Azure

Azure puts tags on resources, resource groups and subscriptions, not on management groups. Each of those carries up to 50 name-value pairs; a name may be 512 characters long (128 on storage accounts), a value 256. Tag names are case insensitive for operations, but the resource provider may keep the casing you supplied, and that casing is what cost reports show; values are case sensitive. Resources do not inherit the tags of their resource group or subscription. Only the usage record can inherit them: the tag inheritance setting in Cost Management writes subscription and resource group tags, and on a Microsoft Customer Agreement billing profile and invoice section tags too, onto the usage records of the resources beneath, without touching the resources. It is available for Enterprise Agreement, Microsoft Customer Agreement and Microsoft Partner Agreement with Azure plan subscriptions, takes 8 to 24 hours, and applies to the current month from its first day. Where resource and group share a key, the resource tag wins by default; that can be switched. Not every resource type supports tags, classic resources none at all, and purchases or resources that emit no usage at subscription scope get no tags even with inheritance on.

Google Cloud

Google Cloud has two different things. Labels are metadata on a resource: up to 64 per resource, keys of 1 to 63 characters, values up to 63, lowercase letters, digits, underscores and dashes, international characters included. Labels are forwarded to billing and appear in the billing reports and the BigQuery export. Tags are resources in their own right, defined before use, inherited down the resource hierarchy and usable as conditions in IAM and organisation policies, which labels cannot be. In the standard usage export, labels land in the labels field, the project's own labels separately in project.labels, Google-generated system labels in system_labels, and tags in tags, flagged as inherited or direct. A label's cost data begins on the day it was applied, and Google documents up to an hour before tags appear in the export. Every line that accrues in a project carries the project's labels, even when the resource carries none.

What it means for your cost

In the billing data a tag is one more column, or one nested field, per line. A cost report groups by it, and the sum over all values of a key plus the lines without one adds back up to the invoice. The share with a value is the tag coverage, the rest is untagged cost, and only the allocated share can be turned into unit costs.

Coverage never reaches every line, because part of the bill hangs on no resource. Support plans, reservation purchases and commitment fees are charged to the account or billing profile, not to a taggable resource; Azure shows them in cost analysis as "Tags not supported", and on Google Cloud support cost belongs to the billing account and carries no project. Marketplace lines and data transfer carry a tag only where the provider links the line to a tagged resource. Services whose usage data carries no tags at all Azure marks "Tags not available". Only the remainder is untagged in the narrow sense, the team's omission. A report keeps these groups apart, because only the last one shrinks through tagging; the others need a rule that spreads them as shared cost by account, project or key.

The keys needed are nearly the same small set everywhere: who owns the resource (owner or team), which environment it runs in (environment), which product or service it belongs to (product or application) and which cost centre it is booked to (cost-center). More keys rarely raise coverage; they lower it, because every key is one more gap.

Where it goes wrong

  • Tags activated late. The resources were tagged, but nobody activated the keys in the AWS console or switched on Azure inheritance. Azure applies inheritance from the current month on, so earlier months stay without the inherited tags; AWS fills earlier months only when the management account requests a backfill, for up to twelve months and only for tags the resources carried at the time.
  • Keys in several spellings. CostCenter, costcenter and cost-center are three keys on AWS, Google Cloud allows lowercase only, and Azure shows whichever casing the resource provider kept. The report then has three incomplete columns for one thing.
  • Tags at the wrong scope. A tag on an Azure resource group reaches the resources' usage data only through tag inheritance in Cost Management or through an Azure Policy definition that copies it onto the resources (modify effect); a Google Cloud project label sits in a different field from the resource labels. Assuming inheritance measures a coverage that does not exist.
  • Coverage counted by resources instead of cost. A high share of tagged resources says nothing about the share of cost when the few most expensive databases and clusters are missing. Coverage is measured in money, not in counts.
  • The policy written before the report. A standard with a dozen mandatory keys that nobody reads against a cost report produces fields with placeholder values. The report first, then the keys it needs, then a coverage number someone reads every month.

Sources

Read on 2026-10-15. AWS organizing and tracking costs using cost allocation tags, backfill cost allocation tags, AWS-generated tags and tag naming limits and requirements; Microsoft use tags to organize your Azure resources, group and allocate costs using tag inheritance, assign policy definitions for tag compliance and group and filter options in cost analysis; Google Cloud labels overview, Tags overview and structure of Standard data export; FinOps Foundation Allocation (CC BY 4.0).