Day 9: IAM Groups and Permission Boundaries – Team Access Without Chaos

It’s been a couple of days since my last blog.
I got busy into experimenting with S3 — exploring storage classes, bucket policies, and even prepping a static website (more on that soon).

So I didn’t get time to continue with IAM... until today.

---

Why IAM Groups & Boundaries?

Today I tackled something that would matter if I ever work in a team:
How do I give multiple users access without repeating permissions for each?

That’s where IAM Groups and Permission Boundaries come into play.

---

What I Did Today

Created IAM Groups

I created a group called ReadOnlyDevs and attached the AmazonEC2ReadOnlyAccess and AmazonS3ReadOnlyAccess policies.

Then I created two IAM users — just test accounts — and added them to the group.

Boom — both users now had the same read-only access, instantly.

No repeated policy assignments. No mistakes. Just clean delegation.

---

Explored Permission Boundaries

This one was trickier to grasp, but here’s how I understood it:

A permission boundary is like a ceiling — even if a user or group has wide permissions, the boundary limits how far they can go.

So I:

• Created a custom permission boundary that allowed S3 read-only access only to a specific bucket

• Attached it while creating a new IAM user

• Gave that user a broader policy than the boundary would allow

Result: The boundary overruled the policy. That user couldn’t go beyond the limit. Cool. ✅

---

Why This Matters?

• IAM Groups = Less work, more consistency

• Permission Boundaries = Safety net for delegated permissions

• Together, they let you scale access without giving away full control

---

What Confused Me?

• You can attach policies to groups, but not permission boundaries

• Permission boundaries are per user or role, not groups

• If a policy allows something but the boundary doesn't, access is denied

So, policies grant power, boundaries restrict it — both must agree.

---

What I Learned

• Create groups early — saves time later

• Use permission boundaries when giving power to others (like account admins)

• Always test new IAM setups with low-impact users first

---

What’s Next?

I want to shift gears now. IAM was essential, but a bit heavy.
Next, I’m planning to write about:

• Hosting a static website on S3

• Comparing that with EC2

• Exploring bucket policies vs IAM policies

---

Final Thought

IAM is like setting up rules before a party starts.
Everyone needs an invite — but not everyone needs access to the kitchen, bedroom, and basement.

IAM groups and boundaries? They’re the bouncers.

Let’s go back to something visual next.

Day 10 loading...