AWS IAM Explained Without Making Your Head Hurt

IAM (Identity and Access Management) is one of the most important services in AWS and one of the most confusing to learn. Here is a plain-language explanation.

## The Core Problem IAM Solves

AWS gives you access to a lot of powerful services. Without access control, anyone with your credentials could do anything to your infrastructure. IAM is the system that controls who can do what.

## The Four Core Concepts

Users
A User is an identity representing a person or application. Users have credentials (password for console, access keys for API).

In modern AWS setups, you should have as few IAM Users as possible. Human users should use SSO (Single Sign-On) or identity federation instead of IAM Users. Machines should use Roles.

Groups
A collection of Users. You assign permissions to Groups instead of individual Users when possible. This makes managing permissions for teams much easier.

Roles
A Role is like a User but with no permanent credentials. Instead, it is assumed temporarily by a service or person that needs its permissions.

Roles are the preferred way to give AWS services permission to interact with other AWS services. An EC2 instance that needs to read from S3 should assume a Role with S3 read permissions — not have hardcoded access keys.

Policies
The actual permission definitions. A Policy is a JSON document that says: "Allow this action on this resource."

Policies are attached to Users, Groups, or Roles.

## The Principle of Least Privilege

The most important IAM concept: give each identity only the permissions it actually needs. Nothing more.

A Lambda function that reads from DynamoDB should only have permission to read from that specific DynamoDB table. Not all DynamoDB tables. Not all services.

This limits the blast radius if credentials are compromised.

## A Common Pattern: Cross-Account Access

This is where IAM gets powerful. You can allow identities in one AWS account to assume roles in another account.

Example: You have a CI/CD pipeline in account A. It needs to deploy to account B. You create a Role in account B that trusts account A. Your pipeline assumes that Role when it needs to deploy.

This is the foundation of multi-account AWS setups.

## The Most Common IAM Mistakes

Too permissive policies: "Action": "*" on "Resource": "*" gives everything access to everything. Never do this outside of a personal sandbox.

Root account access keys: Never create access keys for your root account. Never use root for anything except initial setup and billing.

Unused credentials: Regularly audit IAM Users and Roles. Remove anything that is not being used. Unused credentials are a security liability.

No MFA on privileged accounts: Any account with significant permissions should require Multi-Factor Authentication.

## Reading a Policy Document

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

This allows reading and writing objects in my-bucket. Not deleting. Not listing the bucket. Not accessing any other bucket. This is least privilege in action.

## Where to Start

1. Enable MFA on your root account today if you have not.
2. Create an admin IAM User for daily use instead of using root.
3. Learn to read policy documents.
4. When you create any new service that needs AWS access, create a Role for it with the minimum necessary permissions.

What IAM concept has given you the most trouble?