Policy as code means writing governance rules such as mandatory tags, allowed regions or instance sizes as machine-readable definitions, keeping them in a repository, reviewing them like code and deploying them through a pipeline. For tagging, the tagging policy becomes definitions that reject a wrongly tagged resource at creation, add a missing tag or report the breach. Which keys and values the policy holds is covered in cloud tagging strategy: a policy that holds. This page covers the mechanisms AWS, Azure and Google Cloud offer to enforce it, and the gap each one leaves.
How it works
The mechanisms act at different points.
| Mechanism | Acts | Missing mandatory tag | Wrong value or casing | Existing resources |
|---|---|---|---|---|
AWS tag policy, basic rules with enforced_for | on the tagging operation | not prevented | prevented, for supported resource types | compliance report |
| AWS tag policy, "Required tag key" | at deployment through CloudFormation, Terraform or Pulumi | warning or failure | only the key is checked | organization-wide report |
SCP with aws:RequestTag | on the API request | prevented where the service accepts tags at creation | values yes, key casing no | no |
AWS Config required-tags | after configuration changes | reported | values reported | yes |
| Azure Policy deny | on the request | prevented | value prevented if the definition checks it; casing only with match | marked non-compliant |
| Azure Policy modify | on the request, existing resources by remediation task | added | replaced | by remediation task |
| Google custom constraint | at creation, optionally also on update | prevented | prevented if the condition checks the value | not retroactive |
AWS
Tag policies in AWS Organizations fix the casing and the allowed values per key, and with enforced_for they prevent noncompliant tagging operations for the listed resource types. AWS states that these basic rules do not cover resources created without tags and do not enforce missing keys, and points to two other routes. The first is "Required tag key": report_required_tag_for marks a key as mandatory, and CloudFormation (through the AWS::TagPolicies::TaggingComplianceValidator hook, in warn or fail mode), Terraform (from AWS provider 6.22.0) and Pulumi (through a policy pack) check it before resources are created. The hook must be activated in each account and region where it applies; AWS suggests StackSets. The second route is an SCP that denies creating certain resource types without the required tags, using the aws:RequestTag and aws:TagKeys conditions. Key names in such conditions are not case sensitive; against variants such as CostCenter and costcenter, AWS recommends aws:TagKeys or tag policies.
The tag policy compliance report includes only resources that have had at least one user-defined tag at some point; untagged resources do not appear as noncompliant. For those, AWS points to Resource Explorer with the query tag:none. The required-tags Config rule checks up to six keys with optional values for a fixed list of resource types, triggers on configuration changes and prevents nothing; automatic remediation needs a Systems Manager document of your own.
Azure
In Azure Policy the effect decides. Deny rejects the request, audit logs it, append adds fields only when a resource is created or changed, and modify adds, replaces or removes tags during creation or update. Modify changes existing resources only through a remediation task, for which the assignment needs a managed identity with Contributor or Tag Contributor operations; Microsoft recommends modify over append for tags. Modify is evaluated before deny, so an added tag can stop a deny from triggering. Built-ins include "Require a tag on resources" (deny) and "Inherit a tag from the resource group if missing" (modify). Rule conditions ignore case except match and notMatch, so Prod passes a rule expecting prod.
Cost Management's tag inheritance, for EA, MCA and MPA, is a different thing. It writes subscription and resource group tags into the usage records, not onto the resources, within 8 to 24 hours and for the current month.
Google Cloud
Organization policies check labels through custom constraints with conditions in CEL. For Compute Engine instances Google supports fields including resource.labels and resource.machineType, for example 'cost_center' in resource.labels. A constraint applies to the resource type it is written for, on creation or also on update; in the second case it blocks changes to a violating resource unless the change resolves the violation. Google offers a dry-run mode for testing, and new policies are usually not retroactive. In Preview, a custom organization policy can also require Resource Manager tags on listed resource types, including projects and Compute Engine instances. Unlike labels, Resource Manager tags are inherited and usable in IAM conditions and, for some resources, in organization policy conditions; both reach the billing export, tags with a tags.inherited field.
Definitions in a repository
Microsoft describes the workflow: definitions, assignments and exemptions sit as JSON in source control, GitHub workflows or Azure Pipelines deploy them, and write access to policy resources can be restricted to the pipeline's identity. A new rule first runs with enforcement mode disabled in a test environment; a compliance check and remediation follow, then enforcement, one environment at a time. Google applies organization policies as YAML files with gcloud org-policies set-policy and offers gcloud beta terraform vet, in Preview, to check Terraform plans against constraints in a CI pipeline.
Open-source tools fall into two categories. A policy engine such as Open Policy Agent, a CNCF graduated project, checks a Terraform plan in JSON against rules written in Rego before it is applied. A rules engine such as Cloud Custodian filters running resources on AWS, Azure and Google Cloud with YAML policies and applies actions; its documentation shows a policy that marks untagged EC2 instances and stops them later.
What it means for your cost
Enforcement at creation keeps allocation coverage stable as new teams, accounts and projects arrive. No mechanism in the table covers everything, so a sound setup combines a preventive rule for new resources, a detective check of the existing estate and measurement in money, as tag coverage and untagged cost describes.
Whether a tag must sit on the resource or only in the cost data decides the effort. For cost allocation, Azure's tag inheritance may be enough, and on Google Cloud inherited tags appear in the export. Automation and access rules, by contrast, read the tag on the resource. When a tag added later shows up in billing data differs by provider (tags and labels). How tagging fits into the policy as a whole is covered in cost governance policy: content and enforcement.
Where it goes wrong
- Enforced and still untagged. Symptom: the tag policy uses
enforced_for, yet resources without a cost centre keep appearing. Cause: the basic rules check only tags that are set and do not enforce missing keys. - Two casings despite an SCP. Symptom:
CostCenterandcostcenterboth appear in the data although an SCP requires the tag. Cause: key names in IAM conditions are not case sensitive. - Modify without remediation. Symptom: new resources carry the tag, older ones do not, and coverage stalls. Cause: existing resources change only through a remediation task with a managed identity.
- A rule for a single service. Symptom: Google Cloud VMs carry labels, other resources do not. Cause: a custom constraint applies only to the resource type it is written for.
- Inheritance mistaken for tagging. Symptom: cost analysis groups cleanly by tag, but an automation finds no tag on the resource. Cause: Cost Management's tag inheritance writes to the usage data, not to the resource.
Sources
Read on 2026-10-16. AWS tag policies, enforce tagging consistency, enforce "Required tag key" with IaC, report tagging compliance, service control policies, controlling access using tags and Config rule required-tags; Microsoft policy effect basics, modify effect, policy definitions for tagging resources, tag inheritance in Cost Management, Azure Policy as Code workflows and policy rule conditions; Google Cloud Compute Engine custom constraints, Organization Policy Service, restrict resource locations, tags overview, standard usage cost export structure and policy validation for Terraform; Open Policy Agent documentation and Terraform; Cloud Custodian project site and tag compliance across resources.