When do I need an SQS queue policy?

You need a queue policy when AWS services (like SNS, S3, or EventBridge) need to send messages to your queue, or when principals in other AWS accounts need access. Without a policy, only the queue owner's account can interact with the queue.

What is the difference between an SQS queue policy and an IAM policy for SQS?

An SQS queue policy is a resource-based policy attached to the queue itself, specifying who can access it. An IAM policy is attached to a user, group, or role, specifying what that identity can do. Both are evaluated together to determine access.

AWS SQS Queue Policy Builder

IAM & SecurityAWS

Build SQS queue access policies with conditions for send and receive permissions.

Last verified: May 2026

SQS Queue Policy Configuration

Queue ARN

Statement 1

SID (optional)

Effect

Principal

Actions (comma-separated)

Condition Operator

Condition Key

Condition Value

Generated SQS Queue Policy

Output will appear here...

About This Tool

The SQS Queue Policy Builder provides a guided interface for creating access policies on Amazon SQS queues. SQS queue policies determine which AWS accounts, IAM principals, and services can send messages to or receive messages from your queues. This tool walks you through building policy statements with the correct actions, principals, and conditions, generating valid JSON you can apply via the console, CLI, or infrastructure-as-code tools.

Real-World Scenario

Your team is wiring up an event-driven architecture where S3 uploads trigger SNS fan-out to 5 SQS queues. The builder generates each queue policy with the correct sqs:SendMessage action, sns.amazonaws.com principal, and aws:SourceArn matching the SNS topic. Without the tool, one of the 5 queues was missing the SourceArn condition (typo), making it open to publishes from any SNS topic. The tool's template eliminated this entire class of bug across the project.

When to Use This Tool

•Build a queue policy that allows SNS topics to send messages to your SQS queue for fan-out architectures.
•Create cross-account access policies that let other AWS accounts send messages to your queue securely.
•Configure a policy restricting queue access to specific VPC endpoints for network-level isolation.
•Generate a policy that allows S3 event notifications to deliver object-created events to your SQS queue.

Pro Tips

TIP

When SNS fans out to SQS, the queue policy must allow sns.amazonaws.com as principal AND have an aws:SourceArn condition matching the topic. The tool template handles this correctly — but if you copy-paste from old AWS docs, you might get an example without the SourceArn, which works but allows ANY SNS topic in any account to publish to your queue.

TIP

For S3 → SQS event notifications, use the aws:SourceAccount condition (not just SourceArn) to prevent cross-account confused-deputy attacks. AWS documentation often omits this for brevity, but it's the recommended security posture per AWS Security Hub controls.

TIP

VPC endpoint conditions (aws:SourceVpce) on SQS queue policies are powerful for keeping queues internal-only. Combined with VPC endpoint policies, you can guarantee a queue is only accessible from inside specific VPCs — defense-in-depth even if IAM is misconfigured.

How It Works Under the Hood

The builder collects SQS-specific policy parameters (sqs:SendMessage, sqs:ReceiveMessage, etc., principal, queue ARN, optional conditions) and outputs a valid resource-based policy JSON. It includes pre-populated templates for common patterns: SNS-to-SQS fan-out (with SourceArn condition), S3 event notifications (with SourceArn + SourceAccount), and EventBridge target delivery.

Frequently Asked Questions

When do I need an SQS queue policy?: You need a queue policy when AWS services (like SNS, S3, or EventBridge) need to send messages to your queue, or when principals in other AWS accounts need access. Without a policy, only the queue owner's account can interact with the queue.
What is the difference between an SQS queue policy and an IAM policy for SQS?: An SQS queue policy is a resource-based policy attached to the queue itself, specifying who can access it. An IAM policy is attached to a user, group, or role, specifying what that identity can do. Both are evaluated together to determine access.

Related Learning Guides

AWS IAM Best Practices25 min read

Was this tool helpful?

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.