Everything You Need to Know About IAM

What is IAM?

• IAM (Identity and Access Management) is how AWS controls who can do what in your cloud environment.

• It is a global service.

• When we created a account we created as a root account by default.

Let’s understand it through a real-world office story.

Imagine: AWS is Like a Company Building

You work at a company called CloudCorp. The office building has:

• Meeting rooms

• A finance department

• A server room

• A cafeteria

You want to control:

• Who can go where

• Who can do what

AWS IAM is like your digital security system for this building.

---

IAM Users = Employees

Each employee gets their own ID badge (username & password or access keys). This badge tells IAM who they are.

Example:

• Alice is a Developer

• Bob is in the DevOps team

• Charlee works in both Security and Audit

---

IAM Groups = Departments

You create groups based on job roles:

• Developers Group: Can write code, deploy applications

• DevOps Group: Can manage infrastructure

• Audit Group: Can view logs and check permissions

• Security Group: Can update firewall rules and monitor threats

Here’s the cool part:

A user can belong to multiple groups!

Charlee belongs to:

• The Security Group

• The Audit Group

So she gets permissions from both. Just like someone in real life can work in multiple departments and get access to both of their rooms.

---

IAM Roles = Temporary Visitors or Automation

Sometimes, an external consultant or an application needs access. But you don’t want to give them a permanent badge.

You create an IAM Role — like a visitor pass — that says:

• “You can access only the Finance Room for the next 2 hours.”

• Or: “This EC2 server can read files from S3.”

• IAM roles have policies attached to them that define the permissions granted when the role is assumed.

  

---

IAM Policies = Rulebooks

IAM uses policies to define permissions — like a list of rules.

For example:

• "Can access server room"

• "Can deploy code"

• "Can only read logs, not change them"

Policies are like instructions attached to users, groups, or roles, explaining what they’re allowed to do.

IAM Policy Structure Made Simple

• IAM policies are always written in JSON (JavaScript Object Notation) format.

{
  "Version": "2012-10-17",
  "Id": "S3-Account-Permissions",
  "Statement": [
    {
      "Sid": "1",
      "Effect": "Allow",
      "Principal": {
        "AWS": ["arn:aws:iam::123456789012:root"]
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": ["arn:aws:s3:::mybucket/*"]
    }
  ]
}

The Main Parts of a Policy:

• Version
  Always write "2012-10-17" — this tells AWS which policy language version you're using.

• Id (Optional)
  A name or unique identifier for the policy. It's just for your reference.

• Statement
  This is the most important part — it contains the actual rules. You can have one or more statements.

  Each Statement Contains:

  • Sid (Optional)
    Like a statement ID — helpful when you have many statements.

  • Effect
    Tells AWS if the rule should Allow or Deny access.

  • Principal
    Who the rule applies to (like an AWS account, user, or role).

  • Action
    What actions are allowed or denied (like s3:GetObject, s3:PutObject, etc.).

  • Resource
    What resources the actions apply to (like an S3 bucket, EC2 instance, etc.).

---

Multi-Factor Authentication (MFA)

• MFA adds an extra layer of security to your AWS account.

• Requires:

  • Something you know (your password)

  • Something you have (a device like phone/app/hardware key)

    

• Protects Root and IAM users from unauthorized access.

• Common MFA types:

  • Virtual (e.g., Google Authenticator)

  • Hardware (e.g., YubiKey)

  • SMS (less secure)

• Best practice: Always enable MFA for the root user and critical IAM users.

---

Least Privilege Principle

Give only the minimum permissions needed to perform a task — nothing more.

Why is it Important?

• Reduces risk of accidental changes or deletions

• Limits damage if credentials are compromised

• Helps follow security best practices

---

IAM Security Tools – Monitoring Your Digital Office

Just like in a real company, it’s not enough to give access — you also need to monitor it.

You need tools to answer questions like:

• "Who has access to what?"

• "Are employees using the access they've been given?"

AWS gives us IAM Security Tools to help manage and audit access effectively. Think of these tools as your security guard logs and access trackers in the CloudCorp building.

IAM Credentials Report (Account-Level)

• A downloadable report that lists all users and the status of their credentials (passwords, access keys, etc.).

• Helps you quickly spot insecure accounts (e.g., unused access keys, no MFA, etc.).

IAM Access Advisor (User-Level)

• Shows which services a user has access to, and when they last used them.

Helps you remove unused permissions and follow the Least Privilege Principle.

---

Shared Responsibility Model for IAM – Who Does What?

Before we go deeper, it’s important to understand who is responsible for what when it comes to security in AWS.

Let’s go back to our CloudCorp office analogy:

Imagine AWS provides the building — secure doors, electricity, fire alarms, surveillance, etc.

But you (the company) are responsible for how your employees behave inside the building:

• Who gets a keycard (IAM users)

• What areas they can access (permissions/policies)

• Making sure doors are locked (MFA, strong password policy)

• Reviewing logs (Access Advisor, Credential Reports)

This is called the Shared Responsibility Model.