IAM Policy Simulator

What this tool does

IAM Policy Viewer explains what one policy document says. It deliberately doesn't answer a different, more useful question: given everything attached to an identity, is a specific action on a specific resource actually allowed? This tool does that — paste in one or more identity-based policies (as if all attached to the same user or role), give it an action and a resource, and it applies AWS's own evaluation logic: an explicit Deny anywhere always wins, an explicit Allow somewhere is required otherwise, and everything else is an implicit deny.

What it evaluates, precisely

• Every statement across every policy pasted in is checked against the test action and resource, honoring Action/NotAction and Resource/NotResource — including what NotAction actually means, which is easy to get backwards: an Allow statement with NotAction: iam:* grants every action except IAM ones, not the reverse.
• Wildcards (* and ?) in actions and resources are matched the way AWS matches them. Action matching is case-insensitive (s3:getobject and S3:GetObject are the same action to AWS); resource matching is case-sensitive, since resource identifiers like S3 keys are.
• A statement with no Resource or NotResource element at all is treated as unrestricted for this evaluation, rather than excluded — a rare shape, but a valid one.

What it deliberately doesn't evaluate: Condition blocks

A matching statement with a Condition element is flagged, not silently counted toward the verdict. Evaluating a condition for real needs request context this tool has no way to know — the caller's source IP, whether MFA was present, the current time, a resource tag. Pretending to evaluate that would produce a confident-looking wrong answer, which is worse than admitting uncertainty. When a conditional statement could change the outcome, the verdict is "depends on a Condition" instead of a false Allow or Deny.

What's out of scope

This evaluates identity-based policies only — no resource-based policies (an S3 bucket policy, an SNS topic policy), no permissions boundaries, no service control policies. Per IAM Policy Basics, the three-rule core (deny by default, explicit allow required, explicit deny always wins) is enough to reason about correctly at this layer; once those other layers enter the picture — especially anything cross-account — the real evaluation order gets considerably more layered than a static tool with no AWS credentials can honestly simulate. See How AWS Evaluates Multiple IAM Policies for exactly what that layering looks like — which layers can grant access and which only narrow it, and why cross-account access needs an explicit allow from both accounts independently.

FAQ

Is this the same as AWS's real IAM Policy Simulator?

No — AWS's own IAM Policy Simulator (in the console) evaluates against your real account: actual attached policies, actual permissions boundaries, actual resource-based policies, and it can incorporate real condition context. This tool is an offline, credential-free approximation of the identity-based-policy layer only, useful for quickly checking a policy draft before it's ever attached to anything.

Why does it say "Denied" when I don't see an explicit Deny statement?

That's an implicit deny — nothing in any pasted policy has an Allow that matches your action and resource. IAM denies by default; a statement doesn't need to explicitly deny something for it to end up denied.

Can I build the policies here from scratch?

Use IAM Policy Generator to build a statement from plain fields, then paste the result in here to test it against a real action and resource.

What's a good policy to test first?

IAM Policy Examples has ten worth trying here directly — the explicit-deny-overrides-allow and MFA-required examples are particularly good demonstrations of what this tool actually does.

Is anything I paste here sent anywhere?

No — evaluation happens entirely in your browser. Nothing you enter here is ever sent to a server.