Amazon SQS vs Amazon SNS
Compare durable pull-based queues with push-based pub/sub fanout for buffering, competing consumers, delivery, and retries.
Open editable diagramArchitecture diagram
Edit this exact diagram
Open on the canvasAmazon SQS vs SNS architecture diagram comparing a durable queue with competing workers to a push topic with multiple subscribers. The image links to a fully editable BuildPlane starter.
Overview
Amazon SQS is a durable queue whose consumers pull messages from one backlog. Amazon SNS is a publish/subscribe topic that pushes each publication to matching subscribers. Use SQS to buffer work, absorb backpressure, and spread jobs across competing consumers. Use SNS to fan one event out to multiple independent consumers or delivery channels.
Components
- Shared decision context: Publishes work and business notifications without waiting for downstream processing.
- Amazon SQS Queue: Stores messages until a consumer successfully processes and deletes them. A worker pool pulls from one backlog so each message is processed by one consumer path.
- Amazon SNS Topic: Pushes each publication to subscribed queues, functions, HTTP endpoints, email, or mobile channels. Independent consumers each receive their own copy of the notification.
Comparison Flow
- Order Service can enter the Amazon SQS Queue path and continue to Competing Workers.
- Order Service can instead enter the Amazon SNS Topic path and continue to Multiple Subscribers.
- Choose the path whose operating model and constraints match the workload, then delete the unused branch in the editable diagram.
Customize First
- Choose Standard or FIFO ordering from the business requirement, not by habit.
- Add dead-letter queues and redrive policies per independent consumer.
- Combine SNS and SQS when fanout also needs buffering and replayable backlogs.
Side-by-side decision
Amazon SQS vs Amazon SNS
Use SQS for a durable backlog processed by competing consumers. Use SNS for push fanout to multiple subscribers. Combine SNS with one SQS queue per subscriber when you need both.
| Decision factor | Amazon SQS | Amazon SNS |
|---|---|---|
| Model | Point-to-point queue | Publish/subscribe topic |
| Delivery | Consumers poll or Lambda polls on their behalf | SNS pushes to subscribed endpoints |
| Copies | One message handled by one consumer path | Each subscriber receives a copy |
| Buffer | Messages remain until processed or expired | Direct delivery; durability depends on subscriber type and features |
| Backpressure | Queue depth absorbs demand | Subscribers receive pushes at publish pace |
| Typical use | Jobs, commands, worker pools | Fanout, alerts, mobile, email, webhooks |
Related AWS guides
Understand the decisions behind this diagram
Use these practical explanations to compare services, failure boundaries, and operating tradeoffs before adapting the architecture.
Design rationale
Decisions that shape this architecture
A queue owns consumer pace
SQS lets workers process at their own rate while queue depth makes backlog visible. Visibility timeouts and redrive policies turn temporary failure into retryable work instead of publisher failure.
A topic owns fanout
SNS makes the publisher independent from the number and type of subscribers. Subscription filters can reduce copies, but each matching subscriber still owns its own success and failure semantics.
Durable fanout uses both services
Subscribe one SQS queue per service to SNS. The topic creates copies and each queue buffers them independently. A slow analytics consumer no longer delays the order worker, and each team controls its own concurrency and dead-letter policy.
Before production
Operational checks
Make consumers idempotent for at-least-once delivery.
Set visibility timeout above normal processing time and redrive poison messages.
Monitor queue age, depth, subscriber delivery failures, and dead-letter queues.
Use FIFO only when ordering requirements justify throughput and design constraints.
Scope and tradeoffs
What this diagram does not solve
SNS is not a retained event log by default
Direct subscribers should be available to receive deliveries. Use SQS subscriptions, archive and replay features where applicable, or a streaming service when durable replay is a core requirement.
SQS does not broadcast one message
Multiple consumers on one queue compete for messages. Give each independent consumer its own queue, usually subscribed through SNS or EventBridge, when every consumer needs a copy.
Common questions
Frequently asked questions
Can SNS send messages to SQS?
Yes. An SNS topic can have multiple SQS queue subscriptions. This is the standard durable fanout pattern because each subscriber receives a separate buffered copy.
Does SQS push messages?
SQS is pull-based. Applications poll it, while Lambda event source mappings perform that polling and batching on the function behalf, which can make the integration appear push-based.
Which service supports retries?
Both have delivery and retry behavior, but SQS makes the backlog, visibility timeout, receive count, and dead-letter redrive central to the consumer model. SNS retry behavior varies by endpoint type.
Keep exploring
Related AWS architectures
Amazon SNS vs Amazon EventBridge
Choose SNS when a producer needs straightforward, high-throughput fanout to queues, functions, HTTP endpoints, mobile push, SMS, or email. Choose EventBridge when events need richer content matching, routing across accounts and buses, SaaS sources, schema discovery, API destinations, or controlled replay. Use both only when their responsibilities are explicit, not because two buses feel safer than one.
Explore the architecture
Amazon SQS vs Amazon Kinesis Data Streams
Choose SQS for jobs, commands, and asynchronous work where one consumer path should complete each message. Choose Kinesis for telemetry, clickstreams, change records, and event histories that require per-key ordering, multiple independent processors, or replay. The choice is queue semantics versus stream semantics, not simply low throughput versus high throughput.
Explore the architecture
Event-Driven Order Processing Architecture on AWS
This design accepts an order through an authenticated API, publishes a durable domain event, and uses a saga to coordinate payment, inventory, fulfillment, and notification. It separates request latency from business processing while preserving explicit recovery paths.
Explore the architectureFrom reference to working draft
Adapt this architecture with your AWS AI Agent
Start from the exact diagram in this guide. Change requirements, challenge a decision, or ask what fails first, while keeping the architecture editable.