Resource Tagging

Resource Tagging is the practice of labeling AWS resources with key-value metadata. Tags are fundamental to security governance at scale.

Security Use Cases

• Attribute-Based Access Control (ABAC): IAM policies that grant/deny access based on tags (e.g., aws:ResourceTag/Environment = Production)
• Cost Allocation: track security spending by team, project, or compliance requirement
• Compliance Scoping: tag resources as PCI=true or HIPAA=true for audit
• Automation: target patching, backup, and remediation based on tags
• Ownership: identify who owns and is responsible for each resource

Enforcement

• Tag Policies: enforce tag keys and allowed values across AWS Organizations
• SCPs: deny resource creation without required tags
• Config Rules: detect resources missing required tags
• Service Catalog: enforce tags at provisioning time

How It Goes Wrong in Practice

The moment tags start deciding permissions, the ability to write tags becomes a permission-granting power, and that is the part most ABAC rollouts miss. If your policies allow production access only when aws:ResourceTag/Environment equals Production, then anyone holding ec2:CreateTags or ec2:DeleteTags on those resources can flip the label and change the access outcome. Tagging permissions must be governed as strictly as the access they gate: constrain who can tag, and constrain which keys and values they can write using aws:RequestTag and aws:TagKeys conditions. AWS documents one trap explicitly: do not try to control who can pass a role by tagging the role and matching it with a ResourceTag condition on iam:PassRole, because that approach does not produce reliable results.

The second failure is case chaos. Condition key names in IAM policies are not case sensitive, so a condition on aws:ResourceTag/Owner matches a tag key of Owner or owner, but not both keys existing as separate tags with different values, which some services happily allow (an instance tagged both stack=production and Stack=test). The documented defense is to standardize keys with tag policies in AWS Organizations and to use ForAllValues with aws:TagKeys so requests can only apply the exact keys you allow. Third, the silent mismatch: ABAC conditions simply do not match untagged resources, so an unlabeled resource falls outside every tag-scoped allow, and access "mysteriously" fails, or worse, a tag-scoped deny fails to catch it.

A Practical Check

Audit what is actually tagged, across services, with the Resource Groups Tagging API:

aws resourcegroupstaggingapi get-resources --tag-filters Key=Environment,Values=Production --resource-type-filters ec2:instance

Drop the --tag-filters option to list resources with their tags and hunt for the untagged and the miscased. The --resource-type-filters value takes the service:resourceType format, so s3:bucket or plain ec2 for everything in EC2. Pair this with a policy pattern from the IAM documentation to enforce tag hygiene at creation time: require aws:RequestTag values from an allowed list, and add a Null condition on aws:TagKeys so requests without tags are rejected outright.

Frequently Asked Questions

Which condition keys drive tag-based access control? Four global keys do the work: aws:ResourceTag/key-name checks tags on the resource being accessed; aws:RequestTag/key-name checks tag values being applied in a request; aws:TagKeys constrains which tag keys a request may contain; and aws:PrincipalTag/key-name matches tags on the calling user or role, which is how you express "engineers may only touch resources tagged with their own team".

Are tag comparisons case sensitive? The condition key name portion is not: a policy condition on aws:ResourceTag/Owner matches the tag key owner too. That leniency cuts both ways, since services can hold two tags differing only by case. Enforce a single casing convention through tag policies rather than hoping every team remembers it.

How do I stop people from creating resources without required tags? Layer three mechanisms: an IAM or SCP condition requiring specific aws:RequestTag keys on create actions (with a Null check on aws:TagKeys to reject untagged requests), tag policies to standardize keys and values organization-wide, and AWS Config rules as the detective backstop that flags anything that slipped through, since not every API path supports tag-on-create conditions.

Are there limits on tag policies themselves? Tag policies are a distinct policy type in AWS Organizations with their own quotas: an organization can hold up to 1,000 tag policies, each document up to 10,000 characters, and up to 10 tag policies can be attached directly to the root, to each OU, and to each account. Organizations entities (roots, OUs, accounts) can each carry up to 50 tags of their own, so tagging governance applies to the account structure as well as to the resources inside it.