Table of Contents
IAM Role vs Resource Policy is one of the most misunderstood topics in AWS cross-account access. Let’s break it down with examples.
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 Policy: Key Differences
| 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
When managing access between AWS accounts, clarity is key. IAM Roles offer more flexibility and control but require role assumption. Resource-Based Policies are easier to apply for supported services like S3, SNS, and Lambda. By understanding IAM Role vs Resource Policy clearly, you’ll save debugging time, improve security, and implement AWS best practices confidently.
- 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
- Master IAM Role in AWS: Secure Access Guide
- IAM Roles vs Resource-Based Policies: Clear Guide
- Master IAM Permission Boundaries in AWS
- IAM Identity Center: One Secure Login for All
- Master IAM Role vs Resource Policy in AWS Fast
- Master IAM Policy Conditions for AWS Security
