Keep tag compliance separate from allocated spend
On this page
This check is due for a source refresh. Confirm the current documentation before you rely on provider-specific details.
Report each cloud's metadata status separately before combining allocation results. Otherwise, unlike policy and label signals can produce a misleading spend percentage, especially when scope, missing values, currency, denominator, or billing periods differ.
What you need first
- Tool
- Use the provider browser consoles, which are web interfaces for reviewing cloud governance settings. In Azure, start with Azure Policy tag definitions. In AWS, use Organizations for tag policies and Resource Groups for compliance. In Google Cloud, open Labels and select a project.
- Access
- Ask authorized Azure, AWS, and GCP colleagues for read-only results for the intended subscriptions, accounts, organization, and projects. AWS tag policies require an organization with all features enabled; the management account can view organization-wide compliance.
- If you do not use that tool
- Send governance colleagues the Azure subscription IDs, AWS account or organization scope, and GCP project IDs. Request dated Azure policy definitions and scope, AWS policy availability and compliance results, and GCP project-label lists. Ask service owners for resource-label details where allocation needs them.
Why this is worth a look
A clean compliance result can still hide allocation gaps. AWS does not evaluate untagged resources or tags outside the policy. GCP project labels do not automatically propagate to child resources. Azure policies differ between resources and resource groups, and some resource types do not support tags. Treat these controls as metadata checks, not interchangeable measures of allocated cost.
Run this check
CHECKLISTComplete this manual console review, or use dated results from authorized colleagues. Record metadata controls and gaps without editing policies, tags, or labels. This review does not calculate allocated spend.
READ-ONLY REVIEW
[ ] Set scope: Azure subscriptions, AWS organization or accounts, and GCP projects.
[ ] Record each metadata snapshot date separately from any billing-report period.
[ ] Use provider browser consoles or dated results from authorized colleagues. Confirm the scope and access for each provider; do not assume one read-only role covers all views.
[ ] Record statuses as present, missing, unavailable, or not reviewed. Treat counts as resource or project counts, never as currency or spend percentages.
[ ] Agree on required keys and allowed values for each cloud. Record exact spelling. AWS tag keys and values are case sensitive.
AZURE
[ ] Read tag-policy definitions for the subscriptions in scope. Record policy name, effect, required key/value, and whether it covers resources or resource groups.
[ ] Distinguish policies that add missing tags from policies that add or replace values. Do not assume a policy corrected existing tags.
[ ] Record unresolved coverage of existing resources and resource types that do not support tags. Do not run remediation.
AWS
[ ] Confirm that the organization has all features enabled. If not, mark the tag-policy signal unavailable and skip the remaining AWS policy review.
[ ] Review tag policies in AWS Organizations and compliance in AWS Resource Groups for the selected accounts. Request organization-wide results from a colleague authorized to view them in the management account.
[ ] Record policy keys and covered resource types alongside the result.
[ ] Record untagged-resource coverage as a separate gap. Untagged resources and tags not defined in the policy are not evaluated for policy compliance.
GCP
[ ] Open Labels in Google Cloud console and select each project, or read supplied project-label lists. Do not edit or save changes.
[ ] Record project label keys and values. Do not assume they propagate to child resources.
[ ] If allocation depends on service-resource labels, request a separate review from the service owner using that service's label documentation.
REPORTING GATE
[ ] Report each cloud's metadata status and unresolved gaps separately. Do not average these signals into a spend percentage.
[ ] Ask the billing-report owner to document comparable cost and metadata fields, included scope, denominator, missing-value handling, currency treatment, and billing period for every cloud before calculating combined coverage.
[ ] If any definition is unresolved, mark combined spend coverage as not ready to calculate.How to confirm it
- 01
Set the review boundary
Agree with finance and engineering on the subscriptions, accounts, projects, required keys, and allowed values to review. Record each metadata snapshot date separately from the billing-report period.
- 02
Read Azure policy behavior
Check whether each Azure tag policy covers resources or resource groups and whether it adds missing values or replaces existing ones. Flag existing resources that still need confirmation; a policy definition is not proof that their tags were corrected.
- 03
Expose AWS blind spots
Confirm that the AWS organization has all features enabled before reviewing tag-policy compliance. Record unavailable results as unavailable, not noncompliant, and keep untagged resources outside the compliance result visible as an allocation gap.
- 04
Separate GCP project and resource labels
Inspect project labels without changing them. Ask service owners to review resource labels separately wherever allocation depends on them, because project labels do not automatically propagate to child resources.
- 05
Gate the spend percentage
Ask the billing-report owner to resolve comparable cost fields, scope, denominator, missing-value treatment, currency, and billing periods before publishing combined coverage. Keep metadata status separate until those definitions are documented.
Before making changes
Treat this as a current metadata review, not a billing audit. It assumes you are inspecting policy definitions, compliance results, and label lists rather than validating billing-export records. Azure Modify policies can remediate existing resources with a remediation task, but tags cannot be applied retroactively to change historical allocation automatically. Confirm historical treatment with the billing-report owner before relying on updated metadata.