SCP vs Tag Policy: AWS Tagging Governance Comparison

The Tagging Governance Gap

In multi-account AWS environments, inconsistent tagging destroys cost allocation accuracy, security automation, and compliance reporting. Manual tagging approaches fail at scale-engineers forget tags, automation tools bypass standards, and shadow IT creates untagged resources. AWS Organizations provides two policy mechanisms, but misapplying them creates governance blind spots.

SCPs operate as identity-based guardrails, evaluating API requests before resource creation. They enforce presence but cannot validate value formats or case consistency. Tag Policies operate as resource-based validators, checking compliance after creation and supporting complex validation rules, but cannot prevent resource launch when enforcement is disabled.

Core Technical Distinctions

Service Control Policies (SCPs)

SCPs are explicit-deny policies attached to OUs or accounts that filter API calls made by IAM principals. For tagging, they use aws:RequestTag and ec2:ResourceTag condition keys to block resource creation when required tags are absent.

Key Characteristics:

• Evaluation Point: Pre-creation API request filtering
• Scope: All AWS services and actions (broad coverage)
• Enforcement: Binary—denies or allows; no partial compliance
• Latency: On error, it takes time to understand why did we get an error (need to evaluate SCP's and understand which one blocked the request).
• Limitations: 5 SCPs per OU/account, 5,120-byte size limit

Example SCP Blocking Untagged EC2 Instances:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyUntaggedEC2",
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "arn:aws:ec2:*:*:instance/*",
            "Condition": {
                "Null": {
                    "ec2:ResourceTag/Environment": "true"
                }
            }
        }
    ]
}

Tag Policies

Tag Policies are JSON documents defining tag schema rules, attached to OUs or accounts. They validate tag keys, values, case treatment, and can enforce compliance on supported resource types.

Key Characteristics:

• Evaluation Point: Post-creation validation and compliance reporting
• Scope: 50+ AWS services with enforced_for support (limited coverage)
• Enforcement: Optional—can operate in report-only or enforcement mode
• Latency: The time it takes to remediate
• Capabilities: Value pattern matching, case enforcement, tag key standardization

Example Tag Policy Enforcing CostCenter Values:

{
    "tags": {
        "CostCenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": ["HR", "Legal", "Engineering"]
            },
            "enforced_for": {
                "@@assign": ["ec2:instance", "rds:db"]
            }
        }
    }
}

Key Characteristics Comparison

Here's a side-by-side comparison of the key characteristics between SCPs and Tag Policies:

When to Use Each Approach

So which one to use when? Let's take a look at some scenarios:

The right way to implement tagging in your AWS Environment is to use them together in a layered approach:

Layered Policy Approach

Root Level:

• Mandatory Tags SCP: Block untagged resource creation for critical tags only (Environment, DataClassification)

OU Level (Tag Policies):

• Development OU: Enforce Environment=dev, CostCenter, ProjectID with value validation
• Production OU: Enforce Environment=prod, DataClassification, Compliance with case sensitivity

Implementation phases:

1. Phase 1: Deploy Tag Policies in report-only mode for 30 days to baseline compliance
2. Phase 2: Enable enforcement on Tag Policies for supported services (EC2, RDS, S3)
3. Phase 3: Deploy SCPs for critical tags that cannot be enforced via Tag Policies (EMR, Lambda, cross-service)
4. Phase 4: Monitor CloudTrail ServiceEventDenied events to tune false positives
5. Phase 5: Implement automated remediation via AWS Config rules for existing non-compliant resources

What to Avoid?

Over-Specific Tag Enforcement

SCPs cannot validate regex patterns or enumerated values. Attempting to enforce CostCenter format via SCP requires multiple StringNotLike conditions, hitting the 5,120-byte limit quickly.

Blocking Tag Deletion with SCPs

While possible, using SCPs to prevent ec2:DeleteTags creates operational lock-in. Tag Policies' native tag retention capabilities are more maintainable.

Service-Specific SCPs for Tagging

Creating separate SCPs per service wastes quota. Combine related services into single SCP using Resource element wildcards where possible.

Tag Policy Limitations

• Enforcement Gaps: Tag Policies validate tags on the master resource, not auto-created sub-resources. EMR clusters launching EC2 instances propagate tags inconsistently—SCPs are required for sub-resource enforcement.
• Partial Service Coverage: Only 50+ services support enforced_for. Services like Lambda, EMR, and many container services require SCP fallback which might be disruptive and not user friendly.

Conclusion

SCPs and Tag Policies are not interchangeable—they are complementary governance layers. SCPs provide hard guardrails preventing resource launch without mandatory tags, essential for security and compliance boundaries. Tag Policies provide soft governance ensuring tag consistency and value standardization, critical for cost allocation and automation.

The critical insight: Use SCPs to enforce tag existence on critical resources (production workloads, data stores, security services) where launch prevention is non-negotiable. Use Tag Policies to enforce tag quality (value formats, case sensitivity, schema compliance) across all resources where reporting and gradual remediation suffice.

Your tagging strategy should be layered, not monolithic. Start with Tag Policies in audit mode, add SCPs for critical tags, and refine based on real-world developer feedback. This approach prevents governance from becoming a deployment bottleneck while maintaining security and cost management integrity.