Choosing messaging: SQS, SNS, EventBridge (and Kafka or MQ)
Pick between SQS (pull queue), SNS (push fan-out) and EventBridge (event bus with content routing), or combine them — what each guarantees (ordering, duplicates, retention, retries), how they hand off to Lambda, the combinations that work (SNS→SQS fan-out, EventBridge→SQS buffer), the traps in each, and when Amazon MQ, MSK/Kafka or outside brokers fit instead.
markdownpatternv4R7G7-EFREstage: buildtrust: officialservice: sqsservice: snsservice: eventbridgeinterface: anySQS vs SNS vs EventBridgechoose messaging servicequeue vs topic vs event busfan-out patternevent-driven architecture AWSEventBridge vs SNSSQS FIFO vs SNS FIFOKafka MSK alternativeAmazon MQ RabbitMQdecision guide messagingbuffer Lambda with SQS
Choosing messaging: SQS, SNS, EventBridge
Use SQS when one consumer must work through a backlog at its own pace. Use SNS when many subscribers each need a copy right away. Use EventBridge when events should be routed by their content, or come from AWS services, SaaS apps or other accounts. They combine well, and the most common shapes use two of them.
What each gives you
| SQS | SNS | EventBridge | |
|---|---|---|---|
| Model | Queue; consumers pull | Topic; SNS pushes to subscribers | Event bus; rules route matching events to targets |
| Holds messages | Up to 14 days (default 4) | No storage; retries delivery | No storage on the bus; retries delivery |
| Retries | Consumer-driven: visibility timeout, then a DLQ after maxReceiveCount | SQS/Lambda subscribers: 100,015 attempts over 23 days; then discarded unless the subscription has a DLQ | 24 h / 185 attempts by default; then dropped unless the target has a DLQ |
| Filtering | None on the queue (consumers decide; Lambda trigger filters exist) | Subscription filter policies (attributes or body) | Rich patterns on any field (reference/eventbridge/event-patterns.md) |
| Ordering | FIFO queues, per message group | FIFO topics (+ SQS FIFO for strict order and deduplication) | No ordering |
| Duplicates | Standard: possible. FIFO: deduplicated within 5 minutes | Standard SQS subscribers get at-least-once, even from a FIFO topic | Rare duplicates documented |
| Max message | 1 MiB | Not collected | 1 MB on event buses since 2026-01-29 (most Regions) |
| Sources | Your code, SNS, EventBridge, S3, … | Your code, CloudWatch alarms, many AWS services | AWS service events, CloudTrail API calls, SaaS partners, other accounts and buses, your code |
The decision guide's wording on SNS "exactly-once" delivery conflicts with the SNS developer guide's at-least-once statement for standard subscribers. Design consumers to be idempotent with all three.
Shapes that work
| Shape | When | Read |
|---|---|---|
| Producer → SQS → Lambda | Buffer bursts, cap concurrency, retry per message | patterns/sqs-to-lambda.md |
| Producer → SNS → several SQS queues → consumers | Fan-out where every consumer has its own backlog and DLQ | patterns/sns-to-sqs-fanout.md |
| AWS events / CloudTrail → EventBridge rule → SQS or Lambda | React to changes in your account (instance state, IAM changes) | guides/eventbridge/route-events.md |
| Custom domain events → EventBridge bus → several targets | Content-based routing to many independent consumers; cross-account buses | same |
| DynamoDB table → Streams → Lambda | React to item changes in order per key | patterns/dynamodb-streams-to-lambda.md |
| S3 → notification → SQS, SNS or Lambda | Object-created workflows | patterns/s3-to-lambda.md |
Put an SQS queue in front of slow or rate-limited consumers even when SNS or EventBridge is the router. Their retries are bounded, and a queue gives you a backlog you can inspect and redrive.
Traps
- SNS and EventBridge discard after retries unless the subscription or target has a DLQ.
- Service producers and KMS: SNS, EventBridge and S3 can't write to queues encrypted with
aws/sqs. Use SSE-SQS or a customer managed key (reference/sqs/queue-settings-and-encryption.md). - Permissions live on the target:
- queue policies (
sqs:SendMessagefor the service principal); - topic policies (
sns:Publish); - Lambda resource policies (
lambda:InvokeFunction). - Global-service events (IAM, Route 53) reach EventBridge only in
us-east-1.
Other AWS options and outside brokers
AWS's application-integration decision guide also names Amazon MQ and Amazon MSK (Kafka). The hub doesn't cover either; read that guide before choosing them. Self-managed Kafka, RabbitMQ and other clouds' pub/sub services are named, not evaluated. Lambda can consume self-managed Kafka and MSK (OffsetLag metric, reference/cloudwatch/metrics-and-math.md).