AWS IAM Explained: Users, Groups, Roles and Policies
If you have started working with AWS, one of the first services you will come across is IAM.
IAM stands for Identity and Access Management.
When I first started learning AWS, IAM was one of those topics that looked simple at first but became confusing once I started seeing terms like users, groups, roles, policies, permissions, authentication, and authorization.
So in this article, let's understand IAM from the ground up in a simple and practical way.
What is AWS IAM?
AWS IAM is the service that helps you control who can access your AWS resources and what they are allowed to do.
For example, imagine you have an AWS account containing:
- EC2 instances
- S3 buckets
- RDS databases
- VPCs
- Lambda functions
You probably don't want everyone to have access to everything.
A developer might need access to S3.
A DevOps engineer might need access to EC2 and CloudWatch.
A database administrator might need access to RDS.
IAM allows you to manage these permissions.
In simple words:
IAM helps answer two questions: Who are you? and What are you allowed to do?
Authentication vs Authorization
Before going further, it's worth understanding these two terms.
Authentication
Authentication means:
"Who are you?"
For example, when you log in to AWS, AWS needs to verify your identity.
Authorization
Authorization means:
"What are you allowed to do?"
After AWS knows who you are, it checks your permissions.
For example, you might be allowed to:
View EC2 instances
Start EC2 instances
Stop EC2 instances
But you might not be allowed to:
Delete an S3 bucket
Create IAM users
Modify billing settings
That's authorization.
The Main IAM Components
There are four important IAM concepts that you should understand first:
- Users
- Groups
- Policies
- Roles
Let's look at each one.
1. IAM Users
An IAM User represents an identity inside an AWS account.
For example, suppose a company has these employees:
Chandan
Rahul
Priya
Amit
Separate IAM identities can be created for them.
Each identity can have different permissions.
For example:
Chandan → EC2 + S3
Rahul → S3
Priya → RDS
Amit → CloudWatch
This is much better than giving everyone the same level of access.
2. IAM Groups
Now imagine you have 50 developers.
Managing permissions individually for every developer would quickly become difficult.
This is where IAM Groups become useful.
You could create a group called:
Developers
Then attach the required permissions to that group.
After that, you can add your developers to the group.
For example:
Developers Group
|
|--- EC2 permissions
|--- S3 permissions
|--- CloudWatch permissions
|
├── Rahul
├── Priya
└── Amit
Now the users in the group inherit the permissions assigned through the group.
This makes permission management much easier.
3. IAM Policies
Policies define permissions.
A policy tells AWS which actions are allowed or denied.
For example, you might have a policy that allows someone to read objects from a particular S3 bucket.
A simplified policy could look like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
Don't worry if this JSON looks unfamiliar right now.
We'll go deeper into IAM policies in another article.
For now, remember:
Policies define permissions.
4. IAM Roles
Roles are probably the part that confuses beginners the most.
An IAM Role is an identity that can be assumed by a trusted entity.
Let's take a practical example.
Suppose you have an application running on an EC2 instance.
Your application needs to upload files to an S3 bucket.
You could technically put AWS access keys on the EC2 server.
But this is not a good practice.
Instead, you can create an IAM Role and attach the required S3 permissions to it.
The architecture would look something like:
EC2 Instance
|
↓
IAM Role
|
↓
S3 Permissions
|
↓
S3 Bucket
The EC2 instance can use the role to access S3 without you having to store long-term access keys on the server.
This is one of the concepts you'll use again and again when working with AWS.
Users vs Roles
A simple way to remember the difference is:
User
Usually represents a person or a long-term identity.
Developer
Administrator
Engineer
Role
Provides permissions that can be assumed by an AWS service, application, or trusted identity.
For example:
EC2 → IAM Role
Lambda → IAM Role
ECS → IAM Role
As you start working with AWS services, you'll see IAM Roles everywhere.
Why Should You Avoid Using the Root User?
When you create an AWS account, you get a Root User.
The root user has very powerful permissions over the account.
Because of that, you shouldn't use the root user for your everyday AWS work.
Instead, use appropriate IAM identities with only the permissions they actually need.
Also, enable MFA on your root account.
A simple approach is:
AWS Account
|
↓
Root User
|
↓
Secure the root account
|
↓
Use appropriate IAM identities
The root user should generally be used only when a task specifically requires root-level access.
Principle of Least Privilege
This is one of the most important security concepts in IAM.
The idea is simple:
Give an identity only the permissions it actually needs.
For example, if someone only needs to read files from S3, there is no reason to give them permission to delete the bucket.
Instead of giving:
s3:*
you might only need:
s3:GetObject
The first permission is much broader than the second.
The goal is to give users and applications the minimum access required to perform their job.
This is called the Principle of Least Privilege.
A Simple IAM Example
Let's imagine you're working on a small application.
Your team might look something like this:
Developer
|
↓
IAM User
|
↓
Developer Group
|
↓
Permissions
|
├── EC2
├── S3
└── CloudWatch
At the same time, your application is running on an EC2 instance.
The application needs access to S3.
Instead of giving the application's server your personal AWS credentials:
EC2
|
↓
Hardcoded AWS Access Keys
|
↓
S3
you can use:
EC2
|
↓
IAM Role
|
↓
S3
This is a much better approach for applications running on AWS.
IAM and DevOps
If you're learning DevOps, you'll use IAM constantly.
For example:
EC2
EC2 instances can use IAM Roles to access other AWS services.
CI/CD
A CI/CD pipeline might need permissions to:
- push Docker images to ECR
- deploy applications to ECS
- upload files to S3
- update Lambda functions
Terraform
Terraform needs AWS permissions when it creates and manages AWS infrastructure.
Kubernetes / EKS
When working with Amazon EKS, IAM becomes an important part of authentication and authorization.
So IAM isn't just another AWS service that you learn once and forget.
It becomes part of almost everything you build on AWS.
A Simple Mental Model
If you're just starting with IAM, remember this:
IAM
|
┌──────────┼──────────┐
↓ ↓ ↓
Users Groups Roles
| | |
└──────────┼──────────┘
↓
Policies
↓
Permissions
↓
AWS Resources
This isn't the complete IAM architecture, but it's a useful mental model when you're starting out.
What Should You Remember?
If you remember only four things from this article, remember these:
User → An identity, usually representing a person.
Group → A way to organize users and manage permissions for them.
Policy → Defines what actions are allowed or denied.
Role → An identity that can be assumed by a trusted entity, such as an AWS service.
Once these concepts become clear, IAM becomes much easier to understand.
What's Next?
This article was just the foundation.
In the next article, we'll actually get our hands dirty with IAM.
We'll create an IAM user, create a group, attach policies, look at IAM policy JSON, enable MFA, and see how permissions work in a real AWS environment.
After that, we'll move to one of the most commonly used AWS services:
EC2 — Launching and Connecting to Your First AWS Server.
Final Thoughts
IAM might not be as exciting as launching an EC2 server or deploying an application.
But it's one of the most important foundations to understand before going deeper into AWS.
The earlier you understand IAM and least-privilege access, the fewer permission and security problems you'll run into later.
And that's what we'll build on in the next articles.
Top comments (0)