How do resource policies differ from IAM policies?

IAM policies attach to users, groups, or roles and define what those principals can do. Resource policies attach to the resource itself and define who can access it. A key difference is that resource policies can grant cross-account access directly — the calling account does not need to assume a role. When both IAM and resource policies apply, AWS evaluates them together: within the same account, the union of permissions applies. For cross-account access, both the caller's IAM policy and the resource policy must allow the action.

Which AWS services support resource-based policies?

Common services include S3 (bucket policies), SQS (queue policies), SNS (topic policies), Lambda (function policies), KMS (key policies), Secrets Manager, ECR, API Gateway, and EventBridge. Each service has slightly different supported condition keys and actions. Not all services support resource policies — for services like EC2 or RDS, you must use IAM roles for cross-account access.

Resource Policy Builder

IAM & SecurityAWS

Build cross-account resource policies for S3, SQS, SNS, and Lambda.

Cross-Account Resource Policy

Statement 1

SID (optional)

Effect

Principal (comma-separated for multiple)

Actions (comma-separated)

Resources (comma-separated)

Condition Operator

Condition Key

Condition Value

Generated Resource Policy

Output will appear here...

About This Tool

Resource-based policies in AWS attach directly to resources like S3 buckets, SQS queues, SNS topics, and Lambda functions, controlling who can access the resource and under what conditions. Unlike identity-based IAM policies that travel with the principal, resource policies stay with the resource and can grant cross-account access without requiring IAM role assumption. The Resource Policy Builder generates syntactically correct policy documents with proper Principal, Action, Resource, and Condition blocks for the most common cross-account and service-to-service access patterns.

When to Use This Tool

•Granting another AWS account access to an S3 bucket or specific prefix without creating cross-account IAM roles
•Allowing an SNS topic to trigger a Lambda function owned by a different account
•Building SQS queue policies that permit EventBridge rules or S3 event notifications to send messages

Frequently Asked Questions

How do resource policies differ from IAM policies?: IAM policies attach to users, groups, or roles and define what those principals can do. Resource policies attach to the resource itself and define who can access it. A key difference is that resource policies can grant cross-account access directly — the calling account does not need to assume a role. When both IAM and resource policies apply, AWS evaluates them together: within the same account, the union of permissions applies. For cross-account access, both the caller's IAM policy and the resource policy must allow the action.
Which AWS services support resource-based policies?: Common services include S3 (bucket policies), SQS (queue policies), SNS (topic policies), Lambda (function policies), KMS (key policies), Secrets Manager, ECR, API Gateway, and EventBridge. Each service has slightly different supported condition keys and actions. Not all services support resource policies — for services like EC2 or RDS, you must use IAM roles for cross-account access.

Related Learning Guides

AWS IAM Best Practices25 min read

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.