How AWS IAM Permission Evaluation Really Works

AWS doesn't randomly block you. It runs your request through a security gauntlet — and you need to pass every single checkpoint: SCP → Permission Boundary → Explicit Deny → Allow → Implicit Deny.

AWS doesn't randomly block your API requests. Every single call runs through a strict evaluation gauntlet — and you need to pass every single checkpoint.

Think of it like airport security. Miss one check? You're not getting through. ✈️

⚡ Key Highlights & Evaluation Pipeline

🛡️ 1. SCP (Service Control Policies) → Organization-wide guardrails
🚧 2. Permission Boundary → Maximum allowed permission ceiling
⛔ 3. Explicit Deny Check → The nuclear option overriding all allows
✅ 4. IAM Policy Allow → Identity & Resource explicit permission grant
🔒 5. Implicit Deny → Default fallback state if no allow exists

Core Principles & Guardrails

Rule 1

SCPs = Org Guardrails (Can't be bypassed)

Rule 2

Explicit DENY always wins (No overrides)

Rule 3

No explicit Allow? Default Deny kicks in

Step-by-Step Evaluation Flow

Step 1: Check SCPs at the AWS Organization level
Step 2: Check Permission Boundaries assigned to the IAM entity
Step 3: Evaluate for any Explicit DENY statements anywhere
Step 4: Search for an Explicit ALLOW in Identity-based or Resource-based policies
Step 5: If no ALLOW is found, evaluate as Implicit Deny

💣 The plot twist? An explicit DENY always wins. No exceptions. No overrides. Not even root can escape an explicit DENY statement once it is triggered.

Real-World Scenario Checklist

SCP: Allowed (Passes Organization check)
Permission Boundary: Allowed (Passes boundary ceiling check)
No Explicit DENY in sight (Passes negative check)
IAM Policy: Allowed (Passes explicit authorization grant)

Pass every single gate — or access is immediately DENIED!
Flipping any single gate to ❌ stops the request cold, even for administrator roles.

Evaluation Pillars & Controls

🛡️

SCPs (Service Control Policies)

Your organization's guardrails that apply across member accounts. They cannot be bypassed by any IAM user or root user in linked accounts.

🚧

Permission Boundaries

Set the hard limits on what an IAM entity (User or Role) can possibly do, regardless of what attached policies allow.

☢️

Explicit Deny

The nuclear option. A single explicit Deny in any applicable policy immediately stops evaluation and denies access.

🔒

Implicit Deny

AWS IAM defaults to deny for all requests unless an explicit Allow is present.

Common Gotchas & Edge Cases

Assuming AdministratorAccess bypasses SCPs (It doesn't!).
Forgetting resource-based policies (e.g., S3 Bucket Policies, KMS Key Policies).
Not accounting for Session Policies when assuming IAM roles.

Summary & Takeaways

Understanding the IAM evaluation gauntlet is the difference between guessing why an API call failed and diagnosing permissions in 30 seconds.

Remember: Pass every gate — or access denied. And an explicit DENY always wins!