SNS vs SQS in AWS

How SNS and SQS actually work

SNS (Simple Notification Service) is a pub/sub (publish/subscribe) system. A publisher sends a message to a topic. Every subscriber to that topic immediately receives a copy of the message. If you have 5 subscribers, all 5 receive the same message at roughly the same time. SNS doesn’t store messages for later retrieval — it delivers them immediately and they’re gone. If a subscriber is down when a message is published, that subscriber misses it (unless you use SQS as a buffer).

SQS (Simple Queue Service) is a message queue. A producer sends a message to a queue. The message is stored in the queue until a consumer reads it, processes it, and deletes it. If no consumer is running, messages accumulate in the queue (for up to 14 days, configurable). Only one consumer reads and processes each message. SQS provides retry behavior, dead-letter queues, and visibility timeouts that ensure reliable exactly-once processing.

The fundamental difference: SNS is push-to-many, immediate delivery. SQS is store-for-one, processed at consumer’s pace.

SNS vs SQS comparison

When SNS alone is sufficient

Push notifications. SNS is the native service for sending push notifications to mobile devices (iOS, Android) via platform application endpoints. If your use case is “send a push notification to this user’s device,” SNS mobile push handles it directly.

Email and SMS alerts. Operations alerts — “your EC2 instance CPU is above 90%, here’s the notification” — go through SNS. CloudWatch Alarms publish to SNS topics, which deliver to email or SMS. You don’t need SQS in between for these notification-only flows.

Triggering multiple systems from one event. If a deployment succeeds and you want to notify Slack, update a ticket, and send an email — SNS with three subscribers (a Lambda for Slack, an HTTP endpoint for the ticket system, and an email subscription) handles this cleanly without a queue.

When immediate delivery is required. SNS delivers messages in milliseconds. If subscribers are healthy and reachable, they receive the message immediately. If you don’t need persistence or retry guarantees for a specific subscriber, SNS is simpler than adding SQS.

See SNS overview for topic configuration, subscription types, and filter policy syntax.

When SQS is necessary

Reliable async task processing. A user submits a form. Your application puts a message in an SQS queue: “process this report for user X.” A worker Lambda function reads from the queue and generates the report. If the Lambda function fails halfway through, the message becomes visible again and the next invocation retries it. The user’s request is never lost, even if the processing system has temporary issues.

Decoupling systems with different throughputs. A web API can accept 1,000 requests per second, but your downstream processing system can only handle 100 requests per second. SQS acts as a buffer — requests pile up in the queue and the downstream system processes them at its own pace. Without SQS, you’d need to throttle the API or scale the downstream system to match peak input rates.

Dead-letter queues for failure handling. SQS dead-letter queues capture messages that fail repeatedly — after 3 or 5 retries, the message goes to a DLQ where you can inspect it, debug the failure, and reprocess it manually. SNS has no equivalent — failed deliveries are retried with backoff and then dropped.

FIFO (strict ordering) requirements. SQS FIFO queues guarantee exactly-once processing in strict message order. If your workflow requires that messages are processed in the exact order they were sent — sequential state transitions, ordered audit log entries — SQS FIFO is the answer. Standard SQS queues are best-effort ordered.

Visibility timeout for idempotency. When a consumer reads an SQS message, it becomes invisible to other consumers for the visibility timeout period (configurable, default 30 seconds). The consumer must delete the message after successful processing. This mechanism ensures that a message isn’t processed twice if a consumer crashes mid-processing — as long as your consumer is idempotent (safe to retry), SQS provides at-least-once delivery with retry.

The fan-out pattern: SNS + SQS together

The most common production pattern combines both services: SNS publishes to multiple SQS queues (and optionally direct Lambda functions). This is the fan-out pattern.

Real scenario: an order placed event

A customer places an order. The order service publishes one message to an SNS topic: OrderPlaced.

The OrderPlaced topic has three subscribers:

1. SQS queue → fulfillment service — picks the order, checks inventory, initiates shipping. Needs reliable delivery with retries because fulfillment is critical.
2. SQS queue → email service — sends the order confirmation email. Decoupled from fulfillment so email failures don’t affect fulfillment.
3. Lambda function → analytics service — records the order event in real time for dashboards. Direct Lambda subscriber because analytics doesn’t need the retry/persistence guarantees of SQS.

This architecture has several advantages:

• Publishing is simple — the order service publishes one message, not three
• Services are decoupled — fulfillment and email don’t know about each other
• SQS provides resilience — if the email service is down, messages queue up and are processed when it recovers
• SNS filtering — if you add a fourth subscriber that only cares about premium orders, you add a subscription filter policy ("orderType": ["premium"]) without changing the publisher

Without SQS in the subscriber chain, SNS delivery failures (if the fulfillment HTTP endpoint is down) mean the event is lost. SQS as an intermediate buffer means no message is lost even if downstream systems are temporarily unavailable.

FIFO variants of both

Both SNS and SQS have FIFO versions. SQS FIFO queues guarantee strict message ordering within a message group and exactly-once processing. SNS FIFO topics work exclusively with SQS FIFO subscribers and maintain ordered delivery.

FIFO comes with constraints: SQS FIFO is limited to 3,000 messages per second per API action (higher with batching). Standard queues handle virtually unlimited throughput.

Use FIFO when: message ordering is a hard requirement and you can accept the throughput constraints. Financial transactions, state machine transitions, and sequential audit logs are common FIFO use cases.

Don’t use FIFO when: your throughput requirements exceed FIFO limits, or ordering doesn’t matter. Most event-driven workloads are tolerant of out-of-order delivery.