Understanding AWS IAM Permission Boundaries

Arjun is a cloud engineer at a fast-growing startup. His manager tells him:

"We need to give developers more power. Let them manage users and resources themselves.
But make sure they can't do anything dangerous — like making themselves admins."

Now Arjun is confused.
“How do I give access but also set a limit on what they can do?”

That’s when he discovers… IAM Permission Boundry

🎯 What is a Permission Boundary?

IAM Permission Boundaries are like setting the fence around what a user or role can do — even if they’re given bigger permissions.

A permission boundary is like a safety limit.

Let’s say you give someone a car that can go 200 km/h (IAM policy).
But then you install a speed limiter that won't let it go over 80 km/h.
That limiter is the permission boundary.

So even if the driver (IAM user) has access to everything, the boundary decides the actual maximum.

🧠 Key Points

Applies only to IAM Users and IAM Roles.
It's an extra policy attached to the user/role.
The user’s final permissions =
What’s allowed by both the IAM policy AND the permission boundary.

🔍 Simple Example

Arjun creates a new IAM user named John.

He does 2 things:

Gives John AdministratorAccess
✅ Can do anything on AWS
Sets a Permission Boundary for John:
✅ Allows only AmazonS3FullAccess

What happens now?

Even though John has AdminAccess,
because of the boundary, he can only work with S3.

❌ No EC2
❌ No IAM
✅ Only S3

The boundary wins.

❓If I Can Restrict Access in IAM Policies...

...Then Why Do I Need Permission Boundaries?

Because IAM policies control what a user has access to,
but permission boundaries control what a user can ever be given access to — even by someone else later.

Let’s look at two use cases to make it super clear.

🧠 Example 1: Without Permission Boundary

Imagine you're creating a developer IAM role and you attach this policy:

Allow: ec2:DescribeInstances

✅ The role can only describe EC2 instances.
But — any admin or script can later attach a new policy to this role like:

Allow: iam:CreateUser, ec2:TerminateInstances

Boom 💥 — now the developer has too much power.

🔒 Example 2: With Permission Boundary

Now you create the same role, but you also attach a permission boundary that says:

Allow: ec2:DescribeInstances only

Even if someone attaches a new IAM policy that says:

Allow: iam:CreateUser

🚫 It won’t work.

Because that permission is outside the boundary.

🧩 Where Does it Fit in IAM Security?

Arjun learns that AWS has multiple security layers working together:

Layer	What it does
✅ IAM Policy	Gives permissions
🚫 SCP (Service Control Policy)	Org-wide guardrails
🚫 Permission Boundary	User/role-specific limits
🚫 Resource Policy	Who can access the resource
🚫 Session Policies	Temporary, session-based limits

To allow an action, it must be:

Allowed by IAM policy
Within the permission boundary
Allowed by SCP
Not explicitly denied anywhere

So it’s like a team effort — and even one deny can block the action.

💡 Real-Life Use Cases

Let developers create IAM users,
but stop them from giving admin rights.
Let junior engineers use EC2,
but stop them from touching IAM, S3, or billing.
Give self-service power,
while staying within strict limits.

🧪 Quiz Time – Just for Practice

🟡 Question:
If a policy allows sqs:DeleteQueue,
but another part of the policy explicitly denies sqs:*,
can you delete a queue?

🔴 Answer: No.
Because explicit deny always wins over allow.

🎬 Final Thoughts

Permission boundaries are a powerful feature in AWS IAM.

They let you:

Empower users and teams
Delegate access safely
Keep your cloud secure

Think of them as invisible fences — users can roam, but only inside the safe zone.

📌 Summary

Concept	Think of it as…
IAM Policy	What you allow someone to do
Permission Boundary	The outer wall — max possible scope
Effective Access	The overlap of both

If you're preparing for the AWS SAA exam, remember this:

IAM permission boundaries are NOT about giving access.
They're about setting the maximum limit for what access can be given.