Understanding the Difference Between IAM Roles and Resource-Based Poli

Arjun, a new cloud engineer at a growing startup, just got a task:

“Allow our app in Account A to upload files to an S3 bucket in Account B.”

He thought:
"Cool, I’ll just add an IAM policy!"
But AWS had other plans.

That’s when his senior stepped in and said:

“There are two ways to do it, Arjun — IAM Roles and Resource-Based Policies. Learn the difference. You’ll thank me later.”

Let’s make sure you understand this, too.

🧠 First, What Is a Role in AWS?

IAM Roles are like temporary access cards.

Instead of hardcoding permanent access into users or services, you say:

"Hey AWS, I want this Lambda/EC2/Service to assume a role and get some specific permissions."

So, roles are assigned to trusted entities, like:

IAM users
EC2 instances
Lambda functions
External AWS accounts
Federated users (like SSO)

🧠 SAA Tip: Roles don’t belong to users — they are assumed when needed, like wearing a uniform to do a specific job.

🎯 So Who Creates the Role?

YOU (as the AWS account owner/admin) create the role.

You decide:

Who can assume this role → via a trust policy
What the role can do → via a permissions policy

🔐 What Are Resource-Based Policies?

These are permissions attached directly to the resource itself.

✅ How it works:

Account B directly tells its resource (e.g., S3 bucket):
“Let Account A write data here — no need for role assumption.”
The permission is embedded in the resource itself.

📌 Key Points:

Easier for simple, one-way permissions.
No switching roles, no session credentials.
Only works with certain AWS services (like S3, SNS, SQS, Lambda).

Supported resources include:

S3 Buckets
SNS Topics
SQS Queues
Lambda Functions
API Gateway
KMS Keys

🆚 IAM Role vs Resource-Based Policy — Side-by-Side

Feature	IAM Role	Resource-Based Policy
Who creates it?	Target Account	Target Account
Access Type	Temporary role assumption	Direct access via resource itself
Cross-account friendly	Yes	Yes (if supported)
Ease of use	Moderate (requires assumeRole)	Simple (direct permission)
Service Support	All AWS services	Limited services only
Example	EC2 from Account A assumes role in B	S3 in B allows Account A to write

🧠 When to Use Which?

✅ Use IAM Role when:

You’re dealing with services that don’t support resource policies.
You want more control over temporary access.
You need fine-grained permissions based on who’s requesting.

✅ Use Resource-Based Policy when:

You just need to say: “Let this account/service access this resource.”
You’re working with S3, SNS, SQS, Lambda, etc.
You want less complexity (no role switching).

🔑 Final Shortcut

If you're using S3, Lambda, SNS, or SQS — and just want to allow access from another account → Resource-based policy is often enough.
For more control, or when dealing with services that don’t support resource-based policies, use an IAM Role.

Understanding the Difference Between IAM Roles and Resource-Based Policies