AWS IAM Roles: 10 Practical Examples Step by Step

By Ravindra Bagale, trainer · LinkedIn · Last updated: 24 October 2026

1. Everyday example first

Why do we need this?

Think of an office visitor badge in Hinjewadi, Pune.

Security does not give a visitor the master key. They give a badge for one floor, for one day.

In AWS, long-lived access keys are the master key. A role is the visitor badge.

What is it?

Every role has two parts. Remember them for all 10 examples below.

• Trust policy — who may wear the badge (EC2, Lambda, another account, GitHub).
• Permissions policy — which doors the badge opens (S3 read, DynamoDB write).

All examples use region ap-south-1 (Mumbai). Replace 111111111111 with your account id.

2. Example 1: EC2 reads an S3 bucket

Why do we need this?

Your app on EC2 must read files from S3. Beginners copy access keys into ~/.aws/credentials. Anyone who gets into the server gets the keys.

What is it?

An instance profile is a box that carries a role to EC2. The instance gets fresh temporary keys from the metadata service. No keys on disk.

Trust policy (who can use the role):

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

Permissions policy (what the role can do):

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

How to do it (step by step)

1. IAM → Roles → Create role.
2. Trusted entity: AWS service → Use case EC2 → Next.
3. Create the permissions policy above as ec2-s3-read-ravi and select it.
4. Role name: ec2-s3-read-role → Create role.
5. EC2 → select instance → Actions → Security → Modify IAM role → pick the role → Update.

Verify with CLI:

# run on the EC2 instance
aws sts get-caller-identity
aws s3 ls s3://ravi-app-files/ --region ap-south-1

Expected output:

"Arn": "arn:aws:sts::111111111111:assumed-role/ec2-s3-read-role/i-0abc123..."
2026-10-24 10:00:00   1024 report.csv

3. Example 2: Lambda writes to DynamoDB

Why do we need this?

An order API Lambda must save orders. It must not delete the whole table.

What is it?

The execution role is the role Lambda wears every time it runs.

Trust policy (who can use the role):

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

Permissions policy (what the role can do):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["dynamodb:PutItem", "dynamodb:GetItem"],
    "Resource": "arn:aws:dynamodb:ap-south-1:111111111111:table/Orders"
  }]
}

How to do it (step by step)

1. IAM → Roles → Create role → AWS service → Lambda.
2. Attach the policy above (name lambda-orders-write) and AWSLambdaBasicExecutionRole.
3. Role name: orders-lambda-role.
4. Lambda → your function → Configuration → Permissions → Edit → choose this role → Save.

Verify with CLI:

aws lambda invoke --function-name orders-api \
  --payload '{"id":"o1"}' --cli-binary-format raw-in-base64-out \
  out.json --region ap-south-1
aws dynamodb get-item --table-name Orders \
  --key '{"id":{"S":"o1"}}' --region ap-south-1

Expected output:

{ "StatusCode": 200 }
{ "Item": { "id": { "S": "o1" } } }

4. Example 3: Lambda writes CloudWatch Logs

Why do we need this?

Your print() or console.log() lines must reach CloudWatch. Otherwise you debug blind.

What is it?

AWSLambdaBasicExecutionRole is an AWS managed policy. It allows only log group and log stream writes.

Trust policy (who can use the role):

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

Permissions policy (what the role can do):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "logs:CreateLogGroup",
      "logs:CreateLogStream",
      "logs:PutLogEvents"
    ],
    "Resource": "*"
  }]
}

How to do it (step by step)

1. Lambda → Create function → leave Create a new role with basic Lambda permissions selected.
2. Create function. AWS makes a role like my-fn-role-abc123.
3. Click Test once.
4. Monitor → View CloudWatch logs.

Verify with CLI:

aws logs describe-log-groups \
  --log-group-name-prefix /aws/lambda/my-fn --region ap-south-1

Expected output:

"logGroupName": "/aws/lambda/my-fn"

5. Example 4: EC2 sends logs and metrics with the CloudWatch agent

Why do we need this?

Default EC2 metrics do not show memory or disk use. The CloudWatch agent sends them, plus app log files.

What is it?

Attach the AWS managed policy CloudWatchAgentServerPolicy to an EC2 role.

Trust policy (who can use the role):

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

Permissions policy (what the role can do):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": [
      "cloudwatch:PutMetricData",
      "logs:CreateLogStream",
      "logs:PutLogEvents",
      "logs:DescribeLogStreams",
      "ec2:DescribeTags"
    ],
    "Resource": "*"
  }]
}
// short view of CloudWatchAgentServerPolicy

How to do it (step by step)

1. IAM → Roles → Create role → AWS service → EC2.
2. Attach CloudWatchAgentServerPolicy. Name it ec2-cw-agent-role.
3. Attach the role to the instance (Actions → Security → Modify IAM role).
4. On the instance: sudo yum install -y amazon-cloudwatch-agent.
5. Run the wizard: sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard, then start the agent.

Verify with CLI:

aws cloudwatch list-metrics --namespace CWAgent --region ap-south-1

Expected output:

"MetricName": "mem_used_percent"

6. Example 5: ECS Fargate task role vs task execution role

Why do we need this?

Fargate has two roles. Mixing them up is the top ECS interview trap.

What is it?

The task execution role is for ECS itself: pull the image from ECR, write container logs. The task role is for your app code: call S3, DynamoDB, SQS.

Trust policy (who can use the role):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "ecs-tasks.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
// same trust for both roles

Permissions policy (what the role can do):

// task execution role: attach AWS managed
//   AmazonECSTaskExecutionRolePolicy
// task role (your app):
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::ravi-app-files/*"
  }]
}

How to do it (step by step)

1. IAM → Create role → AWS service → Elastic Container Service Task.
2. Role 1: attach AmazonECSTaskExecutionRolePolicy. Name ecsTaskExecutionRole.
3. Role 2: attach your S3 read policy. Name orders-task-role.
4. ECS → Task definitions → Create → set Task execution role = role 1 and Task role = role 2.

Verify with CLI:

aws ecs describe-task-definition --task-definition orders \
  --query "taskDefinition.[taskRoleArn,executionRoleArn]" \
  --region ap-south-1

Expected output:

[ "arn:aws:iam::111111111111:role/orders-task-role",
  "arn:aws:iam::111111111111:role/ecsTaskExecutionRole" ]

7. Example 6: Cross-account access (account A assumes a role in account B)

Why do we need this?

Your company has a dev account (A, 111111111111) and a prod account (B, 222222222222). A tester in A must read logs in B. Do not create a user in B.

What is it?

Create a role in B that trusts account A. A user in A calls sts assume-role and gets temporary keys for B.

Trust policy (who can use the role):

// in account B (222222222222)
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:root" },
    "Action": "sts:AssumeRole",
    "Condition": { "StringEquals": { "sts:ExternalId": "ravi-2026" } }
  }]
}

Permissions policy (what the role can do):

// in account B: role permissions
// attach AWS managed CloudWatchLogsReadOnlyAccess
// in account A: user/group permission to assume
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::222222222222:role/prod-log-reader"
  }]
}

How to do it (step by step)

1. Sign in to account B → IAM → Create role → AWS account → Another AWS account → enter 111111111111.
2. Tick Require external ID → ravi-2026.
3. Attach CloudWatchLogsReadOnlyAccess. Name prod-log-reader.
4. In account A, attach the assume policy above to the tester group.

Verify with CLI:

aws sts assume-role \
  --role-arn arn:aws:iam::222222222222:role/prod-log-reader \
  --role-session-name ravi-tester --external-id ravi-2026
# export the 3 values, then:
aws sts get-caller-identity

Expected output:

"Account": "222222222222",
"Arn": "arn:aws:sts::222222222222:assumed-role/prod-log-reader/ravi-tester"

8. Example 7: GitHub Actions deploys to AWS with an OIDC role

Why do we need this?

Storing AWS_ACCESS_KEY_ID in GitHub secrets is risky. Keys never expire and can leak from logs or forks.

What is it?

GitHub gives each workflow run a signed OIDC token. AWS trusts GitHub as an identity provider and swaps the token for temporary keys.

Trust policy (who can use the role):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::111111111111:oidc-provider/token.actions.githubusercontent.com"
    },
    "Action": "sts:AssumeRoleWithWebIdentity",
    "Condition": {
      "StringEquals": {
        "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
      },
      "StringLike": {
        "token.actions.githubusercontent.com:sub": "repo:ravindrabagale/site:ref:refs/heads/main"
      }
    }
  }]
}

Permissions policy (what the role can do):

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

How to do it (step by step)

1. IAM → Identity providers → Add provider → OpenID Connect.
2. Provider URL https://token.actions.githubusercontent.com, audience sts.amazonaws.com → Add.
3. IAM → Create role → Web identity → pick this provider → enter your GitHub org, repo and branch.
4. Attach the S3 deploy policy. Name github-deploy-role.
5. In the workflow add permissions: id-token: write and step aws-actions/configure-aws-credentials with role-to-assume and aws-region: ap-south-1.

Verify with CLI:

# workflow step
- run: aws sts get-caller-identity

Expected output:

"Arn": "arn:aws:sts::111111111111:assumed-role/github-deploy-role/GitHubActions"

9. Example 8: Developer read-only role with Switch role

Why do we need this?

A developer needs to look at prod, not change it. Giving them a full user in prod is too much.

What is it?

A ReadOnlyAccess role. The developer clicks Switch role in the console. MFA is required in the trust.

Trust policy (who can use the role):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111111111111:user/priya" },
    "Action": "sts:AssumeRole",
    "Condition": { "Bool": { "aws:MultiFactorAuthPresent": "true" } }
  }]
}

Permissions policy (what the role can do):

// attach AWS managed policy: ReadOnlyAccess

How to do it (step by step)

1. IAM → Create role → AWS account → This account (or another) → tick Require MFA.
2. Attach ReadOnlyAccess. Name dev-readonly.
3. Developer signs in with MFA → top-right account menu → Switch role.
4. Enter account id, role dev-readonly, a display name and colour → Switch Role.

Verify with CLI:

# CLI profile in ~/.aws/config
[profile ro]
role_arn = arn:aws:iam::111111111111:role/dev-readonly
source_profile = default
mfa_serial = arn:aws:iam::111111111111:mfa/priya

aws ec2 describe-instances --profile ro --region ap-south-1
aws ec2 stop-instances --instance-ids i-0abc --profile ro

Expected output:

Enter MFA code for arn:aws:iam::111111111111:mfa/priya:
{ "Reservations": [ ... ] }
An error occurred (UnauthorizedOperation) ... stop-instances

10. Example 9: Service-linked role (Auto Scaling and ELB)

Why do we need this?

Auto Scaling must launch and stop EC2 for you. ELB must register targets. They need permission in your account.

What is it?

A service-linked role is created and owned by the AWS service. Its name starts with AWSServiceRoleFor. You cannot edit its permissions.

Trust policy (who can use the role):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "Service": "autoscaling.amazonaws.com" },
    "Action": "sts:AssumeRole"
  }]
}
// AWS writes this for you

Permissions policy (what the role can do):

// AWS managed, locked:
// AutoScalingServiceRolePolicy
// You only read it. You do not edit it.

How to do it (step by step)

1. Create your first Auto Scaling group or load balancer. AWS creates the role on its own.
2. IAM → Roles → search AWSServiceRoleFor.
3. Open AWSServiceRoleForAutoScaling → read Trust relationships and Permissions.
4. Do not delete it while any Auto Scaling group exists.

Verify with CLI:

aws iam get-role --role-name AWSServiceRoleForAutoScaling \
  --query "Role.[Path,Arn]"

Expected output:

[ "/aws-service-role/autoscaling.amazonaws.com/",
  "arn:aws:iam::111111111111:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling" ]

11. Example 10: EC2 reads Secrets Manager and SSM Parameter Store

Why do we need this?

Your app needs a DB password. Hard-coding it in .env or Git is a classic leak.

What is it?

Store the password in Secrets Manager (or a SecureString parameter). The EC2 role reads only that one secret.

Trust policy (who can use the role):

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

Permissions policy (what the role can do):

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow",
      "Action": "secretsmanager:GetSecretValue",
      "Resource": "arn:aws:secretsmanager:ap-south-1:111111111111:secret:prod/db-*" },
    { "Effect": "Allow",
      "Action": "ssm:GetParameter",
      "Resource": "arn:aws:ssm:ap-south-1:111111111111:parameter/app/db_host" }
  ]
}

How to do it (step by step)

1. Secrets Manager → Store a new secret → Other type → key password → name prod/db.
2. Systems Manager → Parameter Store → Create → /app/db_host.
3. Add the policy above to your EC2 role (inline or customer managed).
4. Attach the role to the instance.

Verify with CLI:

aws secretsmanager get-secret-value --secret-id prod/db \
  --query SecretString --output text --region ap-south-1
aws ssm get-parameter --name /app/db_host \
  --query Parameter.Value --output text --region ap-south-1

Expected output:

{"password":"..."}
mydb.abc123.ap-south-1.rds.amazonaws.com

12. Code needs no keys when a role is attached

Why do we need this?

Students ask: “Where do I put the key in my code?” The answer is: nowhere.

What is it?

Every AWS SDK follows the default credential chain. It finds the role keys from EC2 metadata, Lambda or ECS by itself.

How to do it (step by step)

Python (boto3)

import boto3
s3 = boto3.client("s3", region_name="ap-south-1")   # no keys
print(s3.list_objects_v2(Bucket="ravi-app-files")["KeyCount"])

Node.js (SDK v3)

import { S3Client, ListObjectsV2Command } from "@aws-sdk/client-s3";
const s3 = new S3Client({ region: "ap-south-1" }); // no keys
const r = await s3.send(new ListObjectsV2Command({ Bucket: "ravi-app-files" }));
console.log(r.KeyCount);

Java (SDK v2)

S3Client s3 = S3Client.builder()
    .region(Region.AP_SOUTH_1)       // no keys
    .build();
System.out.println(s3.listObjectsV2(r -> r.bucket("ravi-app-files")).keyCount());

AWS CLI

aws s3 ls s3://ravi-app-files/ --region ap-south-1
# no aws configure needed on EC2 / Lambda / ECS with a role

13. Role vs access keys

14. Common errors and fixes

15. Cleanup

1. Detach roles from EC2 instances and stop or terminate lab instances.
2. Delete lab Lambda functions, ECS task definitions and log groups.
3. IAM → Roles → delete each lab role you created (not the AWSServiceRoleFor… ones).
4. Delete customer managed lab policies.
5. Remove the GitHub OIDC provider if you do not need it.
6. Delete the lab secret (choose 7-day recovery) and parameter.

16. Interview angles

Revision, comparison and interview cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

More cards: Ravi Sir's Cards.