When to reach for SQS vs SNS vs EventBridge

"Should this be a queue or a topic?" gets asked in every design review I sit in, and the answer is almost always "it depends on what breaks when the consumer is down." SQS, SNS, and EventBridge overlap enough to confuse, but they solve genuinely different problems. I've reached for the wrong one and paid for it in dropped messages and tangled coupling, here's how I pick now.

The one-line mental model

• SQS, a buffer. One producer drops work, one consumer (or a fleet) pulls it when ready. Decouples in time.
• SNS, a megaphone. One message, fanned out to many subscribers at once. Decouples in number of consumers.
• EventBridge, a router. Events flow in, get filtered and transformed by rules, and land at many targets. Decouples by content and source.

SQS: when you need to not lose work

SQS is the right call when a message represents work that must be processed exactly once-ish and survives a consumer outage. The consumer polls, processes, and deletes; if it crashes mid-process, the visibility timeout expires and the message reappears. Standard queues are at-least-once and best-effort ordered; FIFO queues give strict ordering and exactly-once processing at lower throughput.

aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123456789012/orders \
  --message-body '{"orderId":"A-1029","amount":4999}' \
  --message-group-id orders   # required for FIFO queues

Always pair a queue with a dead-letter queue and a sane maxReceiveCount so poison messages don't loop forever.

SNS: one event, many listeners, right now

SNS pushes a message to every subscriber the instant it arrives, Lambda, SQS, HTTP, email, SMS. There's no retention beyond delivery retries; if a subscriber is down and has no retry success, the message is gone. That's why the durable pattern is SNS fan-out to SQS: the topic broadcasts, and each consumer gets its own queue that buffers until it recovers.

SNS → SQS fan-out is the workhorse pattern. SNS gives you the broadcast; the per-subscriber SQS queue gives you the durability and independent processing speed SNS alone can't.

EventBridge: routing by content, not just topic

EventBridge is what you want when routing depends on the contents of the event, when you're consuming events from AWS services or SaaS partners, or when you need schema registry and archive/replay. Rules filter on a JSON pattern and can transform the payload before it hits a target.

{
  "source": ["com.myapp.orders"],
  "detail-type": ["OrderPlaced"],
  "detail": {
    "amount": [{ "numeric": [">", 1000] }],
    "region": ["us-east-1", "us-west-2"]
  }
}

That rule fires only for high-value orders in two regions, no consumer-side filtering needed. The trade-off is latency and throughput: EventBridge adds more per-event overhead than SNS and has lower raw throughput, so it's not where I'd put a million-events-per-second firehose.

How they compare where it matters

How I actually choose

1. One consumer that must not drop work → SQS.
2. Many consumers, broadcast, low latency, you control the producers → SNS (fan-out to SQS for durability).
3. Routing depends on event content, or events come from AWS/SaaS sources → EventBridge.

And it's fine to combine them, EventBridge routing into an SNS topic that fans out to per-team SQS queues is a perfectly normal architecture.

Takeaways

• SQS decouples in time, SNS decouples across many consumers, EventBridge routes by content and source.
• SNS has no retention, fan out to SQS when subscribers must survive an outage.
• Reach for EventBridge when routing logic lives in the event payload or events originate from AWS/SaaS.
• These compose: it's common to chain EventBridge → SNS → SQS in one design.