How SCPs Combine with IAM Permissions

Access in an organization is governed by two layers: the SCP ceiling set by AWS Organizations and the IAM permissions granted within the account. Understanding how they combine is one of the most testable ideas in the governance domain, because the outcome depends on both agreeing.

The rule is simple but strict: an action is allowed only if it is permitted by both the applicable SCPs and the account's IAM policies. The effective permission is the intersection. An SCP without a matching IAM allow grants nothing; an IAM allow blocked by an SCP grants nothing.

If the SCP permits an action but no IAM policy grants it, the result is denied by IAM's implicit deny. The SCP only made the action possible; IAM still has to actually grant it. Many learners forget the SCP is a ceiling, not a grant.

Conversely, if an IAM policy allows an action but an SCP denies it, the result is denied. The SCP's deny caps the account regardless of how generous IAM is. This is how an organization enforces hard limits that local administrators cannot override.

Only when both the SCP and an IAM policy allow the action, and no explicit deny exists anywhere, is the request allowed. This intersection logic mirrors how permission boundaries work, and both can apply at once, narrowing permissions further.

In a fully governed environment several caps stack: the SCP (account level), the permission boundary (identity level), any session policy (session level), and the identity policy (grant). The effective permission is the intersection of all caps plus the grant, minus any explicit deny.

Imagine an IAM policy granting s3:* and ec2:*, a permission boundary allowing s3:* only, and an SCP allowing s3:GetObject only. The effective permission is just s3:GetObject, the intersection of all three layers. Each cap shaves the permissions down further.

Across every layer, an explicit Deny in any policy, SCP, boundary, session, identity, or resource, immediately blocks the action. No combination of allows can override it. When analyzing a scenario, scan for any explicit deny first; if found, the answer is deny.

Resource-based policies can grant same-account access independently of the identity policy, but SCPs still cap the principal's account. For cross-account access, both accounts' controls and both sides' policies apply. The intersection rule expands but the core idea holds: every applicable cap must allow.

When access fails unexpectedly in an org, work outward: confirm the identity policy grants the action, then check the permission boundary, then the SCPs on the account and every parent OU, then any session policy, and finally scan all layers for an explicit deny. The first cap that omits the action, or any deny, is your culprit.

SCPs and IAM combine by intersection: an action needs an allow from both, plus any boundary and session caps, with no explicit deny anywhere. SCPs and boundaries only limit; IAM policies grant. To allow an action, every cap must permit it and at least one grant must exist.

Test the combination logic.

SCPs and IAM combine by intersection: an action is allowed only if both permit it, plus any permission boundary and session policy caps, with no explicit deny anywhere. SCPs and boundaries only limit; IAM policies grant. An explicit deny in any layer always wins over every allow.