Table of Contents
IAM Roles vs Resource-Based Policies is a common comparison AWS users must understand to manage secure, cross-account access. In this beginner-friendly guide, you’ll follow Arjun, a new cloud engineer at a startup, as he learns the difference between these two powerful AWS access control mechanisms. Through his real-world scenario — enabling an app in Account A to upload files to an S3 bucket in Account B — we’ll break down how IAM Roles and Resource-Based Policies work, when to use each, and how they help secure your AWS environment.
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 vs 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 Roles vs Resource-Based Policies
| 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.
Read More on AWS Advanced IAM
- Understanding AWS IAM Identity Center: A Beginner’s Guide
- Understanding AWS IAM Permission Boundaries
- Understanding the Difference Between IAM Roles and Resource-Based Policies
- How IAM Conditions Improve AWS Security with Detailed Access Permissions
- AWS SCPs Explained: The Key to Cloud Security
- Exploring AWS Organizations: How to Structure and Separate with OUs
