AWS Organizations Service Control Policies

Definition

Service Control Policies (SCPs) are organization-level permission guardrails attached to the root, organizational units (OUs), or individual accounts in AWS Organizations. SCPs do not grant permissions — they define the maximum actions accounts in that scope can ever perform, even if an IAM policy allows them. Effective permission is the intersection of IAM policies and all inherited SCPs. SCPs use the same JSON policy grammar as IAM but support only Deny effects (and limited Allow patterns for exceptions). They are the primary preventive control in multi-account landing zones.

When to use it

• Prevent disabling audit/logging — deny cloudtrail:StopLogging, config:StopConfigurationRecorder, or deletion of log groups.
• Region allow-lists — restrict prod workloads to approved regions for data residency.
• Block public exposure patterns — deny creation of unencrypted resources or public RDS instances where policy supports it.
• Protect security tooling — deny removal of GuardDuty, Security Hub, or centralized firewall admin roles.
• Sandbox guardrails — deny expensive instance families or root access key creation in non-prod OUs.

When not to use it

• Granting access to users — SCPs are not a replacement for IAM; you still need roles, permission sets, and resource policies.
• Application-level authorization — SCPs affect AWS API calls, not in-app RBAC.
• Overly broad Deny on day one — locking down prod before IAM and OU structure are stable breaks deployments and erodes trust with app teams.

Tips

• Design OU hierarchy first, then attach SCPs at the OU level — accounts inherit parent SCPs; child OUs add stricter layers.
• Use Allow-list SCP patterns for region control (deny all except listed regions) rather than ad-hoc per-service denies.
• Maintain a break-glass account outside restrictive SCPs for emergencies — document and monitor it heavily.
• Test SCP changes in a non-prod OU; SCP denies surface as opaque AccessDenied errors in application logs.
• Log and alert on SCP denials via CloudTrail — spikes often reveal a misconfigured deployment pipeline.

Gotchas

Serious

• SCP Deny blocks IAM Allow — teams spend hours debugging IAM when the SCP on the OU is the actual blocker.
• Forgetting the management account — SCPs do not restrict the management account itself the same way; protect it separately.
• Deny without exception for break-glass roles — you can lock out your own security team during an incident.

Regular

• Confusing SCPs with permission boundaries — permission boundaries cap a single role/user; SCPs cap entire accounts.
• Duplicate conflicting SCPs — multiple attached SCPs combine; unintended Deny overlap is hard to trace without policy simulation.
• Using SCPs for cost optimization alone — instance-type denies help, but FinOps still needs budgets and tagging enforcement.

Official references

• Service control policies (SCPs)
• SCP effects on permissions
• AWS Organizations
• Testing SCPs with IAM policy simulator

Related FactualMinds content

• Service Control Policies: AWS Governance Guide
• AWS Cloud Security Services
• Cloud Compliance Services