AWS IAM: A Beginner-Friendly Guide

`When you start working with AWS, one of the first services you should understand is AWS Identity and Access Management (IAM).

IAM controls who can access your AWS resources, what they can access, and what actions they are allowed to perform.

A simple way to remember it:

IAM → Who can access → What they can access → What they can do

Whether you are working with EC2, S3, Lambda, RDS, Terraform, or other AWS services, IAM is involved in controlling access securely.

What is AWS IAM?

AWS Identity and Access Management (IAM) is an AWS service that helps you securely manage access to AWS resources.

With IAM, you can control:

• Who can access AWS
• How they authenticate
• Which AWS resources they can access
• Which actions they can perform
• Which actions they are explicitly denied

For example, imagine a developer only needs to upload files to a specific S3 bucket.

Instead of giving the developer access to the entire AWS account, you can create a policy that allows access only to that particular bucket and only for the required operations.

This is the foundation of Least Privilege.

The Main IAM Components

IAM becomes much easier to understand when you break it into four major components.

1. IAM Users

An IAM User represents a person or application that needs AWS access.

For example:
Developer → IAM User
Administrator → IAM User
Data Analyst → IAM User

A user can have permissions assigned through policies or groups.

However, for workloads running on AWS, AWS generally recommends using IAM roles instead of long-term access keys whenever possible.

1. IAM Groups

An IAM Group is a collection of IAM users.

Instead of assigning the same permissions individually to 20 developers, you can create a group:
Developers Group
|
|-- User A
|-- User B
|-- User C
|-- User D

Then attach the required policy to the group.

For example:
Developers Group
|
S3 Read Access Policy
|
All developers receive S3 read permissions

This makes permission management easier when working with teams.

1. IAM Roles

IAM Roles are extremely important when working with AWS services.

An IAM Role provides temporary permissions that can be assumed by trusted entities such as:

• EC2
• Lambda
• ECS
• AWS services
• IAM users
• Other AWS accounts

For example, suppose an EC2 instance needs to read files from an S3 bucket.

You should avoid putting AWS access keys directly inside the EC2 server.

Instead:

EC2 Instance
|
IAM Role
|
IAM Policy
|
Amazon S3

The EC2 instance assumes the role and receives temporary credentials automatically.

Why is this better?

You do not need to hard-code credentials such as:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY

inside your application.

This reduces the risk of accidentally exposing long-term credentials.

1. IAM Policies

IAM Policies define what actions are allowed or denied.

Policies are written in JSON.

A simplified example:

{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetObject"
],
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}

Let’s break it down.

Effect

Defines whether the action is:

Allow
or
Deny

Action

Specifies what the principal can do.

For example:s3:GetObject
s3:PutObject
s3:DeleteObject

            IAM
             |
   +---------+---------+
   |         |         |
 Users     Roles     Groups
   |         |         |
   +---------+---------+
             |
         Policies
             |
      AWS Resources
             |
    +--------+--------+
    |        |        |
   S3       EC2     Lambda

IAM Best Practices

Here are some important IAM practices to remember.

1. Enable MFA
   Protect privileged identities with MFA.

2. Avoid using the root user for daily operations
   Keep the root account protected.

3. Follow Least Privilege{% embed %}
   Give only the permissions that are required.

4. Prefer IAM Roles for AWS Workloads
   For EC2, Lambda, ECS, and similar workloads, use roles rather than hard-coded long-term credentials.

5. Review Permissions Regularly
   Remove unnecessary permissions and credentials.

`