How to Master AWS IAM: Complete Step by Step Guide for Beginners
By Braincuber Team
Published on March 28, 2026
AWS Identity and Access Management (IAM) is the security foundation of your entire AWS infrastructure. It gives you precise control over who can access your AWS services and what they can do with them. Understanding IAM is not optional if you are serious about cloud security.
This beginner guide uses a restaurant analogy to make IAM concepts intuitive. You will learn about IAM users, groups, roles, and policies with practical JSON examples you can use immediately. By the end, you will understand how to implement the principle of least privilege and secure your AWS resources properly.
What You'll Learn:
- The critical difference between authentication and authorization
- How to create and manage IAM users, groups, and roles
- Writing effective IAM policies using JSON
- Understanding trust policies vs permission policies
- Real-world EC2 to S3 access scenario with complete setup
- Security best practices and the 5000 user limit workaround
Step 1: Understanding Authentication vs Authorization
Before diving into IAM components, you must understand two fundamental security concepts that are often confused:
Authentication
Proving who you are. Like showing your passport at airport security. IAM users, groups, and roles handle authentication.
Authorization
Proving what you can do. Like your boarding pass that grants access to specific resources. IAM policies handle authorization.
Think of it like boarding a flight. Your passport proves you are who you say you are (authentication). Your boarding pass proves you have permission to board that specific flight (authorization). Both are required to access the plane.
In AWS IAM, users/groups/roles are like passports. Policies are like boarding passes. Without the right policy attached to your identity, you cannot access AWS resources, even if you are authenticated.
Step 2: Creating IAM Users
An IAM user is an identity that requires long-term access to AWS resources. This includes humans logging into the AWS Console or applications making API calls.
When to Use IAM Users
Human Users
Developers, administrators, and team members who need console access. They authenticate with username/password.
Applications
Long-running applications or scripts that need programmatic AWS access. They authenticate with access keys.
Service Accounts
CI/CD pipelines, deployment scripts, and automated tools requiring persistent AWS access.
Creating a User via AWS CLI
aws iam create-user --user-name developer-john
Step 3: Organizing Users into Groups
IAM groups let you organize users by job function and apply permissions at the group level. This is essential for managing permissions at scale.
Why Groups Matter
Imagine you have 60 employees across 6 teams. Managing permissions individually means 60 separate policies. With groups, you manage just 6 policies attached to groups.
Common Group Structure
| Group Name | Typical Permissions | Example Users |
|---|---|---|
| Developers | EC2, S3, RDS read/write | 10 developers |
| DevOps | CloudFormation, ECS, IAM limited | 5 engineers |
| Admins | Full administrative access | 2 system admins |
| ReadOnly | View all resources, no changes | Auditors, managers |
| Support | EC2 start/stop, CloudWatch read | 8 support staff |
Creating a Group and Adding Users
# Create the Developers group
aws iam create-group --group-name Developers
# Add a user to the group
aws iam add-user-to-group --user-name developer-john --group-name Developers
# List users in a group
aws iam get-group --group-name Developers
Important Note
A user can belong to multiple groups. For example, a DevOps engineer might be in both the "DevOps" and "Support" groups, inheriting permissions from both.
Step 4: Understanding IAM Roles
IAM roles provide temporary access to AWS resources. Unlike users, roles do not have long-term credentials. Instead, entities "assume" the role temporarily and receive temporary security credentials that expire.
IAM User
- Long-term credentials (permanent)
- Tied to specific identity
- Best for: Individual humans
- Limit: 5000 per account
IAM Role
- Temporary credentials (expire)
- Can be assumed by anyone/anything authorized
- Best for: Applications, services, external users
- No user limit
Trust Policies vs Permission Policies
IAM roles have two types of policies:
Trust Policy
Controls who can assume the role. Think of it as the bouncer at the door checking IDs. It defines which identities (users, services, external entities) are allowed to assume this role.
Permission Policy
Controls what the role can do once assumed. Think of it as what rooms you can access with your temporary badge. It grants or denies access to specific AWS resources.
Creating an IAM Role for EC2
Here is how to create a role that EC2 instances can assume:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
Step 5: Writing IAM Policies
IAM policies are JSON documents that define permissions. They consist of one or more statements that either allow or deny access to AWS resources.
Policy Structure Breakdown
| Element | Required | Description |
|---|---|---|
| Version | Yes | Policy language version (use "2012-10-17") |
| Sid | No | Statement ID - optional identifier for the statement |
| Effect | Yes | Either "Allow" or "Deny" |
| Action | Yes | Specific AWS actions (e.g., "s3:GetObject") |
| Resource | Yes | ARN of the resource (or "*" for all) |
| Condition | No | Optional conditions for when policy applies |
Complete S3 Access Policy Example
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ListObjectsInBucket",
"Effect": "Allow",
"Action": ["s3:ListBucket"],
"Resource": ["arn:aws:s3:::bucket-name"]
},
{
"Sid": "AllObjectActions",
"Effect": "Allow",
"Action": "s3:*Object",
"Resource": ["arn:aws:s3:::bucket-name/*"]
}
]
}
Principle of Least Privilege
By default, all requests are implicitly denied unless a policy explicitly allows them. Always grant the minimum permissions needed. Avoid wildcards like "*" on resources in production.
The Restaurant Analogy: Bringing It All Together
To make IAM concepts concrete, let us use a restaurant analogy:
Full-Time Employees = IAM Users
Chefs, waiters, and cleaners are full-time staff with long-term access to the restaurant. They are like IAM users requiring permanent access to AWS resources.
Employee Groups = IAM Groups
All waiters belong to the "Waiters" group, all chefs to the "Chefs" group. Each group gets the same set of keys (permissions) to access relevant areas. This is exactly how IAM groups work.
Part-Time Staff and Customers = IAM Roles
Part-time chefs work only evenings and weekends. They need temporary access, just like IAM roles. They assume the "Chef" role temporarily and get a temporary badge (temporary credentials) that expires.
Customers are another perfect analogy for IAM roles. A successful restaurant has thousands of customers over time. Creating individual IAM users for each would hit the 5000 user limit quickly. Instead, customers assume the "Customer" role temporarily when they order.
Keys and Locks = IAM Policies
Keys control access to different areas of the restaurant. Waiters get keys to the dining area and storage room. Chefs get keys to the kitchen. These keys are like IAM policies attached to groups or users.
Restaurant Security
No keys = no access. Even employees cannot enter restricted areas without the right keys.
AWS IAM Security
No policy = implicit deny. Even authenticated users cannot access resources without explicit permissions.
Real-World Example: EC2 Accessing S3
Here is a complete step-by-step scenario: An EC2 instance running an application needs to read from and write to an S3 bucket.
Create IAM Role for EC2
Create a role with a trust policy that allows EC2 instances to assume it.
Attach Permission Policy
Attach a policy that grants s3:GetObject, s3:PutObject, and s3:ListBucket permissions on your specific bucket.
Attach Role to EC2 Instance
When launching or modifying the EC2 instance, attach the IAM role. The instance automatically receives temporary credentials.
Access S3 from EC2
Your application can now use AWS SDKs or CLI to access S3 without storing any credentials. The role credentials are automatically rotated.
Security Best Practices
Enable MFA for All Users
Require multi-factor authentication, especially for users with administrative access. This prevents credential theft from resulting in account compromise.
Use Roles for Applications
Never store access keys in application code or configuration files. Use IAM roles attached to EC2 instances, Lambda functions, or ECS tasks.
Rotate Credentials Regularly
Rotate access keys every 90 days maximum. Better yet, use roles with automatic credential rotation instead of long-term access keys.
Avoid Root Account Usage
Create individual IAM users with appropriate permissions. Lock away the root account credentials and only use them for account-level tasks.
Follow Least Privilege
Grant only the permissions required to perform tasks. Start with minimum permissions and add as needed. Regularly review and remove unnecessary permissions.
Use Resource-Based Policies
For S3 buckets, SNS topics, and other resources that support them, use resource-based policies to control access directly on the resource.
Frequently Asked Questions
What is the difference between an IAM user and an IAM role?
An IAM user is for long-term access and represents a specific identity (human or application) with permanent credentials. An IAM role provides temporary access through temporary security credentials and is assumed by identities that need short-term or rotating access, such as AWS services or federated users.
What is the AWS IAM 5000 user limit workaround?
AWS limits you to 5000 IAM users per account. If you need more than 5000 identities to access your AWS resources, you should use IAM roles with federated access, which does not have the same limitation. Your application authenticates users internally and assumes IAM roles with temporary credentials for AWS resource access.
What happens if no IAM policy allows an action?
By default, all requests are implicitly denied. An identity can only access a resource if an attached policy explicitly allows it. This principle of least privilege ensures users cannot accidentally or maliciously access resources they should not.
How do I create an IAM policy for S3 access?
Create a JSON policy with Version "2012-10-17", include Statements with Effect (Allow/Deny), Action (e.g., "s3:GetObject"), and Resource (ARN). Use specific ARNs rather than wildcards for production. Attach the policy to users, groups, or roles that need S3 access.
Can an IAM user belong to multiple groups?
Yes. A user can be a member of up to 10 groups. The user inherits permissions from all attached groups. This maps to real-world scenarios where, for example, a DevOps engineer might also be part of the support rotation team.
Need Help with AWS IAM?
Our cloud security experts can help you design IAM architectures, audit your current permissions, and implement least privilege policies across your AWS infrastructure.