AWS IAM Roles and Users: Create and Manage IAM Identities

Why this matters

IAM is the foundation of every AWS account. If your identity model is wrong, no amount of encryption or network controls will save you.

• Roles reduce blast radius. Temporary credentials are scoped to a single session. If they are intercepted, the window of exposure is short. Permanent access keys remain valid until someone remembers to rotate them.

• Beginners get IAM wrong when they memorise commands before understanding the identity model. Creating an IAM user and generating access keys is the easiest path, but it is almost never the right one for workloads. Understanding why roles exist, not just how to create them, prevents habits that are painful to undo later.

Simple explanation

For a deeper conceptual overview of how these fit together with policies and permission evaluation, see the IAM in AWS guide.

How IAM identities work

Authentication vs authorisation

Authentication uses a username and password, or an access key pair. Authorisation is handled by IAM policies. Every API call in AWS goes through both checks: “is this caller who they claim to be?” and “does the attached policy allow this action?”

Users, groups, and policies

An IAM user can have policies attached directly, but that does not scale. Instead, you create groups (like Developers or Auditors), attach policies to the group, and add users to it. When someone changes teams, you move them between groups instead of rewriting their permissions.

Trust policy vs permissions policy

Every IAM role has two kinds of policy. The trust policy says who can assume the role, for example the Lambda service or a specific account ID. The permissions policy says what the role can do once assumed, for example reading objects from an S3 bucket. Mixing these up is one of the most common beginner mistakes. For a deep dive, see IAM roles explained.

STS and temporary credentials

When a service assumes a role, AWS Security Token Service (STS) returns a temporary access key, secret key, and session token. These credentials expire automatically, typically after one hour (though the duration is configurable). Because they are short-lived, there is nothing to rotate and nothing that stays valid if leaked. See AWS STS and temporary credentials for the full picture.

Why EC2 needs an instance profile

When to use this

Here are the most common scenarios and which identity to reach for:

• Human admin needs console and CLI access. Create an IAM user (or, in multi-account setups, use IAM Identity Center). Add the user to a group with appropriate permissions. Enable MFA.

• Application running on EC2. Create an IAM role with EC2 as the trusted principal. Create an instance profile, add the role, and attach the profile to the instance. The application retrieves temporary credentials from the metadata service automatically, with no access keys needed.

• Lambda function needs S3 access. Create an IAM role with Lambda as the trusted principal. Attach a permissions policy that grants the specific S3 actions your function needs. Assign the role when you create or update the function.

• Cross-account read access. Create a role in the target account with a trust policy that allows the source account to assume it. Use an ExternalId condition for third-party access. See role assumption in AWS for the full pattern.

• Legacy service account that cannot assume a role. Some older tools or on-premises scripts genuinely require static credentials. In that case, create an IAM user with only programmatic access, scope its policy tightly, and rotate keys on a schedule. This should be the exception, not the default.

Before you start

You need the iam:CreateUser, iam:CreateRole, and related permissions to manage IAM identities. If you are the account root user or have administrator access, you already have these.

All examples below use the AWS CLI. If you have not set it up yet, run aws configure with the credentials of an IAM user or role that has IAM admin permissions. For a broader reference of IAM CLI commands, see managing IAM with the AWS CLI.

Creating and managing IAM users

Create an IAM user when a human needs direct AWS access and your organisation does not use IAM Identity Center (SSO). Each user gets their own credentials and can be added to groups for permission management.

Create a user with console access

# Create the user
aws iam create-user --user-name bob

# Give them a console password (they will be forced to change it on first login)
aws iam create-login-profile \
  --user-name bob \
  --password "InitialPassword123!" \
  --password-reset-required

Create programmatic access keys

Only do this if the user genuinely needs CLI or API access with long-term credentials. For workloads, use a role instead.

# Generate an access key pair
aws iam create-access-key --user-name bob

List and inspect users

# List all users in the account with key details
aws iam list-users \
  --query 'Users[*].{Name:UserName,Created:CreateDate,PasswordLastUsed:PasswordLastUsed}' \
  --output table

# Get details about a specific user
aws iam get-user --user-name bob

Delete a user safely

You cannot delete an IAM user that still has resources attached. Remove everything first, in this order:

# 1. Delete the console login profile
aws iam delete-login-profile --user-name bob

# 2. Delete all access keys
aws iam list-access-keys --user-name bob
aws iam delete-access-key --user-name bob --access-key-id AKIAXXXXXXXXXXXXXXXX

# 3. Detach all managed policies
aws iam list-attached-user-policies --user-name bob
aws iam detach-user-policy --user-name bob \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# 4. Delete all inline policies
aws iam list-user-policies --user-name bob
aws iam delete-user-policy --user-name bob --policy-name SomeInlinePolicy

# 5. Remove from all groups
aws iam list-groups-for-user --user-name bob
aws iam remove-user-from-group --user-name bob --group-name Developers

# 6. Now delete the user
aws iam delete-user --user-name bob

Creating and managing groups

Groups let you assign permissions once and have every member inherit them automatically. Instead of attaching policies to each user individually, attach them to the group and manage team membership.

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

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

# Add a user to the group
aws iam add-user-to-group --user-name bob --group-name Developers

# List which groups a user belongs to
aws iam list-groups-for-user --user-name bob

# List all users in a group
aws iam get-group --group-name Developers \
  --query 'Users[*].UserName' --output text

# Remove a user from a group
aws iam remove-user-from-group --user-name bob --group-name Developers

Creating and managing roles

Roles are the backbone of secure AWS access for services, applications, and cross-account workflows. Every role needs a trust policy (who can assume it) and at least one permissions policy (what it can do).

Role for a Lambda function

This creates a role that the Lambda service can assume, then attaches policies granting CloudWatch Logs and S3 read access.

# Create the role with a trust policy allowing Lambda to assume it
aws iam create-role \
  --role-name my-lambda-execution-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "lambda.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# Attach the basic Lambda execution policy (CloudWatch Logs access)
aws iam attach-role-policy \
  --role-name my-lambda-execution-role \
  --policy-arn arn:aws:iam::aws:policy/service-role/AWSLambdaBasicExecutionRole

# Add S3 read access
aws iam attach-role-policy \
  --role-name my-lambda-execution-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Role for an EC2 instance

EC2 requires an extra step: you must create an instance profile to deliver the role’s credentials to the instance. Without the instance profile, the role exists but EC2 cannot use it.

# Create the role with a trust policy allowing EC2 to assume it
aws iam create-role \
  --role-name my-ec2-role \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {"Service": "ec2.amazonaws.com"},
      "Action": "sts:AssumeRole"
    }]
  }'

# Attach a policy granting SSM access (Session Manager without SSH keys)
aws iam attach-role-policy \
  --role-name my-ec2-role \
  --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

# Create the instance profile and add the role to it
aws iam create-instance-profile --instance-profile-name my-ec2-profile
aws iam add-role-to-instance-profile \
  --instance-profile-name my-ec2-profile \
  --role-name my-ec2-role

# When launching an instance, specify the profile:
# aws ec2 run-instances --instance-profile Name=my-ec2-profile ...

Cross-account role

This role lives in Account B and allows Account A to assume it. The ExternalId condition prevents the confused deputy problem when granting access to third parties. For the full cross-account pattern, see role assumption in AWS.

# In Account B: create a role that Account A can assume
aws iam create-role \
  --role-name CrossAccountReadRole \
  --assume-role-policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111111111111:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"
        }
      }
    }]
  }'

# From Account A: assume the role and get temporary credentials
aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/CrossAccountReadRole \
  --role-session-name cross-account-session \
  --external-id unique-external-id-12345

Creating custom policies

AWS managed policies are convenient but often grant more permissions than you need. Write a custom policy when you want least-privilege access: only the specific actions on the specific resources your workload requires. For details on how the JSON structure works, see IAM policy structure.

The example below grants an application read/write access to a single S3 bucket, restricted to the uploads/ prefix. This is far tighter than attaching AmazonS3FullAccess, which would grant access to every bucket in the account.

# Write the policy document to a file
cat > my-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-app-bucket/uploads/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::my-app-bucket",
      "Condition": {
        "StringLike": {
          "s3:prefix": ["uploads/*"]
        }
      }
    }
  ]
}
EOF

# Create the policy in IAM
aws iam create-policy \
  --policy-name MyAppUploadPolicy \
  --policy-document file://my-policy.json \
  --description "Read/write access to my-app-bucket uploads prefix only"

# Attach it to a role
aws iam attach-role-policy \
  --role-name my-lambda-execution-role \
  --policy-arn arn:aws:iam::123456789012:policy/MyAppUploadPolicy

You can also add conditions to policies for even finer control, such as restricting access by source IP or requiring MFA. See IAM policy conditions for examples.

Auditing IAM

IAM identities accumulate like clutter in a garage. People join the team, get permissions, and leave. Services get launched with broad policies “just for now” and nobody circles back. Regular audits catch stale users, unused permissions, and forgotten access keys before they become security incidents.

# Generate the credential report (CSV listing all users, key ages, MFA status)
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 --decode

# List all managed policies attached to a role
aws iam list-attached-role-policies --role-name my-lambda-execution-role

# List all inline policies on a user
aws iam list-user-policies --user-name bob

# Check when services were last accessed by a role (helps find unused permissions)
aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::123456789012:role/my-lambda-execution-role

# Retrieve the results (wait a few seconds after generating)
aws iam get-service-last-accessed-details \
  --job-id <job-id-from-above> \
  --query 'ServicesLastAccessed[?TotalAuthenticatedEntities > `0`].{Service:ServiceName,LastAuth:LastAuthenticated}' \
  --output table

IAM users vs roles

Use a user when:

• A human needs console access and your organisation does not use SSO
• An external tool requires static credentials and genuinely cannot assume a role

Use a role when:

• An AWS service (EC2, Lambda, ECS, CodeBuild) needs to call other AWS APIs
• You need cross-account access
• A CI/CD pipeline runs in AWS and needs deployment permissions
• You want to grant time-limited elevated access to a human (role assumption)

For a deeper comparison with more examples and security tradeoffs, see the dedicated IAM users vs roles guide.