Virtual tags are allocation attributes computed from the billing data instead of set on the resource: an allocation rule reads the account, service, resource name or existing tags and writes a value such as team or product onto every line. None of the three providers uses the term; AWS calls the feature Cost Categories, Microsoft cost allocation rules. Such rules reach what tagging cannot: lines with no resource behind them, keys in several spellings, and months before anyone tagged. Allocation coverage rises without touching a single resource. In exchange, allocation becomes logic that someone has to maintain, review and date.
How it works
A rule list is read from top to bottom. The first match sets the value, and a default value catches whatever no rule matches. Conditions are fields every line carries, from the account and the service to existing tags. A virtual cost centre tag might read the key cost-center first, then the variants CostCenter and costcentre, and finally fall back to the account. Because the rule runs on billing data, it covers every month the data holds, as far as the tool applies it backwards; a tag on the resource counts only from the day it was set. The result is a dimension reports group by, a segment; segments and hierarchies in cost allocation covers how segments roll up into hierarchies.
AWS
AWS Cost Categories is the built-in rule engine. A cost category is a key, and its value sits on every line a rule matches. The operators are Is, Is not, Is absent, Contains, Starts with and Ends with; the last three apply to accounts and tags only and are case sensitive. Regular rules set a fixed value, inherited value rules copy the value of a tag key or the account name. The first matching rule wins, and an optional default value takes the rest. Cost categories are created by an organisation's management account or a standalone account, with up to 50 cost categories of 500 rules each through the API, or 100 in the console.
A new or changed cost category applies from the first of the current month, and with an earlier start date retroactively, at most twelve months back. Values appear everywhere within 24 hours, and the status then moves from Processing to Applied. In CUR 2.0 a key of the map column cost_category appears only when it has a value for that line.
Azure
Azure has two mechanisms. Tag inheritance is a fixed, built-in rule: it writes subscription and resource group tags, and on a Microsoft Customer Agreement billing profile and invoice section tags too, onto the usage records beneath, from the current month; where keys collide, the resource tag wins by default. Cost allocation rules move cost from sources (subscriptions, resource groups or tags) to subscriptions, resource groups or tags as targets: evenly, by fixed whole-number percentages, or in proportion to the targets' total, compute, storage or network cost. They run in the order they were created and take up to 24 hours. They are available for Enterprise Agreements and Microsoft Customer Agreements, enterprise or online. They do not move purchases such as reservations and savings plans, and they do not change the invoice. Shared cost and how to split it covers how Azure uses them to split shared cost.
Google Cloud
Cloud Billing has no rule engine like Cost Categories: its reports group only by fixed dimensions such as project, project hierarchy, service and SKU, and by label keys. The building blocks sit in the BigQuery export: project.labels on every line, project.ancestors with folders and organisation, labels, tags flagged inherited, service and SKU. A rule there is SQL, for example a CASE expression in a view, with conditions in a fixed order and the ELSE branch as the default value. Google publishes example queries for labels, tags and the resource hierarchy from which such rules are built.
FOCUS
The FinOps Open Cost and Usage Specification (FOCUS) has carried split columns since release 1.3: AllocatedMethodId, AllocatedMethodDetails, AllocatedResourceId, AllocatedResourceName and AllocatedTags. They describe splits the data generator calculated itself, such as the cost of a node in a shared cluster spread across its workloads. The split lines add up to the origin line, and the unallocated part has no AllocatedResourceId. A company's own rules do not fill these columns; carrying their result in a FOCUS dataset takes an additional column prefixed x_, as FOCUS requires. FOCUS columns and the providers' mapping covers the columns in detail.
| Provider | Mechanism | Conditions | Result visible in |
|---|---|---|---|
| AWS | Cost Categories with regular and inherited value rules, default value | account, service, region, usage type, charge type, tag, billing entity, another cost category | Cost Explorer, AWS Budgets, Cost Anomaly Detection, CUR column cost_category |
| Azure | tag inheritance, cost allocation rules | tags from the levels above; sources subscription, resource group, tag | cost analysis, budgets, forecasts, exports with costAllocationRuleName |
| Google Cloud | SQL over the BigQuery export | any field in the export | own tables and reports |
| FOCUS | Allocated columns | the data generator's method | the provider's FOCUS export |
What it means for your cost
A value from a rule is not a tag. A report that mixes both shows high coverage while the resources stay untagged. A clean report therefore records whether a value came from a tag, from the account or from which rule, and measures tag coverage separately. The default value is the most telling line: whatever lands there matched no rule.
Rules change the past. On AWS every change applies at least from the first of the current month, and with an earlier start date up to twelve months back. On Azure an edited rule is reprocessed within up to two hours; Microsoft does not document how far back it reaches. Rules therefore need a change log with date and reason, for example as code in a version-controlled repository.
The total is preserved. On AWS each line has at most one value per cost category, and without a default value unmatched lines stay without one. Azure cost allocation rules produce a pair in the export, a negative row on the source and a positive one on the target; for reconciliation with the invoice, Microsoft advises filtering these rows out.
Where it goes wrong
- Overlapping rules. Symptom: after a new rule a team's cost drops with no change in usage. Cause: on AWS the first matching rule wins; on Azure a rule created later has no effect once an earlier one has moved all of the source's cost.
- A rule hiding the tagging gap. Symptom: allocation is close to complete, yet teams cannot find their resources. Cause: a broad default value or an account rule assigns everything, and nobody measures tag coverage separately.
- An undated rule change. Symptom: last quarter's figures have changed and nobody knows why. Cause: the change applied retroactively and was recorded nowhere.
- Casing in a condition. Symptom: a Contains rule misses some lines. Cause: Contains, Starts with and Ends with are case sensitive on AWS.
- A purchase expected in an Azure rule. Symptom: a reservation stays in the central subscription. Cause: cost allocation rules do not move purchases.
Sources
Read on 2026-10-16. AWS organizing costs using AWS Cost Categories, creating cost categories, quotas and restrictions, CreateCostCategoryDefinition and cost category columns in CUR 2.0; Microsoft create and manage Azure cost allocation rules and group and allocate costs using tag inheritance; Google Cloud example queries for Cloud Billing data export, structure of Standard data export and analyze billing data and cost trends with Reports; FinOps Foundation FOCUS column library, data generator-calculated split cost allocation, data generator-calculated split cost allocation handling, Allocated Resource ID and custom column handling.