Free — no signup required

Control Tower Guardrails vs. SCPs: Understanding the Difference

2 min read

Two Enforcement Mechanisms, One Goal

Control Tower uses the term Guardrails as an abstraction over two underlying enforcement mechanisms. Understanding the distinction matters when you are debugging why something is blocked or when you need to write custom controls.

Preventive Guardrails are implemented as SCPs. They prevent non-compliant actions from happening at all. Example: "Disallow changes to CloudTrail logging." If a developer tries to run cloudtrail stop-logging, the API call is rejected before it executes.

Detective Guardrails are implemented as AWS Config Rules. They detect non-compliant configurations after the fact and report them in the Control Tower dashboard. Example: "Detect whether MFA is enabled for the root user." Config evaluates this periodically and flags violations, but it does not prevent the non-compliant state from existing.

The practical implication: Preventive guardrails are hard stops. Detective guardrails are audit findings. For security-critical controls (disabling logging, leaving the organization, creating IAM users with console access), use preventive guardrails. For configuration drift that is expensive to prevent (e.g., "all S3 buckets should have versioning"), detective guardrails give you visibility without blocking legitimate workflows.

Mandatory vs. Strongly Recommended vs. Elective:
- Mandatory: Always enabled by Control Tower. Cannot be disabled. Example: disabling CloudTrail.
- Strongly Recommended: Enabled by default but can be disabled. Example: detecting public S3 buckets.
- Elective: Opt-in. Example: requiring EC2 instances to use approved AMIs.

This is one of 18 chapters

Get every chapter — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

See pricing