AWS IAM Policy Simulator

How AWS IAM Policy Evaluation Works — Complete Guide

Understanding how AWS evaluates IAM policies is critical for building secure cloud architectures. This simulator follows the evaluation logic AWS documents in the IAM User Guide, including resource control policies, session policies and cross-account rules, so you can test decisions and debug access issues before deploying. Use it to learn and pre-check, and confirm important decisions with the AWS IAM policy simulator or IAM Access Analyzer.

The AWS policy evaluation order

1. Explicit Deny: AWS checks every applicable policy (RCPs, SCPs, resource-based, identity-based, permissions boundaries and session policies). If any Deny statement matches, the request is denied.
2. Resource control policies (RCPs): if the resource’s account has RCPs and none allows the request, it is denied.
3. Service control policies (SCPs): if the caller’s account has SCPs and none allows the action, it is denied — for every principal in the account, including its root user. SCPs and RCPs do not apply to the organisation’s management account.
4. Resource-based policies: in the same account, a resource policy that names the caller can grant access on its own. Granting to an IAM user or a role session is not limited by the caller’s identity policies or permissions boundary; granting to a role ARN is still limited by a permissions boundary and session policy. Granting to the whole account only delegates — the identity policy must also allow.
5. Identity-based policies: if no attached policy allows the action, it is implicitly denied.
6. Permissions boundaries: if the user or role has a boundary that does not allow the action, it is denied.
7. Session policies: for role and federated sessions with a session policy, the session policy must also allow the action.

Role trust policies and AWS KMS key policies are special: the trust or key policy must allow the caller explicitly — an identity-based Allow alone is not enough.

Explicit Deny vs Implicit Deny — What’s the Difference?

An explicit deny is a matching statement with "Effect": "Deny". Nothing can override it. An implicit deny is simply the absence of an Allow — the default state — and a matching Allow in the right policy grants access.

How Conditions Are Evaluated

• All operators and keys in a Condition block must be true (AND). For one key with several values, the condition is true if the request matches any value — except negated operators such as StringNotEquals, which are true only if the request matches none of them.
• StringEquals, StringLike and ARN comparisons are case-sensitive; condition key names are not.
• If the key is missing from the request: positive operators are false, negated operators are true, …IfExists is true, and ForAllValues is true (a common trap — add a Null check).
• Policy variables such as ${aws:username} or ${aws:PrincipalTag/team} only work with "Version": "2012-10-17".

Cross-Account Access Rules

When a principal in account A accesses a resource in account B, both evaluations must allow it: the caller’s identity-based policy in account A and the resource-based policy in account B. An explicit Deny on either side wins. In the same account, a resource-based policy that names the caller can be enough on its own.

Common IAM Policy Debugging Patterns

• Access denied but the policy shows Allow: look for an explicit Deny elsewhere — an SCP, RCP, permissions boundary, session policy or the resource policy.
• Condition not matching: check the key name and value, letter case (StringEquals is case-sensitive), and whether the key is actually present in that request.
• S3 access denied cross-account: the bucket policy must name your principal or account AND your identity policy must allow the S3 action on that bucket. KMS-encrypted objects also need the key policy to allow you.
• Role can’t do what the user can: check the role’s permissions boundary and any session policy passed when it was assumed.

Frequently Asked Questions