Amazon SQS and SNS

Managed messaging — SQS for decoupled queue-based communication and SNS for pub/sub fan-out to multiple subscribers.

Overview

Amazon Simple Queue Service (SQS) is a fully managed message queue for decoupling producers and consumers, while Amazon Simple Notification Service (SNS) is a managed pub/sub service that fans out messages to multiple subscribers simultaneously.

Feature	SQS	SNS
Pattern	Queue (point-to-point)	Pub/Sub (one-to-many)
Consumer model	Consumers poll the queue	Subscribers receive push notifications
Delivery	At-least-once (Standard) / Exactly-once (FIFO)	At-least-once
Persistence	Messages stored until consumed or expired	No persistence — immediate delivery or drop
Throughput	Nearly unlimited (Standard) / 3,000 msg/s with batching (FIFO)	Nearly unlimited publishes
Ordering	Best-effort (Standard) / Strict FIFO	FIFO via FIFO SNS topic → FIFO SQS only

Core Concepts

Concept	Description
Standard Queue	Nearly unlimited throughput, best-effort ordering, at-least-once delivery
FIFO Queue	Strict message ordering and exactly-once processing; up to 3,000 msg/s with batching
Dead-Letter Queue (DLQ)	Destination for messages that fail processing after a configured number of attempts
Visibility Timeout	Period during which a received message is hidden from other consumers (default 30 s)
Long Polling	Reduces empty responses by waiting up to 20 s for a message to arrive
Message Group ID	FIFO concept — messages with the same group ID are processed in order
Deduplication ID	FIFO concept — prevents duplicate messages within a 5-minute deduplication window
SNS Topic	A logical channel to which publishers send messages
SNS Subscription	An endpoint (SQS, Lambda, HTTP, email, SMS) that receives copies of topic messages
Filter Policy	JSON policy on a subscription that filters which messages are delivered
Fan-Out	Pattern where one SNS topic pushes to multiple SQS queues for parallel processing

How SQS Works

Producer → SQS Queue → Consumer (poll) → Process → Delete Message
                ↓ (failure)
         Dead-Letter Queue

Retention: 1 minute to 14 days (default 4 days)
Max message size: 256 KB (use Extended Client Library + S3 for larger payloads)
Delay queue: Postpone delivery of new messages by 0–15 minutes
In-flight messages: up to 120,000 (Standard) / 20,000 (FIFO)

Publisher → SNS Topic
              ├── SQS Queue A (filter: order events)
              ├── SQS Queue B (filter: payment events)
              ├── Lambda Function
              ├── HTTP/S Endpoint
              └── Email / SMS

Message filtering: Apply JSON filter policy per subscription to reduce downstream noise
Raw message delivery: Skip SNS JSON wrapping for SQS/HTTP subscribers
Message attributes: Key-value metadata attached to each published message
FIFO topics: Pair with FIFO SQS queues for ordered, deduplicated fan-out

Fan-Out Pattern (SNS + SQS)

Order Service
    → SNS Topic (OrderPlaced)
        ├── SQS Queue → Inventory Service
        ├── SQS Queue → Billing Service
        └── SQS Queue → Analytics Pipeline

Each SQS queue receives an independent copy of the message and processes it at its own pace — failure in one consumer does not affect others.

Criteria	Choose SQS	Choose SNS
One consumer per message	Yes	No — use SNS + SQS fan-out
Multiple consumers	One queue per consumer (no fan-out)	Yes — single publish, multiple receive
Need message persistence	Yes — up to 14 days	No — deliver or lose
Pull-based processing	Yes — consumer polls at own pace	No — push-based
Need ordering guarantees	FIFO queue	FIFO topic → FIFO queue
Event notification (email/SMS)	Not directly	Yes — built-in email, SMS, HTTP

Common Use Cases

Application decoupling — SQS queue between microservices to absorb load spikes and prevent cascading failures.
Fan-out processing — SNS topic publishes an event; multiple SQS queues process it independently (e.g., order → billing + inventory + analytics).
Batch job buffering — Producers write to SQS; a fleet of workers polls and processes at a controlled rate.
S3 event notifications — S3 publishes object-created events to SNS topic, fanning out to Lambda, SQS, and email subscribers.
Cross-account messaging — SNS topic in one account fans out to SQS queues in other accounts via resource policies.

SAA/SAP Exam Tips

SAA Tip: "Decouple components" + "handle traffic spikes" → SQS Standard Queue. "Decouple" + "strict ordering" → SQS FIFO Queue.

SAA Tip: "Fan-out to multiple destinations from a single event" → SNS + SQS. This is the classic fan-out pattern tested heavily on the exam.

Exam Trap: SQS messages are not pushed — consumers must poll. If the question says "push-based" delivery, the answer is SNS (or EventBridge), not SQS.

SAP Tip: FIFO SQS throughput is 300 msg/s without batching, 3,000 msg/s with batching. If a scenario requires higher throughput with ordering, consider Kinesis Data Streams instead.

Cross-Cloud Equivalents

Provider	Service / Solution	Notes
AWS	Amazon SQS / Amazon SNS	Baseline
Azure	Azure Queue Storage (queue) / Azure Service Bus (advanced) / Azure Event Grid (pub/sub)	Service Bus supports FIFO + sessions
GCP	Google Cloud Pub/Sub	Unified queue + pub/sub in one service
On-Premises	RabbitMQ, Apache Kafka, ActiveMQ	Self-managed message brokers

Pricing Model

Dimension	Unit	Notes
SQS requests	Per million requests	First 1 M requests/month free; Standard cheaper than FIFO
SQS data transfer	Per GB out	Intra-region SQS → EC2 is free
SNS publishes	Per million publishes	First 1 M publishes/month free
SNS deliveries	Per delivery type	SQS/Lambda free; HTTP tiered; SMS per-message charge

Amazon EventBridge — event bus with content-based filtering and schema registry
Amazon Kinesis and Flink — real-time streaming for high-volume ordered data
AWS Step Functions — orchestration alternative for sequential workflows
AWS Lambda — serverless consumer for SQS queues and SNS subscriptions

Amazon SQS and SNS

On this page