Start with push, pull, and routing intent
Amazon SQS
A durable queue that buffers work. Consumers pull messages when ready, which protects downstream services from bursts and lets processing scale independently.
Amazon SNS
A publisher sends to a topic and SNS pushes messages to multiple subscribed endpoints. Choose it for fan-out, application notifications and application-to-person delivery.
Amazon EventBridge
A serverless event router. Event buses match structured events against rules and deliver them to zero or more targets; Pipes support point-to-point integration with filtering and enrichment.
Services are often combined, not substituted
Order processing with traffic spikes
The checkout service sends each order to SQS. Worker instances or Lambda functions consume at a controlled rate. The queue absorbs a burst without requiring the fulfillment service to match the producer’s instantaneous throughput.
Every department needs its own order copy
Publish the order event to SNS and subscribe separate SQS queues for fulfillment, analytics and fraud review. Each team receives a durable copy and can process at its own rate.
Central routing for many event types
Send application and AWS service events to EventBridge. Rules inspect fields such as event source, detail type or business attributes and route only matching events to appropriate targets.
Reliability depends on consumer behavior too
For SQS, the visibility timeout temporarily hides a received message. The consumer must delete it after successful processing; otherwise it becomes visible again. Configure a dead-letter queue and redrive policy for messages that repeatedly fail.
Standard queues provide at-least-once delivery, so consumers should be idempotent. FIFO queues add ordering within message groups and deduplication capabilities, but architecture choices still need correct message-group, retry and failure handling.
DLQ is not the finish line: monitor dead-letter depth, retain enough diagnostic context, fix the cause, and use a controlled redrive process. Silently accumulating failed business events is data loss in slow motion.
Common SAA-C03 mistakes
- Choosing SNS when a slow consumer needs a durable backlog and pull-based pacing.
- Choosing one SQS queue when every subscriber must receive its own copy; competing consumers share work from one queue.
- Using EventBridge only because a scenario says “event” even though the real need is a durable work queue.
- Assuming a Standard SQS message is delivered exactly once.
- Setting visibility timeout shorter than normal processing time without extension logic.
- Ignoring DLQ monitoring and replay procedures.
- Building custom polling or fan-out code when a managed service already provides the pattern.
Fast SAA-C03 decision rule
Buffer one unit of work for processing: SQS. Push one publication to many subscribers: SNS. Match structured events from many sources to targets: EventBridge. Need durable fan-out: SNS plus a separate SQS queue for each consumer.
Official AWS references
Frequently asked questions
What is the simplest difference between SQS and SNS?
SQS stores messages in a queue until consumers poll and process them. SNS publishes a message to a topic and pushes copies to subscribed endpoints, making it suitable for fan-out and notifications.
When should I choose EventBridge instead of SNS?
Choose EventBridge when you need content-based event routing across AWS services, custom applications or third-party sources, with rules that can send matching events to different targets and optionally transform them.
Can SNS and SQS be used together?
Yes. Subscribe separate SQS queues to an SNS topic when every consumer needs its own durable copy and should process independently. This is the common fan-out-with-buffering pattern.
Why should an SQS consumer be idempotent?
Standard SQS queues use at-least-once delivery, so a message can be delivered more than once. An idempotent consumer safely handles retries or duplicates without repeating an unwanted business effect.