AWS Service Control Policies: Guardrails That Actually Hold
How to design SCPs that prevent real incidents without blocking engineers — with copy-pasteable policy patterns.
RAZR Advisory
6 min read
Why SCPs matter
IAM policies control what a principal can do. Service Control Policies control what an account is allowed to attempt. When designed well, SCPs stop entire categories of incidents — public S3 buckets, disabled CloudTrail, root key creation — before they happen.
The four guardrails every org needs
- Prevent CloudTrail tampering — deny
cloudtrail:StopLogging,DeleteTrail,UpdateTrailoutside the security account. - Block public S3 exposure — deny
s3:PutBucketPublicAccessBlockchanges that weaken defaults. - Region lockdown — deny actions outside approved regions to shrink blast radius and data-residency risk.
- Root user protection — deny all actions when
aws:PrincipalArnmatches the account root.
Rollout without breaking builds
Deploy SCPs in audit mode first via CloudTrail analysis, then flip to deny. Pair with a break-glass OU that bypasses guardrails for genuine emergencies — logged, alerted, time-boxed.
Common mistakes
- Attaching everything to the root OU on day one
- Forgetting that SCPs do not grant permissions
- Skipping the
aws:ViaAWSServicecondition and breaking service-linked roles