AWS IAM Explained: Users, Roles, Policies and Permissions

What AWS IAM is

IAM handles two things: authentication (proving you are who you say you are) and authorization (deciding whether you have permission to do what you are trying to do). When you sign into the AWS Management Console, IAM authenticates you. When you run an AWS CLI command, IAM checks whether your identity has permission to perform that action.

IAM is a global service. Unlike most AWS services that are scoped to a specific region, the users, roles, and policies you create in IAM are available across every region in your account.

AWS IAM explained simply

Why IAM matters

IAM is not optional and it is not something you configure once and forget. Every AWS account uses it whether you realize it or not.

• Security. IAM is where you enforce least privilege, giving each identity only the permissions it needs. A Lambda function that only reads from one S3 bucket should not have permission to delete EC2 instances.

• Operational stability. Under-permissioned roles break deployments. If your CI/CD pipeline’s role cannot push to ECR or update a Lambda function, the deployment fails silently or with a cryptic AccessDenied error.

• Auditability. Combined with CloudTrail, IAM gives you a record of who did what, when, and whether it was allowed. That audit trail is essential for incident response and compliance.

Core IAM building blocks

Users

An IAM user is a permanent identity that represents a single person. Each user has their own credentials: a password for console access and optionally access keys for CLI and API access. Users are fine for human operators, but long-lived access keys are a security risk and should be avoided where possible.

Groups

A group is a collection of users. Policies attached to a group apply to every user in it. Instead of attaching the same policy to ten developers individually, create a Developers group and attach the policy once. When someone joins the team, add them to the group. When they leave, remove them.

Roles

An IAM role is an identity that issues temporary credentials when assumed. Roles are not tied to a specific person. They are the preferred way to grant permissions to AWS services (a Lambda function, an EC2 instance), to applications, and to users who need cross-account access. Temporary credentials expire automatically, which makes roles inherently safer than long-lived user credentials. See IAM Roles Explained for a deeper look.

Policies

A policy is a JSON document that defines what actions are allowed or denied on which resources. Policies are the rules. They do nothing on their own and only take effect when attached to a user, group, or role. For a full breakdown of policy syntax, see IAM Policy Structure.

Resources

Resources are the AWS objects being acted upon: an S3 bucket, an EC2 instance, a DynamoDB table. In policies, resources are identified by their ARN (Amazon Resource Name), like arn:aws:s3:::my-app-bucket/*.

Actions

Actions are the specific API operations being controlled. The format is service:OperationName. Examples: s3:GetObject, ec2:StartInstances, iam:CreateRole.

Conditions

Conditions add extra constraints to a policy statement. You can restrict access based on IP address, time of day, whether MFA was used, or dozens of other context keys. Conditions let you write policies like “allow this action only if the request comes from the corporate network.” See IAM Policy Conditions for details and examples.

How IAM permission evaluation works

When any principal makes an API call, IAM evaluates all applicable policies to decide whether the action is allowed or denied. The logic follows a specific order:

1. Start with default deny. Everything is denied unless explicitly allowed. A missing policy is a deny, not a gap.
2. Check for explicit deny. If any attached policy has “Effect”: “Deny” for this action, the request is denied immediately. Explicit denies always win.
3. Check Service Control Policies (SCPs). If the account is part of AWS Organizations, SCPs set the maximum permissions for the entire account. If an SCP does not allow the action, it is denied regardless of IAM policies.
4. Check permission boundaries. If the role or user has a permission boundary set, the action must be allowed by both the boundary and the identity policy. The boundary acts as a ceiling.
5. Check identity-based policies. Is there an “Effect”: “Allow” for this action on this resource in the user’s, group’s, or role’s attached policies?
6. Check resource-based policies. Does the resource itself (like an S3 bucket policy) grant access to this principal?
7. If no allow was found, deny. The default deny applies.

IAM users vs groups vs roles

The general rule: use users for humans who need console or CLI access, groups to manage those users’ permissions at scale, and roles for everything else. If you are granting permissions to an AWS service or an application, always use a role. For a detailed comparison, see IAM Users vs Roles.

Identity-based vs resource-based policies

S3 example. You can grant a role access to an S3 bucket in two ways. An identity-based policy on the role says “this role can read from this bucket.” A resource-based policy (bucket policy) on the S3 bucket says “this bucket allows this role to read.” Both work. For cross-account access, resource-based policies are often simpler. For a full comparison, see S3 IAM vs Bucket Policies.

AWS also distinguishes between AWS managed policies and customer managed policies. AWS managed policies cover common use cases and are maintained by AWS. Customer managed policies give you precise control but you maintain them yourself.

When to use this

You will interact with IAM almost immediately when using AWS. Here are the most common situations:

• Console access. When you create an AWS account, you sign in as the root user. Your first IAM task is creating a separate IAM user for daily work so you stop using root.

• Application-to-service access. A Lambda function needs to read from DynamoDB or write to S3. You create a role with exactly those permissions and assign it to the function.

• Cross-account access. Your staging and production environments live in separate accounts. You create a role in the production account that your CI/CD pipeline in the staging account can assume.

• Temporary credentials. Instead of embedding access keys in your code, use roles and STS temporary credentials that expire automatically.

• Team management. You have five developers who all need the same permissions. Create a group, attach a policy to it, and add each developer to the group.

Common IAM use cases

A developer signing into the AWS console

An admin creates an IAM user with a password and console access. The user is added to a Developers group that has the PowerUserAccess managed policy attached. The developer signs in through the IAM sign-in URL and can use most AWS services but cannot manage IAM itself.

A Lambda function accessing S3

You create an IAM role with a policy that allows s3:GetObject on a specific bucket. You assign that role as the Lambda function’s execution role. When the function runs, it automatically receives temporary credentials scoped to that role’s permissions. No access keys are stored in code.

An EC2 instance using a role

Instead of putting access keys on the instance, you create an instance profile with an IAM role. The EC2 instance automatically gets temporary credentials from the instance metadata service. Any application running on the instance can use those credentials to call AWS APIs.

Cross-account access via role assumption

Account A needs to read data from a DynamoDB table in Account B. Account B creates a role with the needed permissions and a trust policy that allows Account A to assume it. A principal in Account A calls sts:AssumeRole, gets temporary credentials for Account B’s role, and uses them to read the table. See Role Assumption in AWS for a full walkthrough.

Example: a minimal IAM policy

This policy allows reading and writing objects in one S3 bucket and listing its contents. It grants nothing else.

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

# Create the policy from a JSON file
aws iam create-policy \
  --policy-name MyAppS3Policy \
  --policy-document file://my-policy.json

# Attach it to a role
aws iam attach-role-policy \
  --role-name my-app-role \
  --policy-arn arn:aws:iam::123456789012:policy/MyAppS3Policy

How to debug AccessDenied errors

AccessDenied is one of the most common errors in AWS. Here is a practical checklist for diagnosing it:

1. Identify the principal. Which user or role made the request? Check the error message or CloudTrail event for the ARN.
2. Check identity-based policies. Does the user or role have a policy that allows this specific action on this specific resource ARN?
3. Check resource-based policies. If the resource (S3 bucket, KMS key, SQS queue) has its own policy, does it allow this principal?
4. Check for explicit denies. Look at all attached policies, SCPs, and permission boundaries for any “Effect”: “Deny” that matches the action.
5. Verify the resource ARN. A common mistake is targeting the bucket ARN when the action requires the object ARN (with /*), or vice versa.
6. Check SCPs and permission boundaries. If the account is in an Organization, an SCP may block the action even if the IAM policy allows it.
7. Simulate the policy. Use the IAM Policy Simulator to test whether the action is allowed.

# Simulate whether a specific action is allowed for a role
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/my-app-role \
  --action-names s3:GetObject \
  --resource-arns arn:aws:s3:::my-bucket/file.txt \
  --query 'EvaluationResults[*].{Action:EvalActionName,Decision:EvalDecision}' \
  --output table