Getting Started with AWS IAM – Giving EC2 Controlled Power

I didn’t write for the last two days — not because I stopped learning, but because I was getting my hands dirty with IAM (Identity and Access Management).
Turns out, IAM isn’t something you understand just by reading; you really need to play with it.

---

🎯 My Goal for Today

I wanted to do something specific:
Give my EC2 instance access to S3 without using access keys or storing credentials manually.

That’s where IAM roles come into play.

---

What I Learned About IAM

Here’s how I’ve started to understand IAM:

• Users – Actual people (like me), who log into AWS.

• Groups – Collections of users with shared permissions.

• Policies – JSON documents that say who can do what.

• Roles – Temporary permission sets for AWS services (like EC2).

IAM is all about controlling access in a secure, centralized way.

---

What I Did

1. Created a test S3 bucket

2. Logged into my EC2 instance

3. Wanted to list files in S3 with the AWS CLI
   → but got a credentials error (duh)

4. So I:

   • Created an IAM Role with AmazonS3ReadOnlyAccess

   • Attached the role to my running EC2 instance

5. Tried the CLI command again... and it worked! 🎉

No access keys, no .aws/credentials files — just clean, role-based access.

---

Key Takeaways

• IAM Roles make EC2 secure and powerful

• Much better than hardcoding credentials

• Roles can be updated anytime without touching the instance

• AWS managed policies (like AmazonS3ReadOnlyAccess) are super helpful to start with

---

What’s Next?

Spending time with IAM made me realize how deep it actually is.
I plan to dig deeper into:

• Writing custom IAM policies

• Creating IAM users with very limited permissions

• Exploring how IAM integrates with billing, CloudWatch, and more

---

🙌 Final Thoughts

IAM felt abstract at first. But after trying things out, I get why it's so important.
This wasn’t the most “bloggable” phase — it was more trial and error — but I’m glad I got through it.

On to Day 8...