SQS vs SNS: Which AWS Messaging Service Should You Use?

Definition

Amazon SQS and Amazon SNS are both fully managed messaging services on AWS, but they solve different problems:

• Amazon SQS (Simple Queue Service) is a point-to-point queue. One producer (or many) writes messages; one logical consumer (or a pool of workers sharing a consumer group) pulls and processes them. Messages are durable — up to 14 days — so consumers can process at their own rate.
• Amazon SNS (Simple Notification Service) is a pub/sub topic. One publisher sends a message; every subscriber receives a copy, pushed directly. Subscribers include SQS queues, Lambda functions, HTTPS endpoints, email, SMS, and mobile push.

The classic way to combine their strengths is the SNS → SQS fan-out pattern: one SNS topic fans a single event out to multiple SQS queues, each dedicated to a specific downstream consumer.

Side-by-Side Comparison

| Aspect | Amazon SQS | Amazon SNS | | --- | --- | --- | | Messaging pattern | Queue (point-to-point) | Topic (pub/sub) | | Delivery model | Pull — consumers long-poll | Push — SNS calls subscriber | | Fan-out | No (one logical consumer group) | Yes (many subscribers per topic) | | Persistence | 1 minute – 14 days | None (fire-and-forget) | | Consumers must be online | No — messages wait | Yes — offline subscribers miss messages (unless fanned out to SQS) | | Max throughput | Nearly unlimited (Standard); 300/s – 30,000/s (FIFO) | Nearly unlimited (Standard); 300/s (FIFO) | | Ordering | Best-effort (Standard) / strict (FIFO) | None (Standard) / strict (FIFO) | | Delivery guarantee | At-least-once (Standard) / exactly-once (FIFO) | At-least-once (Standard) / exactly-once (FIFO) | | Subscriber types | SDK consumers, Lambda event-source mapping | SQS, Lambda, HTTPS, email, SMS, mobile push, Firehose | | Filtering | Consumer-side only | Filter policies on attributes or body | | Visibility timeout / retry | Yes — per-message visibility window | No — retries driven by subscription delivery policy | | Dead-letter queue | Yes, per-queue | Yes, per-subscription | | Price per message | Lower | Slightly higher for non-SQS/Lambda deliveries | | Free Tier | 1M requests / month | 1M publishes / month |

When to Choose SQS

• You have one logical consumer (or a worker pool) that processes each job once.
• You need to buffer work across bursts of incoming traffic.
• Consumers may be offline or slow — the queue durability gives you up to 14 days of cushion.
• You need strict ordering or exactly-once delivery (use SQS FIFO).
• You want a simple task queue for background processing: image resizing, email sending, PDF generation, batch jobs.

When to Choose SNS

• You need to fan a single event out to many consumers, each running independently.
• You want push delivery — consumers don't poll.
• You're notifying humans via email, SMS, or mobile push.
• You want content-based filtering on subscription so each consumer only sees relevant messages.
• You have lightweight webhook subscribers on HTTPS endpoints.

The SNS → SQS Fan-Out Pattern

The most widely-used AWS decoupling pattern combines both services:

            ┌──── SQS (audit service queue) ──── Audit service
            │
Publisher ──▶ SNS ──┤──── SQS (inventory queue)     ──── Inventory service
            │
            └──── SQS (notifications queue)  ──── Notifications service

Why it works so well:

• One publish, many consumers — the producer doesn't know or care about downstream services.
• Each consumer owns its own queue — they can process at their own pace, go offline for maintenance, and replay messages independently.
• Filter policies ensure a consumer's queue only receives relevant events.
• Independent scaling — each queue scales its worker pool based on its own depth and latency.
• Durability — each SQS queue persists its messages up to 14 days.

This pattern turns a tightly-coupled service call graph into a loosely-coupled event-driven system with very little code.

Common Misconceptions

• "SQS is one-to-one; SNS is one-to-many" — correct at the service level, but remember an SQS queue can have many workers that share the same logical consumer. The point is that a message is consumed by exactly one worker from that queue.
• "SNS stores messages" — no. SNS is push-only; if a subscriber is offline when a message is published (and retries exhaust), the message is lost unless you fanned out to SQS.
• "SQS has fan-out" — no. You can't duplicate a message to multiple SQS queues without a pub/sub layer on top (SNS or EventBridge).

Where EventBridge Fits In

Amazon EventBridge is a newer, more flexible event bus that overlaps with SNS but adds:

• Content-based routing using JSON pattern matching on the whole event body (SNS filters attributes or specific body fields).
• 130+ SaaS integrations (Datadog, Shopify, Zendesk, PagerDuty, etc.).
• Schema registry and event validation.
• Archive and replay for event sourcing patterns.

EventBridge has slightly higher latency and higher per-event cost than SNS. Rule of thumb: use SNS for simple, high-throughput AWS-internal fan-out; use EventBridge when you need rich content routing or SaaS event integration.

Pricing Comparison

Both are pay-as-you-go with a Free Tier of 1 million requests/month:

• SQS: per million requests. Batch APIs (up to 10 messages per request) reduce cost 10×.
• SNS: per million publishes + per million deliveries. Delivery cost varies by destination (SQS/Lambda cheapest; HTTPS/email/SMS more expensive).

For the same logical workload, SNS → SQS fan-out costs roughly the sum of one SNS publish per message + one delivery per subscriber + one SQS request per consumer receive + one delete. Batching and filter policies reduce cost substantially.

Exam Relevance

This comparison shows up on every associate-level AWS exam:

• Cloud Practitioner (CLF-C02) — high-level: SNS = pub/sub notifications, SQS = queue for decoupling.
• Solutions Architect Associate (SAA-C03) — very common scenario questions: "A single event must reach three different services, each with a DLQ, allowing each to process at its own pace" → SNS + SQS fan-out. "Decouple a web tier from a worker tier that processes jobs at its own rate" → SQS alone.
• Developer Associate (DVA-C02) — visibility timeout, FIFO queues, SNS filter policies, idempotent consumers.

Classic exam trap: if the scenario asks for fan-out with persistence for each consumer, the answer is SNS + multiple SQS queues, not just SNS and not just SQS.

Frequently Asked Questions

Q: Can I replace SNS + SQS with EventBridge?

A: Often yes — EventBridge provides pub/sub with richer routing. EventBridge rules can have multiple targets (Lambda, SQS, Step Functions, SNS, Firehose, and more), supports content-based filtering on the full event body, and integrates with many SaaS partners. Trade-offs: EventBridge latency is slightly higher, and per-event cost is higher for high-throughput workloads. For simple AWS-internal fan-out, SNS is usually cheaper and faster; for event-driven routing across SaaS and AWS, EventBridge wins.

Q: How do I guarantee every consumer sees a message, even if it's offline temporarily?

A: Use SNS → SQS fan-out. SNS publishes to each subscribed SQS queue; SQS persists messages up to 14 days. When the consumer comes back online, it drains its queue. Without SQS, an offline SNS subscriber misses messages after the delivery retry policy gives up.

Q: Which is better for Lambda: SQS or SNS?

A: Depends on the pattern. SNS → Lambda is simpler for one-to-one or fan-out notifications — the Lambda is invoked asynchronously, once per message. SQS → Lambda (via an event source mapping) gives you better back-pressure, visibility-timeout retry semantics, a DLQ, and natural batching (up to 10,000 messages per invocation). For high-throughput workloads with spiky traffic, SQS → Lambda is usually the safer choice because SQS buffers and paces the Lambda concurrency.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official SQS and SNS documentation before making production decisions.