Service Control Policies (SCP)

• SCPs are organization-level permission boundaries that define what IAM users and roles can do within accounts.

• They apply to member accounts only, not the Management Account (which always has full admin access).

• Evaluation is cumulative and hierarchical: an action must be explicitly allowed at every level from the root to the target account.

• If any SCP in the path explicitly denies an action, the action is blocked, even if allowed elsewhere.

• The default policy FullAWSAccess allows all AWS actions unless restricted by another SCP.

SCP Hierarchy – Example

OU (Root)

• Contains all OUs and accounts.

• Management Account: unaffected by SCPs.

OU (Sandbox)

• Policies: FullAWSAccess + Deny S3.

• Account A: Inherits Full AWS access but is denied S3 (Sandbox OU) and EC2 (account-level Deny).

• Account B & C: Inherit Full AWS access but are denied S3.

OU (Test)

• Policies: FullAWSAccess + Deny EC2.

• Account D: Access to all services except EC2.

OU (Workloads)

• Policies: FullAWSAccess.

OU (Prod)

• Policies: Allow EC2.

• Account E & F: Full AWS access inherited from parent OUs, including EC2.

Notes

• SCPs only set the maximum available permissions; IAM policies still control actual access.

• Explicit Deny always takes precedence over any Allow.

• SCPs are powerful for enforcing security guardrails across an AWS Organization.

SCP Strategies

• Blocklist Strategy:
• Begin with broad permissions (e.g., FullAWSAccess) and add explicit deny statements for specific services, actions, or regions.
• Best when most services should be available but you need to restrict a small subset.
• Example: FullAWSAccess + Deny s3:*.

• Allowlist Strategy:
• Start with a full deny baseline and explicitly allow only the services and actions you need.
• More restrictive and suitable for highly controlled environments.
• Example: Allow only ec2:* and s3:*.