Understanding AWS IAM Permission Boundaries
Understanding IAM Permission Boundaries: Defining Limits on User and Role Actions in AWS.
Hello! I'm Jay Tillu, an Information Security Engineer at Simple2Call. I have expertise in security frameworks and compliance, including NIST, ISO 27001, and ISO 27701. My specialities include Vulnerability Management, Threat Analysis, and Incident Response. I have also earned certifications in Google Cybersecurity and Microsoft Azure. I’m always eager to connect and discuss cybersecurity—let's get in touch!
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 AWSSets 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.
