IAM Roles — Another "Who" in the IAM Family
If you check the AWS docs, they say:
“An IAM role is similar to an IAM user in that it is an AWS identity with permission policies that determine what the identity can and cannot do. However, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it.”
Yeah… not exactly clear at first glance.
Let me break it down with an example.
🧵 The Real-World Use Case
Let’s say you want to host an application on EC2, and that app needs to:
- Store and retrieve files in S3
- Publish logs to CloudWatch
You’ve got a few ways to do this.
❌ Option 1: Use an IAM User
You could:
- Create an IAM user
- Attach the necessary permissions (S3 and CloudWatch access)
- Hardcode the credentials into your application
Or store those credentials somewhere in the EC2 file system and read them at runtime.
Sounds doable, right?
🚨 Don’t do this. It’s a bad idea. Hardcoding credentials is a massive security risk, and storing them locally isn’t any better.
✅ The Right Way: Use an IAM Role
A better approach is to:
- Create an IAM role with the exact permissions your app needs (e.g., S3 and CloudWatch access)
- Attach that role to the EC2 instance when launching it
AWS will automatically provide your instance with temporary, secure credentials using that role.
No manual keys, no risk of accidental leaks. This is the recommended and secure way to give AWS services access to other AWS services.
🎯 Creating a Role — Step by Step
- Go to the IAM dashboard
- Select Roles from the sidebar
- Click Create role
You’ll be asked to choose a trusted entity type, which just means:
“Who or what will use this role?”
Some options include:
- AWS service (e.g., EC2, Lambda)
- Another AWS account
- Web identity or SAML provider
Once selected:
- Attach the required policies (permissions)
- Name the role and create it
Done.
🧠 Quick Recap
- Users are actual people (with passwords, keys, etc.)
- User Groups are collections of users
- Roles are assignable identities with temporary credentials, ideal for services like EC2, Lambda, or even federated users
They’re all part of the "who" that can access your AWS resources.
📌 Up Next: IAM Policies
Now that we’ve covered the who, next up is the what — as in, what can they do?
In the next blog post, we’ll dive deep into IAM Policies — how to write them, use them, and avoid common pitfalls.
📚 Missed a post in the series?
Catch up here:
➡️ Understanding IAM Users
➡️ Understanding IAM User Groups
🔔 Follow me for more beginner-friendly AWS and cloud content!
Top comments (0)