Can I? An Interactive AWS Permission Evaluator

Every so often someone on the team asks the same question in a slightly different shape. “Why can’t this role read that bucket?” “Will this Lambda be allowed to write to the table?” “We added the bucket policy, why is it still AccessDenied?”

The answer is almost always in the interaction between six things: the IAM identity policy, the permission boundary, the resource-based policy, the SCP, the RCP, and for encrypted resources the KMS key policy. Each one can independently sink a request, and a few of them interact in ways that are counterintuitive.

I had written all of this up as notes. A wall of rules is hard to internalise, so I turned it into something you can poke at.

→ Try the evaluator

What it does

You set the scenario with toggles: service, same-account or cross-account, encryption, and the state of each policy. The page then draws a live diagram of the request. Nested boxes are policy scopes; SCP and RCP wrap the account, and the permission boundary and the identity and resource policies wrap the principal and the resource. Press Run request and a dot travels from the role to the resource and stops, pulsing, at the gate that decides the outcome. A gate-by-gate table and a one line deciding rule explain why.

It is a teaching tool. Flip one switch and watch the verdict change.

The corners worth playing with

These are the ones people get wrong, and they are worth setting up yourself.

• Implicit vs explicit deny in a permission boundary. Same-account, a resource-policy grant overrules an implicit deny in the boundary (the action simply isn’t in its allow set), but it can never override an explicit Deny. Flip the boundary between “Silent” and “Explicit Deny” and the verdict flips with it.
• Cross-account needs both sides. Same-account is generous; an IAM Allow on the role is often enough. Cross-account is not: you need an IAM Allow and a resource-policy grant. The request has to clear a gate on each side of the account gap.
• aws/s3 can not go cross-account. The AWS managed S3 key silently makes cross-account access impossible, and the evaluator calls it out.
• A CMK is deny-by-default. Same-account buys you nothing with a customer managed KMS key; the principal has to be enumerated in the key policy. IAM alone never opens it.
• SCPs and RCPs can not be bypassed. A resource-policy grant can paper over an implicit boundary deny, but never an SCP or RCP block.

Why a diagram and not a blog post

I nearly published the rules as prose. But authorization is a path: a request either makes it through every gate or it does not, and the interesting part is always which gate stopped it. A diagram that animates that path teaches the mental model in a way a table does not. The underlying logic is the same one I packaged as a reusable agent skill; this is its clickable face.

If you find a scenario it gets wrong, I’d like to hear about it.