A tagging policy that lives in a wiki gets ignored. A tagging policy expressed as code, evaluated in the provisioning path, cannot be. Enforce tags with policy as code and untagged resources are blocked or flagged before they ever reach the bill, so coverage holds without anyone chasing it.
Learning how to enforce tagging with policy as code is what turns a tagging strategy from an aspiration into a guarantee. Policy as code means the rules for what a resource must look like, including its mandatory tags, are written as machine-evaluated code rather than human-read documentation, so they are checked automatically every time a resource is created or changed. Applied to tagging, this closes the gap that kills most tagging efforts: the gap between a policy people agree to and the untagged resources they create anyway. When the policy is enforced in code, a non-compliant resource is rejected or surfaced immediately, and cost allocation stays reliable by construction.
This article is part of the complete guide to cloud cost governance. The patterns below are how we enforce tagging across the 500-plus environments we have optimized since 2019, where the move from manual tagging to policy as code is consistently the step that takes coverage from patchy to dependable.
Manual tagging depends on every engineer remembering, every time, to apply the right tags with the right values. At any real scale that fails: resources are created in a hurry, by automation, or by people who never read the tagging doc. The untagged backlog grows faster than anyone can clean it, and the coverage number drifts down. The only durable fix is to remove the dependence on memory and put the check in the path itself, which is exactly what policy as code does.
Policy as code can act in two places, and a strong program uses both.
The earliest point to catch a missing tag is before the resource is ever created, in the infrastructure-as-code pipeline. Tools that evaluate policy against a plan, such as Open Policy Agent and the policy frameworks built into Terraform and similar tooling, can fail a deploy that would create a resource without its mandatory tags. This is the cheapest place to catch a violation because nothing has been provisioned yet, and it is the role policy as code plays in FinOps more broadly, covered in the role of policy as code in FinOps.
The pipeline only covers resources created through the pipeline. To catch everything, including resources created in the console or by other automation, enforce at the cloud platform itself. The major providers offer native mechanisms: AWS Tag Policies and Service Control Policies through Organizations, Azure Policy with deny and modify effects, and Google Cloud Organization Policy together with required-label checks. These evaluate at the control plane, so they apply regardless of how a resource is created. Because the exact capabilities and effect names change over time, confirm the current behavior in each provider's documentation before relying on a specific effect.
Native policies usually offer three strengths. Deny blocks a non-compliant resource outright. Modify or append can add a default tag automatically. Audit flags the violation without blocking. Start in audit to size the problem and avoid breaking deployments, then graduate the mandatory tags to modify or deny once teams have adjusted.
Switching straight to deny across an existing estate breaks deployments and turns the whole organization against the program. Stage it instead. Begin in audit mode so you can measure non-compliance without blocking anything, the same way you would in an audit of tag coverage across clouds. Use the audit findings to fix the worst gaps and give teams time to update their templates. Then move the mandatory tags to modify, so a default value is applied where one is missing, and finally to deny for the tags that genuinely must be present and correct. Each step tightens enforcement without a sudden outage.
Policy as code stops new violations; it does not retroactively tag what already exists. Treat the existing untagged estate as a one-time remediation project, tagging in bulk from ownership data where you can and accepting that a residual slice is genuinely untaggable. Decide how that untaggable remainder is allocated up front, using the approaches in cost allocation for shared and platform services, so it does not sit in an unowned bucket forever.
Enforce only the mandatory tags in code. The temptation is to encode the whole schema, but every additional enforced tag is another reason a deploy fails and another argument against the program. A tight set of deny-level tags plus a wider set of audited optional ones keeps enforcement credible and deployments unblocked.
When policy as code is working, new resources arrive correctly tagged because they cannot arrive otherwise, the coverage audit holds steady above target without manual chasing, and the few violations that appear are caught and routed automatically rather than discovered months later on an allocation report. The enforcement has moved from people to the platform, which is the only place it stays reliable.
We write and roll out the policy-as-code enforcement, staged from audit to deny, so untagged resources stop reaching your bill and allocation stays dependable. It is the Lock step of our method that keeps governance from drifting.
Get a FinOps implementation plan →Policy-as-code enforcement is what makes a tagging strategy durable. Read the complete guide to cloud cost governance for the full picture, see how to build a cloud tagging strategy that sticks for the schema it enforces, and download The Cloud Cost Governance and Tagging Toolkit for ready-to-use policy examples. When you want the enforcement built and staged for you, see our FinOps implementation service.
New commitment instruments, FOCUS changes, hyperscaler pricing shifts, and the plays that actually move a bill. No schedule, no filler.