What is Service Control Policy (SCP) enforcement in AWS Organizations?

Service Control Policies (SCPs) are organization‑level guardrails that limit the maximum permissions any AWS Identity and Access Management (IAM) principal can obtain, and they are enforced by the AWS Organizations control plane at request evaluation time.

Enforcement workflow
1. Define the policy – write a JSON document using the IAM policy syntax, e.g. a Deny statement for s3:* on all resources.
2. Create the SCP – aws organizations create-policy --content file://scp.json --description "Block S3" --name BlockS3 --type SERVICE_CONTROL_POLICY.
3. Attach to a target – root, OU, or individual account with aws organizations attach-policy --policy-id p-xxxxxx --target-id ou-1a2b-3c4d5e6f.
4. Request evaluation – when a principal issues an API call, Organizations checks every SCP attached to the principal’s account hierarchy; any matching Deny returns AccessDeniedException before IAM policies are consulted.
5. Validate effective permissions – combine aws organizations list-policies-for-target with aws iam simulate-principal-policy --policy-source-arn arn:aws:iam::123456789012:user/JohnDoe to see the net allowed actions.

SCP vs IAM policy
| Aspect | SCP | IAM Policy |
|---|---|---|
| Scope | Organization/OU | Account/Principal |
| Effect model | Implicit allow, explicit deny | Explicit allow/deny |
| Evaluation order | Pre‑check (guardrail) | Post‑SCP check |
| Management UI | Organizations console, list-policies CLI | IAM console, list-policies CLI |

CLI example

aws organizations attach-policy \
    --policy-id p-12345678 \
    --target-id ou-1a2b-3c4d5e6f

Gotcha: SCPs do not revoke permissions that are already baked into active temporary credentials; they only affect subsequent API calls, so rotate credentials after tightening an SCP.