AWS IAM Explained: Users, Roles, and Policies in Plain English

Every AWS service, from EC2 to Lambda to S3, relies on IAM to decide who can do what. If you skip IAM and jump straight to building, you'll eventually lock yourself out of your own resources or, worse, give everyone access to everything. IAM is the first thing you should understand, and the last thing most beginners actually study.

Think of IAM as the Front Desk of a Building

Imagine an office building. The front desk checks your ID (authentication), looks up which floors you're allowed to visit (authorization), and gives you a badge that only opens certain doors (permissions). AWS IAM works the same way. It controls who gets in and what they can touch once inside.

Without IAM, there's no front desk. Every door is unlocked. That's what a root account with no IAM configuration looks like.

Users, Groups, and Roles: The Three Building Blocks

IAM has three core concepts. Understanding when to use each one is more important than memorizing their definitions.

IAM Users

An IAM user represents a single person or application that needs access to your AWS account. Each user gets their own credentials - either a password for console access or access keys for programmatic (CLI/API) access.

When to create an IAM user:

• A team member needs direct console access to manage AWS resources day to day
• An application running outside AWS needs access keys to call AWS APIs
• You need individual audit trails - every IAM user's actions are logged separately in CloudTrail

When NOT to create an IAM user:

• An application running on EC2 or Lambda - use a role instead (more on this below)
• You have more than 10 team members - manage access through groups, not individual user policies

IAM Groups

A group is a collection of IAM users. You attach policies to the group, and every user in that group inherits those permissions. Change the group policy once, and it updates for everyone.

Use groups for:

• Organizing by job function - a "Developers" group with permissions to deploy Lambda functions and read S3 buckets, a "DBAdmins" group with RDS access
• Enforcing least privilege at scale - instead of attaching 15 policies to 15 individual users, attach one policy to one group

A user can belong to multiple groups. Permissions from all groups are combined.

IAM Roles

A role is like a temporary badge. Instead of giving permanent credentials to a user or application, you let them "assume" a role that grants specific permissions for a limited time. The credentials expire automatically.

Use roles for:

• EC2 instances that need to access S3 or DynamoDB — attach a role to the instance instead of hardcoding access keys
• Lambda functions — every Lambda function runs with an execution role that defines what AWS services it can call
• Cross-account access — let users in Account A assume a role in Account B without sharing credentials

Try building a Lambda function with a custom IAM role in the following hands-on lab:

Policies: The Rules That Define Access

Policies are JSON documents that define what actions are allowed or denied on which resources. They're the actual permission rules - users, groups, and roles are just the containers that hold them.

A simple policy looks like this:

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

This policy allows reading objects from a specific S3 bucket. Nothing else. That's the principle of least privilege - grant only the permissions needed for the task, nothing more.

AWS provides two types of policies:

• AWS managed policies - pre-built by AWS for common use cases (e.g., AmazonS3ReadOnlyAccess). Good for getting started.
• Customer managed policies - written by you for your specific needs. Required for production workloads where AWS managed policies are too broad.

Three Mistakes That Will Bite You

Using the root account for daily work. The root account has unrestricted access to everything. If those credentials leak, your entire AWS account is compromised. Create IAM users for daily work and lock the root credentials in a safe.

Attaching policies directly to users instead of groups. It works when you have two users. When you have twenty, you'll have twenty different policy configurations to maintain. Use groups from the start.

Hardcoding access keys in application code. This is the most common IAM mistake in the wild. Access keys in code end up in Git repositories, which end up on GitHub, which get scraped by bots within minutes. Use IAM roles for applications running on AWS. They provide temporary credentials automatically.

Where IAM Fits in Your Cloud Journey

IAM isn't a one-time setup. It's a skill you'll refine as your AWS usage grows. For now, focus on:

• Create an IAM user for yourself and stop using root
• Organize users into groups based on job function
• Use roles for all applications running on AWS services
• Start with AWS managed policies, then customize as you learn what your workloads actually need

If you're studying for the AWS Cloud Practitioner or Solutions Architect exam, IAM is tested heavily. Our practice exams for AWS certifications include domain-level scoring so you can see exactly how your IAM knowledge measures up.