Introduction
When you start your AWS journey, one of the first important services you will encounter is IAM - Identity and Access Management.
It may sound complex, but by the end of this article, you will understand exactly what IAM is, and why it exists, and how it works using a simple real-world example.
Why do we Need IAM - A Real World Example
Imagine you work at a hospital.
This hospital has many different areas like general ward, ICU, pharmacy, operation theatre and other record rooms where all patient files are stored.
Now not everyone in the hospital can walk into every area:
- A receptionist can access front desk but not Operation theatre
- A nurse can access ward pharmacy but not record rooms
- A doctor can access most areas but still not the hospital's financial vault.
- Only the hospital director has access to everything.
This is done for security and safety. If everyone has access to everything, someone could accidentally or intentionally misuse the sensitive information.
AWS **IAM **works exactly the same way but for your cloud resources instead of a hospital.
What is AWS IAM?
IAM stands for Identity and Access Management.
It is a free AWS service that helps you control:
- Who can access your AWS account
- What they can do inside it
When you first create an AWS account you will get a root user - this is like the hospital director who has access to everything. But giving everyone root access is extremely dangerous.
IAM **allows you to create separate identities with **only the permissions they need - nothing more, nothing less.
The 4 Core Components of IAM
**IAM **is built on 4 main building blocks:
1.Users: A user represents a single person that needs access to your AWS account.
For example: A developer named Ravi who joins your company needs access to AWS. You create an IAM User for Ravi. set a password and he can now login.
2.Policies: Creating a user alone isn't enough. You will also need to define what that user is allowed to do.
This is handled by Policies - they are JSON documents that defines permissions.
For example, you can create a policy that says:
- ✅ Ravi can read files from S3
- ❌ Ravi cannot delete EC2 instances
- ❌ Ravi cannot access billing
You then attach this policy to the user.
Think of policy as the access card rules - It defines which door you can open.
3.Groups:
Now imagine your company is growing fast. Every week new developers. testers and others are joining. Creating individual policies for each person manually is time consuming and error prone.
This is where **Groups **come in.
A Group is a collection of users that share the same permissions.
Here is how it works in reality:
- You create a group called "Developers" and attach developer policy to it.
- You create group called "QA testers" and attach testing policy to it.
- You create a group called "DBAdmins" and attach Database policy to it.
Now whenever a new employee joins, you simply:
- Create their IAM user.
- Add them to the correct group
- They automatically get all the right permissions.
No more manually attaching policies one by one.
4.Roles: Roles are similar to users, but with one key difference - Roles are not assigned to a specific person permanently.
Roles are mostly used for temporary access or giving AWS services permissions to interact with each other.
Example: Your app running on an EC2 instance needs to read files from S3. Instead of creating a user and hardcoding credentials, you can create an IAM Role with S3 read permissions and attach it to the EC2 instance.
Think of Role as a temporary visitor pass - given for a specific purpose and a specific time.
How It all works Together - Real Workflow
Here is how a real company uses IAM when a new employee joins:
New Employee joins the company
⬇️
They raise a request mentioning their name and which team they belong to
⬇️
DevOps engineer creates an IAM user
⬇️
Adds the user to the correct group
⬇️
User automatically gets the right policies.
⬇️
DevOps engineer share the login credentials with the employee
⬇️
Employee logins with only the access they need
This process keeps your AWS environment secure, organized and scalable.
IAM Best Practices
Before we proceed further, here the important best practices every AWS user should follow:
- Never use your root account for daily tasks - create an IAM admin user instead.
- Enable MFA on for all users especially for root users.
- Follow least Privilege - give users only the permissions they absolutely need.
- Use Groups instead of attaching policies to individual users.
- Review permissions regularly and remove unused access.
Hands On for IAM Service:
Now that we understand the theory, let me walk you through what I actually did in the AWS console step by step.
Step 1: Accessing IAM Dashboard
After logging in to my AWS account with root user credentials, I searched for IAM in the search bar and opened the IAM Dashboard. This is where you can see a full summary of your users, groups, policies and roles.
Step 2: Creating an IAM User
I clicked on IAM Users from the left sidebar and clicked on Create User.
Here I filled in:
- Username: I gave a name like "test-user"
- Access Type: I selected the console access so the user can login
- Password: Set a auto password.
Step 3: Creating a Group, attaching policies
Next I went to IAM User groups -> click on Create Group and created a group called "DevOps" and clicked on create group.
Then I went to IAM user groups and then clicked on the newly created group. Then I clicked on "permissions" and here I attached the policies.
Step 4: Adding user to the Group
Finally I added my newly created user "test-user" into "DevOps" group.
Then I went to IAM user groups and then clicked on the newly created group. Then I clicked on "users" and here I added the user.
As soon as I did this, the user automatically got all the policies attached to that group - without me adding manually.
This was all for IAM service in AWS. Hope the article helped you to understand the concept. Let's meet with another service soon...🥳