DEV Community: Chandan Maheshwari

AWS IAM Explained: Users, Groups, Roles and Policies

Chandan Maheshwari — Sun, 06 Sep 2026 05:57:14 +0000

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.

How AWS Global Infrastructure Works - Regions, Availability Zones, and Data Centers

Chandan Maheshwari — Sun, 31 May 2026 05:29:52 +0000

If you've started exploring AWS, you've probably come across terms like Regions, Availability Zones (AZs), and Data Centers.

When I first saw these terms, I thought they were complicated networking concepts.

But once I understood the relationship between them, everything started making sense.

In this article, I'll break them down in the simplest way possible.

Why Does AWS Need Global Infrastructure?

Imagine AWS had only one data center in the entire world.

What would happen?

Users far away would experience high latency.
If that data center failed, millions of applications could go down.
Businesses wouldn't be able to serve customers reliably.

To solve these problems, AWS has built infrastructure across the globe.

This infrastructure allows applications to be:

Faster
Highly available
Fault tolerant
Closer to users

Understanding the Hierarchy

Think of AWS infrastructure like this:

Data Center → Availability Zone → Region

Let's understand each one.

What is a Data Center?

A Data Center is a physical building that contains:

Servers
Storage systems
Networking equipment
Power systems
Cooling systems

This is where your AWS resources actually run.

When you launch an EC2 instance, it is ultimately running inside a physical AWS data center somewhere in the world.

Most AWS customers never need to know the exact data center location because AWS manages everything behind the scenes.

What is an Availability Zone (AZ)?

An Availability Zone is one or more data centers grouped together within a Region.

Each Availability Zone is designed to operate independently.

For example:

If one Availability Zone experiences an issue, another Availability Zone can continue serving your application.

This improves:

Availability
Redundancy
Disaster recovery

You may see names like:

ap-south-1a
ap-south-1b
ap-south-1c

These are Availability Zones inside the Mumbai Region.

What is a Region?

A Region is a geographical area where AWS has multiple Availability Zones.

Examples include:

Mumbai
Singapore
Frankfurt
London
Tokyo
North Virginia

Each Region is isolated from other Regions.

This helps customers choose where their applications and data should be located.

For example:

An Indian company serving Indian users might choose the Mumbai Region to reduce latency.

Real-World Example

Imagine you're building an e-commerce application.

You deploy your application in the Mumbai Region.

Inside that Region:

Web Server 1 runs in Availability Zone A.
Web Server 2 runs in Availability Zone B.
Database backups are stored in another Availability Zone.

Now imagine Availability Zone A suddenly becomes unavailable.

Your application can still continue running from Availability Zone B.

This is one of the main reasons AWS is highly reliable.

Why Multiple Availability Zones Matter

Many beginners deploy everything in a single Availability Zone.

While this works for learning, production applications should use multiple Availability Zones whenever possible.

Benefits include:

Better uptime
Higher availability
Protection against infrastructure failures
Improved disaster recovery

This is known as a Multi-AZ architecture.

How AWS Names Regions

AWS uses standard naming conventions.

Examples:

us-east-1 → North Virginia
us-west-2 → Oregon
eu-west-1 → Ireland
ap-south-1 → Mumbai
ap-southeast-1 → Singapore

Once you work with AWS regularly, these names become familiar.

Which Region Should Beginners Use?

If you're learning AWS from India, the Mumbai Region (ap-south-1) is usually a good starting point because:

Lower latency
Easy to understand
Commonly used by Indian businesses

However, many tutorials also use North Virginia (us-east-1) because AWS often launches new services there first.

Key Takeaway

Remember this simple relationship:

A Data Center is a physical facility.

Multiple Data Centers form an Availability Zone.

Multiple Availability Zones form a Region.

When you launch resources on AWS, they run inside this global infrastructure.

Understanding this foundation will make services like EC2, RDS, Load Balancers, and VPC much easier to learn.

Final Thoughts

AWS's global infrastructure is one of the biggest reasons companies trust the platform.

By distributing resources across multiple Availability Zones and Regions, AWS helps businesses build applications that are reliable, scalable, and highly available.

In the next article, we'll dive into one of the most important AWS services for every beginner:

Happy Learning.

What is Cloud Computing and How Does It Actually Work?

Chandan Maheshwari — Fri, 29 May 2026 17:43:00 +0000

What is Cloud Computing and How Does It Actually Work?

If you are starting your AWS or DevOps journey, then one term you’ll hear everywhere is “Cloud Computing”.

But when I first started learning, this term sounded more complicated than it actually is.

People explain it using technical definitions, which usually confuses beginners even more.

So in this article, let’s understand cloud computing in the simplest way possible with real examples.

What is Cloud Computing?

Cloud computing simply means:

Using computing services like servers, storage, databases, networking, and software over the internet instead of managing everything physically on your own system.

In simple words:

Instead of buying and maintaining your own servers, you rent resources from cloud providers whenever you need them.

These resources are available through the internet.

Before Cloud Computing

Earlier, companies had to:

buy physical servers
set up data centers
manage cooling and electricity
maintain networking hardware
hire teams to manage infrastructure

This process was expensive and difficult to scale.

Imagine a startup suddenly getting huge traffic.

They would need to buy more hardware, which takes time and money.

How Cloud Computing Changed Everything

Cloud platforms solved this problem.

Now companies can:

launch servers instantly
increase storage anytime
scale applications automatically
deploy services globally
pay only for what they use

Instead of waiting weeks for hardware setup, infrastructure can now be created in minutes.

That’s why cloud computing became so popular.

Real-Life Example

Imagine you want to start a website.

Traditional Way

You would need:

physical servers
networking setup
internet connection
maintenance
backup systems

Cloud Way

You simply go to a cloud platform like AWS and launch a virtual server.

Within minutes:

your server is ready
your website can go live
users can access it from anywhere

No physical hardware required.

So Where is “The Cloud”?

One common beginner question is:

“Where does the cloud actually exist?”

The answer is:
the cloud runs inside huge data centers owned by cloud providers.

Companies like AWS have data centers across the world.

These data centers contain:

thousands of servers
storage devices
networking equipment
security systems

When you launch a server on AWS, you are basically using a small part of AWS infrastructure remotely.

Types of Cloud Computing

There are mainly 3 types.

1. Public Cloud

Infrastructure is owned by a cloud provider and shared over the internet.

Example:

AWS
Microsoft Azure
Google Cloud

This is the most common model.

2. Private Cloud

Infrastructure is used privately by a single organization.

Mostly used by:

banks
government organizations
large enterprises

3. Hybrid Cloud

Combination of both public and private cloud.

Some services run privately while others run on public cloud infrastructure.

Main Benefits of Cloud Computing

Scalability

Increase or decrease resources anytime.

Cost Efficient

No need to buy expensive hardware upfront.

High Availability

Applications can run globally with minimal downtime.

Faster Deployment

Infrastructure can be created within minutes.

Security

Cloud providers offer advanced security features and monitoring.

Common Cloud Services You’ll Use

As you continue learning AWS and DevOps, you’ll work with services like:

Virtual Servers
Storage
Databases
Networking
Monitoring
Load Balancers
Containers
Kubernetes
CI/CD Pipelines

All of these are part of cloud computing.

Why Cloud Computing is Important for DevOps

Modern DevOps practices heavily depend on cloud platforms.

Because cloud computing allows engineers to:

automate infrastructure
deploy applications faster
scale systems easily
build CI/CD pipelines
manage production environments efficiently

Without cloud computing, modern DevOps would be much slower and harder.

Final Thoughts

Cloud computing is not as complicated as it sounds in the beginning.

It simply means:
using computing resources over the internet instead of managing physical infrastructure manually.

Once you understand this foundation, learning AWS services becomes much easier.

Happy Learning,
Connect me if you are a Cloud, DevOps, AI or in Automation.

Getting Started with AWS — A Beginner Friendly Introduction

Chandan Maheshwari — Sun, 24 May 2026 08:28:06 +0000

If you are starting your Cloud or DevOps journey, then one name you’ll hear everywhere is AWS.

When I first heard about AWS, I was confused.

People were talking about EC2, VPC, IAM, Regions, Availability Zones, Load Balancers… and honestly, it felt overwhelming in the beginning.

But once I started understanding the basics step-by-step, things became much easier.

So in this article, I’ll explain AWS in the simplest way possible.

No complicated definitions.

Just a practical beginner-friendly introduction.

So, What Actually is AWS?

AWS stands for Amazon Web Services.

It is a cloud platform created by Amazon that allows you to use servers, storage, databases, networking, and many other services directly from the internet.

In simple words:

Instead of buying a physical computer/server and keeping it in your office, AWS lets you rent infrastructure whenever you need it.

You can launch servers in minutes and stop them anytime.

That’s the power of cloud computing.

Why Do Companies Use AWS?

Think about companies like Netflix, Spotify, Airbnb, or big startups.

Millions of users use their applications every day.

Managing physical servers manually for such huge traffic is difficult and expensive.

AWS solves this problem.

Using AWS, companies can:

Scale applications easily
Store huge amounts of data
Deploy apps globally
Automate infrastructure
Improve security
Reduce hardware costs

And the best part is:
you only pay for what you use.

Real Example

Suppose you want to host a website.

Traditionally, you would need:

A physical server
Networking setup
Electricity
Cooling systems
Maintenance

But with AWS:
you can launch a virtual server in just a few clicks.

This virtual server is called an EC2 instance.

You can deploy your application there and access it from anywhere.

Some Important AWS Services Beginners Should Know

EC2

Virtual servers in the cloud.

S3

Used to store files, images, videos, backups, etc.

IAM

Used to manage users and permissions securely.

RDS

Managed database service.

VPC

Helps create your own private network inside AWS.

Don’t worry if these terms sound new right now.
We’ll learn all of them step-by-step in upcoming articles.

Why I Think AWS is Worth Learning

One thing I personally like about AWS is that it gives you practical exposure to real-world infrastructure.

You can actually deploy applications, create networks, configure security, automate deployments, and build production-like environments.

That’s why AWS is highly valuable for:

Cloud Engineers
DevOps Engineers
Backend Developers
System Administrators

Final Thoughts

If you are starting your cloud journey, don’t try to learn everything at once.

Start with the fundamentals.

Understand:

what cloud computing is
why AWS exists
how basic services work

Once the foundation becomes strong, advanced topics become much easier.

In the next article, I’ll explain:
“What is Cloud Computing and how does it actually work?”

Happy Learning.