How SCPs Combine with IAM Policies

When a request is made within a member account, AWS effectively evaluates it against two layers: first, do the applicable SCPs (from the account itself, its OU, and every parent OU up to the organization root) even allow this action to be possible at all — if any SCP in that chain explicitly denies it, or if no SCP in the chain allows it (SCPs use an implicit-deny-by-default model once any SCP is attached), the request is blocked immediately, regardless of IAM. Second, and only if the SCP layer permits it, the account's own IAM policies are evaluated normally to determine whether this specific identity actually has permission.

This means an SCP functions as a ceiling, not a grant: attaching an SCP that allows S3 and EC2 actions doesn't itself give any user permission to use them — it just means IAM policies within that account are now capable of granting S3/EC2 access if they choose to; without a matching IAM policy, the action is still denied, just for the ordinary IAM reason rather than an SCP reason.

A common practical pattern is a 'default allow' baseline SCP at the organization root (allowing everything, functionally a no-op in terms of restriction) with progressively more restrictive SCPs attached to specific OUs where genuine limits are needed (e.g. a Sandbox OU denying expensive instance types, or a Production OU denying the ability to disable logging) — rather than trying to enumerate every allowed action explicitly at the root, which becomes unwieldy to maintain as the organization's actual needs evolve.