Service comparisons / Amazon SQS vs Amazon SNS vs Amazon EventBridge
SQS vs SNS vs EventBridge
Amazon SQS queues work for one consumer to pull, SNS pushes copies to many subscribers, and EventBridge routes events by their content. When to use each, ordering, retention and the exam traps.
Last checked against AWS documentation · How we write our content
| Question | Amazon SQS | Amazon SNS | Amazon EventBridge |
|---|---|---|---|
| Use it when | One consumer group should process each message at its own pace | Many subscribers should each get a copy right away (fan-out) | Events should be routed to different targets based on what they contain |
| How it delivers | Consumers poll (pull); messages wait in the queue | Pushes to SQS, Lambda, HTTPS, email, SMS and mobile | Rules match event patterns and push to 20+ AWS targets |
| Ordering | Best-effort in standard queues; strict per message group in FIFO queues | None in standard topics; FIFO topics keep order for FIFO subscribers | No ordering guarantee |
| Keeps messages | 4 days by default, configurable from 1 minute to 14 days | No storage; retries delivery, then a dead-letter queue | No storage by default; archive and replay events if you turn it on |
| Watch out for | A consumer must delete each message, or it reappears after the visibility timeout | A subscriber that's down misses messages unless an SQS queue buffers them | Best for routing, not high-throughput streams of ordered data |
All three decouple the part of a system that produces work from the part that does it, so exam questions often offer them side by side. The difference is who receives each message and how.
How to choose
- One worker pool, uneven load: SQS. The queue absorbs spikes, and workers (EC2 in an Auto Scaling group, or Lambda) take messages as fast as they can. Scale the workers on queue depth.
- Same message to several systems at once: SNS. Publish once, and every subscriber gets a copy.
- Different targets depending on the event’s content, or events from AWS services and SaaS apps: EventBridge. A rule such as “order events where
amountis over 1,000” sends only those to one target. - Run something on a schedule: EventBridge Scheduler.
Exam traps
- “Exactly once” and “in order” point to an SQS FIFO queue, not a standard queue.
- “Must not lose messages if a subscriber is down” means putting an SQS queue behind SNS, because SNS doesn’t store messages.
- “Filter which messages a subscriber receives” can be SNS subscription filter policies (on message attributes or body) or an EventBridge rule (on any field of the event). EventBridge is the answer when routing depends on many fields or targets.
- “React to a change in an AWS service” (an EC2 state change, a CodePipeline failure) is an EventBridge rule, because AWS services already send those events to the default bus.
Using them together
The classic fan-out pattern is SNS to several SQS queues. Each consuming service gets its own queue, works at its own pace, and can retry without affecting the others. EventBridge can target SQS the same way when routing rules are needed.