AWS IAM Role Explained

Think of an AWS IAM Role like a secure building with a job inside.

For example:

• One role lets a Lambda function upload files to S3.
• Another role lets EC2 read from DynamoDB.
• Another role lets CloudFront access a private S3 bucket.

An IAM Role has 2 important parts:

1. Trust Policy → Who is allowed to enter the building?
2. Permissions Policy → What are they allowed to do once inside?

---

1. Trust Policy = “Who can assume this role?”

This answers:

“Which AWS service, user, or account is allowed to use this role?”

It is like the security guard at the entrance.

Example

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

This means:

• AWS Lambda is trusted
• Lambda can “assume” (take/use) this role

✅ Lambda can enter the building.

But this policy does NOT say what Lambda can do yet.

---

2. Permissions Policy = “What can this role do?”

Once Lambda enters the building, permissions decide:

• Can it read S3?
• Can it write logs?
• Can it delete DynamoDB tables?

Example

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

This means:

✅ The role can read objects from S3.

---

Simple Real-Life Analogy

Imagine a school laboratory.

Trust Policy

The lab says:

“Only science teachers may enter.”

That is the trust policy.

Permissions Policy

Inside the lab:

• Teacher can use microscope
• Teacher can use chemicals
• Teacher CANNOT access principal’s office

That is the permissions policy.

---

Important Concept

Both are required.

If trust exists but no permissions

Lambda can assume the role… but cannot do anything useful.

Like entering an empty room.

If permissions exist but no trust

The role has powers… but nobody is allowed to use it.

Like a locked superhero suit nobody can wear.