Security Best Practices – My Checklist Before I Move On

IAM was a bit of a maze at first — users, roles, policies, permissions...
But after messing around with it for several days, I feel way more confident now.

Before I officially move on to the next AWS service, I wanted to jot down a personal IAM checklist — a kind of "did I learn the right stuff?" checkpoint.

---

My IAM Security Checklist

1. Don’t Use Root User (Except for Billing/Account Setup)

Learned this on day 1.
Root is powerful, but risky. So I secured it with MFA and tucked it away.

---

2. Enable MFA for All Users

I enabled Multi-Factor Authentication (MFA) on my test IAM user.
Extra step to log in, but way more secure — especially if credentials get leaked.

---

3. Use Groups Instead of Assigning Permissions Individually

IAM groups made managing permissions feel clean and scalable.
I used them to grant read-only access to EC2 and S3 without repeating myself.

---

4. Follow Least Privilege Principle

Instead of giving “AdminAccess” to everyone, I:

• Created custom policies for specific tasks

• Scoped them down to exact services (and sometimes exact resources)

It took more time — but felt safer.

---

5. Use IAM Roles for EC2 Access

This was a cool trick.
I created an IAM role with S3 access, attached it to an EC2 instance, and didn’t need any access keys.

No hardcoded credentials = safer automation.

---

6. Use Permission Boundaries When Delegating

When I imagined having a junior admin or temp dev in the account, permission boundaries made sense.

They helped me control how far users can go — even if I assign broad permissions.

---

7. Rotate Access Keys (and Avoid Using Them If Possible)

I didn’t dive too deep into access keys, but I saw AWS recommends:

• Rotating keys every 90 days

• Avoiding them altogether if possible (use roles or federated login)

---

8. Audit with Credential Reports

This was new to me.

I generated an IAM credential report, which gave a CSV showing:

• Which users had MFA enabled

• Who had active access keys

• When passwords were last changed

Useful if you’re managing a team.

---

9. Use the IAM Policy Simulator (Lifesaver)

Instead of “trial and error” with policies, I started using the Policy Simulator.

It let me test:

“Would this user be allowed to access this service?”

Saved me lots of guesswork.

---

Final Takeaways

IAM is not flashy — there’s no “wow” visual moment.
But it’s the foundation of everything else in AWS.

• Want to launch EC2 securely? You need IAM.

• Want your Lambda to read from S3? IAM.

• Want to manage access for a dev team? IAM.

So yeah — I’m glad I got my hands dirty here.

---

🔜 What’s Next?

Now that the access management piece is in place, I’m heading to something more fun:

S3 – object storage, static websites, lifecycle rules, and more.

Let’s upload some files and break the internet.
Day 11 coming soon.