AWS IAM Guide: Users, Roles, Policies Explained

If cloud computing is renting someone else's computers, then IAM is the lock on the front door. It controls who can get in and what they can do once they are inside.

AWS Identity and Access Management (IAM) is the first service you should learn after creating your AWS account, because every other service depends on it. Misconfigure IAM, and you risk either locking yourself out or leaving the door wide open.

This guide will walk you through IAM from scratch. No prior experience required.

Prerequisites: You should understand cloud computing basics before starting this article.

What You Will Learn

By the end of this article, you will be able to:

• Configure IAM users, groups, and roles from the CLI and explain when to use each one
• Implement least-privilege policies using specific actions, resource ARNs, and conditions (MFA, IP restrictions)
• Troubleshoot "Access Denied" errors by tracing the policy evaluation order through SCPs, permissions boundaries, and identity-based policies
• Explain how IAM role assumption works, including trust policies and temporary credentials, for cross-account and service-to-service access
• Design an IAM strategy for a multi-account organization using groups for team permissions and SCPs for guardrails

Why IAM Matters

When you create an AWS account, you get a single identity called the root user. This user has unrestricted access to everything in the account. Every service, every resource, every billing setting. Think of it as the all-access key to your entire cloud infrastructure.

Using the root user for daily work is like carrying around the all-access key to an office building when you only need to access one room. If someone steals that key, they have access to everything.

IAM solves this problem by letting you create individual identities with limited, specific permissions. Instead of one all-powerful key, you create separate keys that each open only the doors their holder needs.

Authentication vs Authorization

Before diving into IAM components, understand these two distinct concepts:

Authentication answers: "Who are you?" This is the login process. You prove your identity with a username/password, access keys, or MFA token.

Authorization answers: "What are you allowed to do?" After you prove who you are, IAM checks your attached policies to determine which API calls you can make.

Every API call to AWS involves both steps. First AWS verifies your identity, then it checks whether your identity has permission for the requested action.

The Four Building Blocks of IAM

IAM has four core components: users, groups, roles, and policies. Understanding how they fit together is the key to using IAM effectively.

IAM Users

An IAM user represents a single person or application that interacts with AWS. Each user has their own credentials and their own set of permissions.

There are two types of access:

• Console access: A username and password for logging into the AWS Management Console (the web interface)
• Programmatic access: An access key ID and secret access key for using the AWS CLI or SDKs

# Create a new IAM user with the AWS CLI
aws iam create-user --user-name jane.doe

# Create console login credentials
aws iam create-login-profile \
  --user-name jane.doe \
  --password 'TempPassword123!' \
  --password-reset-required

Each person in your organization who needs AWS access should have their own IAM user. Never share credentials between people. If two people use the same account, you cannot tell who did what when something goes wrong.

IAM Users: Important Limits

If you need more than 5,000 identities, use IAM Identity Center (formerly SSO) with federated access instead of creating individual IAM users.

IAM Groups

A group is a collection of IAM users. You attach permissions to the group, and every user in that group inherits those permissions.

This is how you manage permissions at scale. Instead of attaching the same policy to 50 individual developers, you create a "Developers" group, attach the policy once, and add all 50 developers to the group.

# Create a group
aws iam create-group --group-name Developers

# Add a user to the group
aws iam add-user-to-group --group-name Developers --user-name jane.doe

# Attach a policy to the group
aws iam attach-group-policy \
  --group-name Developers \
  --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess

Common group examples:

Key rules:

• Groups cannot be nested. You cannot put a group inside another group.
• Groups are for users only. You cannot add a role to a group.
• A user can belong to up to 10 groups.
• Permissions from all groups are combined (union, not intersection).

IAM Roles

A role is an identity with permissions that is not tied to a specific person. Instead, a role is assumed temporarily by whoever (or whatever) needs it.

Roles are critical because they solve three problems:

1. Granting AWS services permission to act on your behalf.

When an EC2 instance needs to read files from S3, it cannot type in a username and password. Instead, you create a role with S3 read permissions and attach it to the instance. The instance automatically receives temporary credentials.

# Create a role that EC2 instances can assume
aws iam create-role \
  --role-name EC2-S3-ReadOnly \
  --assume-role-policy-document file://trust-policy.json

The trust policy defines who can assume the role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Then attach the permission policy that defines what the role can do:

# Attach a policy that allows reading S3 objects
aws iam attach-role-policy \
  --role-name EC2-S3-ReadOnly \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

# Create an instance profile (required to attach a role to EC2)
aws iam create-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile

aws iam add-role-to-instance-profile \
  --instance-profile-name EC2-S3-ReadOnly-Profile \
  --role-name EC2-S3-ReadOnly

2. Cross-account access.

If your company has a development account and a production account, a developer might need temporary access to production for debugging. A role in the production account can trust the development account, allowing developers to assume the role when needed without creating IAM users in both accounts.

# In the production account: Create a role that trusts the dev account
# Trust policy allows the dev account to assume this role
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

# In the dev account: Assume the production role
aws sts assume-role \
  --role-arn arn:aws:iam::444455556666:role/ProdReadOnly \
  --role-session-name debug-session

3. Federated access.

If your company uses Active Directory, Okta, or another identity provider, roles let external users access AWS without creating IAM users. The external identity provider authenticates the user, and AWS grants temporary credentials through a role.

Why temporary credentials matter: When a user or service assumes a role, AWS issues credentials that expire automatically (default: 1 hour). This means even if those credentials are stolen, the attacker has a limited window. Compare that to an access key that never expires and you can see why roles are the preferred approach.

Two Types of Policies on a Role

Every role has two distinct policies:

This distinction trips up many beginners. The trust policy is the lock on the door. The permission policy is what you can touch once you are inside.

IAM Policies

A policy is a JSON document that defines permissions. It specifies what actions are allowed or denied on which resources, under what conditions.

Every permission in AWS is controlled by policies. If there is no policy granting an action, that action is denied by default.

Here is a policy that allows reading objects from a specific S3 bucket:

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

Let us break down each element:

Understanding ARNs (Amazon Resource Names)

Every resource in AWS has a unique identifier called an ARN. You will use ARNs constantly in IAM policies.

arn:aws:service:region:account-id:resource-type/resource-id

Examples:
arn:aws:s3:::my-bucket                          # S3 bucket (global, no region)
arn:aws:s3:::my-bucket/*                         # All objects in the bucket
arn:aws:ec2:us-east-1:123456789012:instance/i-abc123   # Specific EC2 instance
arn:aws:iam::123456789012:user/jane.doe          # IAM user (global, no region)
arn:aws:dynamodb:us-east-1:123456789012:table/Users    # DynamoDB table

Common ARN gotcha with S3: The bucket itself (arn:aws:s3:::my-bucket) and the objects inside it (arn:aws:s3:::my-bucket/*) are separate resources. If you only specify the bucket ARN, s3:GetObject will not work because GetObject operates on objects, not buckets. You need both ARN formats.

Three Types of Policies

AWS managed policies are created and maintained by AWS. They cover common use cases like AmazonS3ReadOnlyAccess or AdministratorAccess. These are convenient but sometimes grant more permissions than you need.

# List all AWS managed policies (there are hundreds)
aws iam list-policies --scope AWS --max-items 20

# View what a specific managed policy allows
aws iam get-policy-version \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess \
  --version-id v1

Customer managed policies are policies you write yourself. They give you precise control and can be attached to multiple users, groups, or roles. This is the recommended approach for production environments.

Inline policies are embedded directly in a single user, group, or role. They cannot be reused. Use these only when you need a strict one-to-one relationship between a policy and an identity.

Policy Writing Best Practices

The Principle of Least Privilege

Least privilege is the most important security concept in cloud computing. It means granting only the minimum permissions required to perform a task, nothing more.

Here is why it matters:

Scenario 1: Over-permissioned user. You give a developer AdministratorAccess because it is easy. That developer's access keys get leaked in a public GitHub repository (this happens more often than you think). The attacker now has full control of your AWS account, they can launch crypto-mining instances, delete databases, and access customer data.

Scenario 2: Least privilege user. The same developer has a custom policy that grants only the specific EC2 and S3 permissions their application needs. The leaked keys still get exploited, but the damage is contained. The attacker can access one S3 bucket, not your entire account.

The Blast Radius Concept

Think of permissions as a blast radius. If credentials are compromised, how much damage can the attacker do?

Every step down the table reduces the blast radius. Least privilege means staying as far down as possible.

How to Apply Least Privilege

1. Start with zero permissions. New users and roles should have no permissions by default.
2. Add permissions as needed. When someone needs access, grant exactly what they need for their specific task.
3. Use specific resource ARNs. Instead of "Resource": "*" (all resources), specify the exact bucket, table, or instance.
4. Review regularly. Use IAM Access Analyzer and credential reports to find unused permissions and remove them.
5. Use conditions. Require MFA for sensitive actions. Restrict access to specific IP ranges or times.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowReadReportsWithMFA",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-reports-bucket/*",
      "Condition": {
        "Bool": {
          "aws:MultiFactorAuthPresent": "true"
        },
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

This policy allows reading objects from a specific bucket, but only if the user has authenticated with MFA AND is connecting from a specific IP range. Even if someone steals the password, they cannot access the data without the MFA device and the correct network.

Practical Least Privilege Workflow

Here is how to implement least privilege in practice:

1. Start broad, then narrow. Give developers a managed policy like PowerUserAccess during initial development.
2. Enable CloudTrail logging. Record every API call the developer makes.
3. After 30-60 days, review actual usage. Use IAM Access Analyzer to see which permissions were actually used.
4. Create a custom policy. Write a policy that grants only the permissions the developer actually needed.
5. Replace the broad policy. Remove PowerUserAccess and attach the custom policy.
6. Monitor and iterate. If the developer gets "access denied" errors, add the specific missing permission.

# Generate a policy based on CloudTrail activity
aws accessanalyzer generate-policy \
  --policy-generation-details '{"principalArn": "arn:aws:iam::123456789012:user/jane.doe"}' \
  --cloud-trail-details '{
    "trails": [{"cloudTrailArn": "arn:aws:cloudtrail:us-east-1:123456789012:trail/management-trail", "allRegions": true}],
    "accessRole": "arn:aws:iam::123456789012:role/AccessAnalyzerRole",
    "startTime": "2026-04-01T00:00:00Z",
    "endTime": "2026-05-01T00:00:00Z"
  }'

How IAM Policy Evaluation Works

When you make an API request to AWS, IAM evaluates all applicable policies to decide whether to allow or deny the request. The logic follows a specific order.

The Three-Step Evaluation Process

1. Everything starts with an implicit deny. By default, all requests are denied.
2. An explicit allow overrides the implicit deny. If any attached policy allows the action, the request proceeds (unless step 3 applies).
3. An explicit deny always wins. If any policy explicitly denies the action, the request is denied regardless of any allows.

This means a deny always beats an allow. If one policy says "Allow s3:DeleteBucket" and another says "Deny s3:DeleteBucket," the request is denied.

The Full Evaluation Order

In a real AWS environment with organizations, the full evaluation order is:

1. Service Control Policies (SCPs) - Set maximum permissions for the account
2. Resource-based policies - Attached to the resource (like an S3 bucket policy)
3. IAM permissions boundaries - Set maximum permissions for a user/role
4. Session policies - Passed when assuming a role
5. Identity-based policies - Attached to the user, group, or role

All of these must allow the action for it to succeed. Think of them as concentric circles: each layer can only restrict, never expand, what the outer layer allows.

Policy Evaluation Examples

Example 1: User with one policy that allows S3 read

User policy: Allow s3:GetObject on my-bucket/*
Result: ALLOWED (explicit allow, no deny)

Example 2: User with allow and deny on same action

Group policy: Allow s3:GetObject on *
User policy: Deny s3:GetObject on secret-bucket/*
Request: s3:GetObject on secret-bucket/file.pdf
Result: DENIED (explicit deny wins)

Example 3: No relevant policy

User has no S3 policies
Request: s3:GetObject on any-bucket/file.pdf
Result: DENIED (implicit deny, no policy grants access)

Example 4: SCP restricts what IAM allows

SCP: Deny all actions in us-west-2
User policy: Allow ec2:RunInstances in all regions
Request: ec2:RunInstances in us-west-2
Result: DENIED (SCP blocks even though user policy allows)

Securing the Root User: Your First Priority

The moment you create an AWS account, do these three things:

Step 1: Enable MFA on the Root User

Multi-Factor Authentication adds a second verification step beyond your password. Even if your password is compromised, the attacker needs your physical MFA device.

1. Sign in to the AWS Console as the root user
2. Go to IAM > Dashboard > Security recommendations
3. Click Add MFA for the root user
4. Choose a virtual MFA app (like Google Authenticator or Authy) or a hardware key

Step 2: Delete Root User Access Keys

If the root user has access keys, delete them immediately. The root user should never be used for programmatic access.

# Check if root user access keys exist (run as root)
aws iam list-access-keys

# Delete them if they exist
aws iam delete-access-key --access-key-id AKIAEXAMPLE

Step 3: Create an IAM User for Daily Work

Stop using the root user. Create an IAM user with admin permissions and use that instead.

# Create an admin user
aws iam create-user --user-name my-admin

# Add to an admin group
aws iam create-group --group-name Admins
aws iam attach-group-policy \
  --group-name Admins \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess
aws iam add-user-to-group --group-name Admins --user-name my-admin

# Create console login credentials
aws iam create-login-profile \
  --user-name my-admin \
  --password 'ChangeMe!2026' \
  --password-reset-required

# Enable MFA on this user too
# (Do this in the console: IAM > Users > my-admin > Security credentials > MFA)

When You MUST Use Root

The root user should only be used for the handful of tasks that specifically require it:

For everything else, use an IAM user or role.

IAM and AWS Organizations

If you manage multiple AWS accounts (which is the recommended approach for production), AWS Organizations adds another layer of access control.

Service Control Policies (SCPs)

SCPs define the maximum permissions for all accounts in an organizational unit. They do not grant permissions, they restrict them. Even if an IAM policy in an account allows an action, an SCP can block it.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyUSWest2",
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": [
            "us-east-1",
            "us-east-2"
          ]
        }
      }
    }
  ]
}

This SCP restricts all accounts in the organizational unit to only use us-east-1 and us-east-2. A developer with AdministratorAccess still cannot launch resources in eu-west-1.

Multi-Account Strategy Impact on IAM

Common IAM Mistakes Beginners Make

Mistake 1: Using the Root User for Everything

This is the most dangerous mistake. If your root credentials are compromised, the attacker owns your entire account. Use the root user only for account-level tasks that explicitly require it.

Mistake 2: Granting AdministratorAccess to Everyone

It is tempting to give everyone full access because it is simple. Resist this. Every user with admin access is a potential attack vector. Start with read-only access and add permissions incrementally.

Mistake 3: Hardcoding Access Keys in Code

Never embed access keys in application source code, configuration files, or environment variables on production servers. Use IAM roles instead. If your code runs on EC2, attach a role. If it runs on Lambda, the execution role provides credentials automatically.

# BAD: Hardcoded credentials in code
# aws_access_key_id = "AKIAIOSFODNN7EXAMPLE"
# aws_secret_access_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"

# GOOD: Use IAM roles - credentials are provided automatically
# On EC2: Instance profile provides temporary credentials
# On Lambda: Execution role provides temporary credentials
# Locally: Use aws configure or environment variables (never commit these)

Mistake 4: Not Rotating Access Keys

If you must use access keys (for local development, for example), rotate them regularly. AWS recommends rotating keys every 90 days.

# Create a new access key
aws iam create-access-key --user-name jane.doe

# Update your local configuration with the new key
aws configure set aws_access_key_id AKIANEWKEYEXAMPLE
aws configure set aws_secret_access_key wJalrNewSecretKeyEXAMPLE

# Then delete the old key
aws iam delete-access-key \
  --user-name jane.doe \
  --access-key-id AKIAOLDKEYEXAMPLE

Mistake 5: Ignoring IAM Access Analyzer

IAM Access Analyzer identifies resources shared with external entities and flags overly permissive policies. Enable it in every Region you use.

# Enable IAM Access Analyzer
aws accessanalyzer create-analyzer \
  --analyzer-name my-account-analyzer \
  --type ACCOUNT

# List findings (externally shared resources)
aws accessanalyzer list-findings \
  --analyzer-arn arn:aws:access-analyzer:us-east-1:123456789012:analyzer/my-account-analyzer

Mistake 6: Forgetting About Service Control Policies

If your organization uses AWS Organizations, Service Control Policies (SCPs) set the maximum permissions boundary for all accounts in an organizational unit. Even if an IAM policy allows an action, an SCP can block it. Always check SCPs when troubleshooting "access denied" errors in multi-account environments.

Mistake 7: Using Wildcards in Resource ARNs

Using "Resource": "*" means the policy applies to ALL resources of that type across your entire account. This is almost always too broad.

// BAD: Allows deleting ANY DynamoDB table
{
  "Effect": "Allow",
  "Action": "dynamodb:DeleteTable",
  "Resource": "*"
}

// GOOD: Allows deleting only the dev-users table
{
  "Effect": "Allow",
  "Action": "dynamodb:DeleteTable",
  "Resource": "arn:aws:dynamodb:us-east-1:123456789012:table/dev-users"
}

Troubleshooting IAM Access Denied Errors

When you get an "Access Denied" error, work through this checklist:

1. Check the IAM user/role's attached policies. Does any policy explicitly allow the action?
2. Check for explicit denies. Look for deny statements in any attached policy.
3. Check SCPs. If using AWS Organizations, SCPs might block the action.
4. Check permissions boundaries. If a permissions boundary is set, it limits the effective permissions.
5. Check resource-based policies. Some services (S3, SQS, Lambda) have resource-based policies that might deny access.
6. Check the resource ARN. Is the policy targeting the right resource? A common issue is missing the /* for S3 objects.
7. Check the Region. Policies can restrict actions to specific Regions.
8. Check conditions. MFA, IP address, or time conditions might not be met.

# Simulate a policy evaluation (very useful for debugging)
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/jane.doe \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/report.pdf

IAM Best Practices Cheat Sheet

IAM Cost: It is Free

IAM is completely free. There is no charge for creating users, groups, roles, or policies. There is no charge for MFA, Access Analyzer, or credential reports. AWS wants you to use IAM properly, so they removed all cost barriers.

The only indirect cost is the time it takes to design and manage your IAM configuration. But the cost of NOT doing IAM properly (a compromised account, a data breach, unauthorized resource usage) is exponentially higher.

Quick Knowledge Check

Test yourself on these questions before moving on:

1. What is the difference between authentication and authorization in IAM?
2. When should you use a role instead of a user?
3. What happens when one policy allows an action and another policy denies it?
4. Why should you avoid using "Resource": "*" in policies?
5. Name three things you should do to secure the root user.
6. What are the two types of policies attached to an IAM role?
7. What is an SCP and how does it interact with IAM policies?
8. How would you troubleshoot an "Access Denied" error?
9. What is the "blast radius" concept and why does it matter?
10. Why does AWS recommend IAM roles over IAM users for applications?

If you can answer all ten confidently, you have a solid foundation in IAM.

Troubleshooting Common IAM Issues

IAM is one of those areas where most people learn just enough to make things work, then stop. The difference between a junior and senior cloud engineer often comes down to how well they understand IAM policy evaluation, condition keys, and permission boundaries. It is worth investing the time to get this right early because every security incident you prevent is one less 3 AM page.

Build it yourself: This topic is covered hands-on in Module 04: IAM Users and Policies of our AWS Bootcamp, where you write policies from scratch and troubleshoot Access Denied errors.