AWS judges each request by combining several policy types. Identity-based and resource-based policies add up, while permissions boundaries and organization policies narrow what is possible. An explicit deny in any of them overrides every allow. If nothing allows the request, it is denied by default.
Union and intersection
Most confusion comes from two words. AWS documents how the policy types combine:
- Identity-based plus resource-based, same account. The result is the union. If either allows the action, it is allowed, unless something denies it.
- Identity-based plus a permissions boundary. The result is the intersection. The action must be allowed by both.
- Identity-based plus service control policies or resource control policies. Again the intersection. The action must be allowed by the identity policy, the SCP and the RCP.
An explicit deny in the identity policy, the resource policy, the boundary, an SCP or an RCP overrides any allow.
A worked example
A developer role has an identity policy that allows s3 actions on all buckets. The role also has a permissions boundary that allows only EC2 and CloudWatch. What can the role do with S3?
Nothing. The identity policy allows it, but the boundary does not, and the result is the intersection. The same logic applies when an SCP at the organization level does not allow S3.
Now flip it. A bucket policy allows the role to read objects, and the role's identity policy says nothing about S3. In the same account, the union applies, so the read is allowed, provided nothing denies it and any SCP above the account allows it.
What each layer is for
- Identity policy: Grants permissions to a user or role
- Resource policy: Grants permissions on a resource, such as a bucket
- Permissions boundary: Sets the maximum an identity can have
- SCP and RCP: Set guardrails for accounts in an organization
Boundaries and SCPs never grant anything. They only limit. Granting always comes from an identity or resource policy.
Debugging a surprising denial
Work from the outside in:
- Is there an explicit deny anywhere? Check SCPs, RCPs, the boundary, the identity policy and the resource policy.
- Does the organization allow the action at every level above the account?
- Does a boundary allow it?
- Does something actually grant it, in an identity or resource policy?
AWS also notes that you can see whether your account belongs to an organization with the describe organization action, and that you may need your organization administrator to tell you whether an SCP is the cause.
Design tips that follow
- Use explicit deny sparingly and put it where it is meant to be absolute, such as an SCP that blocks a region you never use.
- Keep boundaries for delegated admin scenarios, where you let teams create roles but cap what those roles can do.
- Write down which layer owns which decision, so a denial points to one place.
Quick check
If two policies conflict, which wins?
If either contains an explicit deny that matches the request, deny wins. Otherwise the request needs an allow from the right policy types.
Can an SCP give a user access?
No. An SCP only limits what identities in the account may be granted. The permission itself must come from an identity or resource policy.
Sources
Last reviewed: 19 October 2026.
