What is IAM? AWS Identity & Access Management Explained

You just got your first AWS account. You log in, set up an EC2 server, and then someone says: “Don’t use the root account. Create an IAM user.”

Then later: “Attach the S3 policy to the developers group.”

Then: “The Lambda needs a role with DynamoDB access.”

If you’ve been following this series, you already understand all of this. IAM is the same mental model you learned on Linux — Users, Groups, Permissions, Resources — scaled to the entire cloud. Let’s prove it.

IAM in One Paragraph

IAM stands for Identity and Access Management. It’s the AWS service that answers one question for every action in your AWS account:

“Who is allowed to do what, on which resources?”

Every API call to AWS — every aws s3 cp, every EC2 launch, every Lambda invocation — is checked against IAM before it’s allowed. IAM is the security layer between every identity and every resource in AWS.

---

The 4 Core IAM Concepts

1. IAM Users — The Individual Identity

An IAM User is a named identity that belongs to your AWS account. Like a Linux user, it has:

• A username (e.g., shekhar-admin)
• Credentials: a password (for Console login) and/or Access Keys (for CLI/API)
• Permissions attached via policies

Linux:   shekhar   → UID 1001 → password in /etc/shadow
AWS IAM: shekhar   → AccessKeyID + SecretAccessKey

2. IAM Groups — The Team Identity

An IAM Group is a collection of IAM Users. You attach policies to the group — every user in the group inherits them.

Real example:

• Group Developers → has AmazonS3FullAccess + AmazonEC2ReadOnlyAccess policies
• Add alice, bob, charlie to the group
• All three can now access S3 and read EC2 — without setting permissions per user

# This is conceptually identical to Linux:
sudo groupadd developers
sudo usermod -aG developers alice

# In AWS, you'd use the Console or CLI:
aws iam create-group --group-name Developers
aws iam add-user-to-group --user-name alice --group-name Developers

3. IAM Policies — The Permission Documents

An IAM Policy is a JSON document that says: “Who can do what action on which resource.”

Every IAM policy has at least these fields:

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

Field	What it means
Effect	"Allow" or "Deny". Deny always wins if both match.
Action	Which API calls are allowed. "s3:GetObject", "ec2:*", "*" (everything — dangerous!)
Resource	The specific ARN (Amazon Resource Name) the policy applies to. "*" means all resources.

AWS Managed vs Customer Managed Policies

Type	Examples	When to use
AWS Managed	AmazonS3FullAccess, AdministratorAccess	Quick starts, standard roles
Customer Managed	Your JSON document	When you need precise, least-privilege control
Inline	Embedded directly in a user/group	Avoid — hard to manage and audit

Recommendation for production: always write Customer Managed policies with the minimum required permissions.

---

4. IAM Roles — The Service Identity (Cloud-Unique Concept)

This is where AWS IAM differs most from Linux. IAM Roles are identities assumed by services — not by people.

Think of it like this:

• IAM User = a person who logs in with a permanent username and password
• IAM Role = an identity that a service “puts on” temporarily while doing a task

Real examples:

EC2 instance → assumes IAM Role "ec2-s3-readonly" → can call s3:GetObject
Lambda function → assumes IAM Role "lambda-dynamo-writer" → can call dynamodb:PutItem
GitHub Actions → assumes IAM Role via OIDC → can deploy to ECS
Another AWS account → assumes IAM Role for cross-account access

Why Roles Over Access Keys?

Bad pattern (Access Keys):
  - Embed ACCESS_KEY_ID + SECRET_ACCESS_KEY in EC2 instance
  - Keys are long-lived (until manually rotated)
  - If server is compromised → permanent credentials leaked

Good pattern (IAM Role):
  - Attach IAM Role to EC2 instance
  - AWS rotates credentials automatically every few hours
  - If server is compromised → keys expire and rotate — attacker's access expires

Rule: Never put Access Keys on a server. Always use IAM Roles for AWS services.

---

IAM in Practice: Common AWS CLI Commands

Check your current identity:

List IAM users in your account:

Check a user’s policies:

Create a new IAM user (CLI):

---

The Principle of Least Privilege

This is the most important IAM rule — and it applies equally to Linux:

Grant only the minimum permissions needed to do the specific job. Nothing more.

In practice:

❌ Bad:  Give a developer AdministratorAccess because it's easy
✅ Good: Give a developer AmazonS3FullAccess + AmazonEC2ReadOnlyAccess

❌ Bad:  Lambda function has AmazonDynamoDBFullAccess
✅ Good: Lambda function has policy: dynamodb:GetItem, dynamodb:PutItem on ONE specific table

❌ Bad:  Resource: "*" (all resources in AWS)
✅ Good: Resource: "arn:aws:s3:::company-data-bucket/*" (one specific bucket)

---

MFA: Adding a Second Factor

Every IAM user (especially admins) should have Multi-Factor Authentication (MFA) enabled. Without it, a leaked password means full account access.

In IAM, you can even write policies that require MFA for sensitive actions:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": {
    "BoolIfExists": {
      "aws:MultiFactorAuthPresent": "false"
    }
  }
}

This policy says: “Deny everything if the user didn’t authenticate with MFA.” Combined with an Allow policy, this forces MFA for all admin actions.

---

Hands-On Challenge

Do this in your AWS account (free tier safe):

1. Log in as root → IAM → Create an IAM user with AdministratorAccess
2. Enable MFA on the root account (with a mobile authenticator app)
3. Log out of root, log in as your new IAM admin user
4. Create an IAM Group called ReadOnlyGroup
5. Attach ReadOnlyAccess policy to the group
6. Create a second IAM user called auditor, add to ReadOnlyGroup
7. Run: aws iam list-attached-user-policies --user-name auditor — verify they have ReadOnly
8. Bonus: Use the IAM Policy Simulator to test if auditor can delete an S3 bucket (they shouldn’t be able to)

---

Key Takeaways

1. IAM = Linux identity model at cloud scale. Users, Groups, Permissions, Resources — same model, JSON syntax.
2. Everything is denied by default. Permissions must be explicitly granted. No grants = no access.
3. IAM Roles are for services — EC2, Lambda, ECS. Never embed Access Keys in servers. Use Roles instead.
4. Deny always beats Allow — if two policies conflict, the explicit Deny wins.
5. Principle of Least Privilege — minimum permissions, specific resources, specific actions. Always.
6. MFA is mandatory for humans — especially root and admin users. With MFA a leaked password is useless.
7. Use AWS Managed policies to start, Customer Managed for production — built-in policies are convenient but often too broad for production.

What’s Next

• AWS CLI Getting Started — Put your IAM credentials to work from the command line
• Linux SSH Key Management — The same key-based cryptography that secures AWS EC2 instances
• What is a VPN? — How network security and identity security work together

🧠

Test Your Knowledge

Score: 0/5

Take a quick 5-question quiz to check your understanding.

Start Quiz

Next

0 /5

Retake Quiz