Enforce tagging with AWS Service Control Policies by writing an SCP that denies the resource create action when a required tag is missing, using the aws:RequestTag and aws:TagKeys condition keys. Pair it with an AWS Organizations Tag Policy that standardizes the allowed keys and values, then roll the SCP out organizational unit by organizational unit, testing in a sandbox first and watching CloudTrail for AccessDenied events. Enforcing at creation is the only approach that keeps allocation complete, because every resource gets an owner the moment it exists instead of being chased down later.
Last updated: June 2026
A Service Control Policy (SCP) is an AWS Organizations permission guardrail that sets the maximum available permissions for the accounts it covers, including the root user. To enforce tagging, you write an SCP that denies the create action for a resource when a required tag key is not present in the request, which stops an untagged resource from ever being created. This is the See step of FinOps made enforceable: tagging that actually holds, so every dollar of spend has an owner and allocation does not leak.
This article is part of our governance, tagging and allocation cluster. For the full picture start with the complete guide to cloud cost governance, the pillar this piece links up to. Enforcement only works if the tag keys themselves are well chosen, which is covered in what is a tagging taxonomy and how to design one.
Can an SCP actually force tags on AWS resources?
Yes. An SCP can deny a resource create action when a mandatory tag is missing, using the global condition keys aws:RequestTag/key and aws:TagKeys to inspect the tags supplied in the request. Because SCPs apply to every principal in the covered accounts, including administrators and the root user, there is no privileged path around the guardrail. The condition keys and how SCPs evaluate them are documented in the AWS Organizations Service Control Policies guide.
What is the difference between an SCP and a Tag Policy?
An SCP is a permission guardrail that can deny actions, while a Tag Policy is a separate AWS Organizations feature that defines which tag keys and values are allowed and enforces consistent capitalization. The SCP enforces that a tag is present at creation; the Tag Policy enforces that its key and value are spelled and cased correctly. They are complementary, and a robust setup uses both, as described in the AWS Tag Policies documentation. Without the Tag Policy you can still end up with env, Env, and environment all in use, which fragments allocation just as badly as missing tags.
How do I enforce tagging with an SCP, step by step?
Follow these six steps to move from no enforcement to untagged creation being blocked across the organization.
- Define the mandatory tag keys. Pick the small, fixed set every resource must carry, typically owner, environment, and cost-center, drawn from your tagging taxonomy. Keep it short; each required key is a thing every pipeline must supply.
- Standardize allowed values with a Tag Policy. Create an AWS Organizations Tag Policy that lists the permitted keys and acceptable values and locks the case, so the SCP and your reports agree on what a valid tag looks like.
- Write the deny SCP. Author an SCP that denies the create actions you care about (for example ec2:RunInstances, rds:CreateDBInstance, s3:CreateBucket) when aws:RequestTag for a required key is null, using a Null or StringEquals condition per key.
- Test in a sandbox OU. Attach the SCP to a non-production organizational unit, then confirm a tagged launch succeeds and an untagged launch is denied. Verify both outcomes before going wider.
- Roll out by organizational unit. Expand to production OUs in stages. Watch CloudTrail for AccessDenied events to find pipelines, Terraform modules, and CI roles that still need to pass the tags, and fix them as you go.
- Monitor compliance and fix drift. Use AWS Config and Tag Policy compliance reports to find resources created before enforcement and remediate them, so the back catalogue gets tagged too.
Untagged spend you cannot pin to a team?
Our cost audit designs the tag taxonomy, writes and stages the enforcement SCPs and Tag Policies, and remediates the untagged back catalogue so allocation is complete across your accounts. On the performance model, you pay only from realized savings. No savings, no fee.
Book a cloud cost audit →Which resource create actions should the SCP cover?
Cover the create actions for the services that drive the bill and that support tag-on-create, then expand. EC2 instances, EBS volumes, RDS and Aurora databases, S3 buckets, load balancers, and EKS resources are the usual priority because they carry most spend. Not every API supports tagging in the create call, so check each service before adding it, and where tag-on-create is unsupported, rely on the Tag Policy plus a Config remediation rule instead of the SCP. Start with the high-cost services and widen the policy as you confirm each one tags cleanly at creation.
How do I avoid breaking pipelines when I turn enforcement on?
Stage the rollout and instrument it so you find non-compliant automation before it fails in production. Attach the SCP to a sandbox OU first, then to lower environments, and only then to production, watching CloudTrail AccessDenied events at each step to identify Terraform, CloudFormation, and CI roles that do not yet pass the required tags. Update those to set owner, environment, and cost-center as part of every resource definition. This staged approach is the same discipline we apply in how to implement policy as code for cloud cost guardrails, where guardrails are tested in CI before they ever reach a live account.
The Cloud Cost Governance and Tagging Toolkit includes a ready-to-edit tag-enforcement SCP, a Tag Policy template, and the rollout runbook. It is the downloadable companion to this article.
Frequently asked questions
Can an SCP force tags on AWS resources?
Yes. A Service Control Policy can deny the create action for a resource when a required tag is not supplied, using the aws:RequestTag and aws:TagKeys condition keys. This blocks untagged resources at creation rather than reporting them after the fact. The SCP sets the guardrail for every account in the organizational unit it is attached to, including the root user.
What is the difference between an SCP and a Tag Policy?
A Service Control Policy is a permission guardrail that can deny actions, so it can block creation of untagged resources. A Tag Policy is a separate AWS Organizations feature that defines which tag keys and values are allowed and standardizes their case, but does not by itself prevent creation. The two work together: the Tag Policy standardizes values and the SCP enforces presence.
Why enforce tagging at creation instead of cleaning up later?
Enforcing at creation keeps allocation complete, because every resource has an owner the moment it exists. Cleaning up later is slow, manual, and never catches everything, so untagged spend accumulates. Blocking untagged creation with an SCP is the only approach that holds the line without ongoing janitorial work.
Will an SCP break existing automation?
It can, if pipelines or infrastructure-as-code do not yet pass the required tags. That is why you test in a sandbox OU and watch CloudTrail for AccessDenied events before a wide rollout. Update Terraform, CloudFormation, and CI roles to set the mandatory tags, then expand enforcement by organizational unit.
The short version
Enforce tagging with AWS Service Control Policies by denying untagged resource creation with aws:RequestTag conditions, standardizing values with a Tag Policy, and rolling out organizational unit by organizational unit while watching for AccessDenied events. Enforcing at creation is what keeps allocation complete. When you want the taxonomy, the SCPs, and the remediation of the back catalogue done for you, that is exactly what our FinOps implementation service delivers.
Written by Morten Andersen and reviewed by Fredrik Filipsson, applying the See, Cut, Lock, Run method. Independent and vendor neutral.
Cloud pricing and service behavior change frequently. Verify the specifics in this guide against the providers’ own current documentation and the FinOps Foundation: AWS pricing ↗, AWS documentation ↗ and FinOps Foundation Framework ↗. This article also reflects Cloud Cost Room’s hands-on, vendor-neutral engagement experience.