AWS SNS and SQS (Messaging Services)
AWS provides two core messaging services — SNS (Simple Notification Service) and SQS (Simple Queue Service). Both services help different parts of an application communicate asynchronously — meaning each component works at its own pace without waiting for the other. Together, they form the backbone of modern, loosely-coupled cloud architectures.
Why Messaging Services?
In a direct (synchronous) communication model, Component A sends a request to Component B and waits for a response. If Component B is slow or down, Component A also fails or gets stuck.
With messaging services, Component A sends a message to a queue or topic and continues working. Component B processes the message when it is ready. Both components operate independently — neither blocks the other.
Without Messaging (Synchronous):
[OrderService] → waits... → [EmailService]
(if email service is down, order fails!)
With SQS (Asynchronous):
[OrderService] → [SQS Queue] → [EmailService processes when ready]
(order succeeds even if email service is temporarily down)
AWS SQS — Simple Queue Service
SQS is a fully managed message queue service. Messages are placed in a queue by a producer and consumed (processed and removed) by a consumer. SQS acts as a reliable buffer between components.
How SQS Works
[Producer — sends messages]
|
[SQS Queue]
+-----------+
| Message 1 |
| Message 2 |
| Message 3 |
+-----------+
|
[Consumer — polls and processes messages]
|
[Message deleted after successful processing]
SQS Queue Types
| Feature | Standard Queue | FIFO Queue |
|---|---|---|
| Message Order | Best-effort (may vary) | Strict First-In-First-Out |
| Delivery | At-least-once (may deliver duplicates) | Exactly-once processing |
| Throughput | Unlimited | 300 msg/sec (3,000 with batching) |
| Use Case | Order processing, image jobs (order not critical) | Financial transactions, inventory updates (order critical) |
Key SQS Concepts
Visibility Timeout: When a consumer receives a message, SQS hides it from other consumers for a set period (visibility timeout, default 30 seconds). If the consumer successfully processes and deletes the message within this window, it is gone. If the consumer crashes, the message becomes visible again and another consumer can pick it up. This prevents duplicate processing while ensuring the message is not lost.
Message Retention Period: Messages that are not consumed stay in the queue for a configurable period — from 1 minute to 14 days (default 4 days). After this, they are automatically deleted.
Dead Letter Queue (DLQ): A special SQS queue that receives messages that have failed processing a defined number of times (maxReceiveCount). DLQs prevent bad messages from blocking the main queue indefinitely and allow manual inspection of failed messages.
[Main Queue]
|
Message failed 3 times (maxReceiveCount = 3)
|
[Dead Letter Queue] ← failed messages land here for review
Long Polling: By default, consumers poll SQS for messages every few seconds (short polling) — even if the queue is empty — which wastes API calls. Long polling instructs SQS to wait up to 20 seconds before responding if no messages are in the queue. This reduces empty responses and lowers costs.
AWS SNS — Simple Notification Service
SNS is a publish-subscribe messaging service. A publisher sends a message to a Topic. SNS then delivers that message to all subscribers of that topic simultaneously. This is called fan-out delivery.
How SNS Works
[Publisher sends ONE message to SNS Topic]
|
[SNS Topic: OrderPlaced]
/ | \
[Email: [SMS: [SQS Queue: [Lambda:
customer] admin] warehouse] analytics]
One message from the publisher triggers delivery to all subscribers at the same time. This eliminates the need to send separate messages to each system.
SNS Supported Subscriber Types
- SQS Queue: Delivers the message to a queue for async processing.
- Lambda Function: Invokes a Lambda function with the message payload.
- Email / Email-JSON: Sends an email notification to a subscribed address.
- SMS: Sends an SMS text message to a phone number.
- HTTP/HTTPS Endpoint: Makes a POST request to a webhook URL.
- Mobile Push: Sends push notifications to iOS, Android, or FireOS devices.
SNS Message Filtering
By default, all subscribers receive all messages from a topic. Message filtering allows each subscriber to receive only the messages it cares about, based on message attributes.
Example: An order system publishes all order events to one topic. A filter policy on the SQS warehouse subscriber ensures it only receives messages where orderType = "physical". The email subscriber only receives messages where orderStatus = "shipped".
SNS + SQS Fan-Out Architecture
Combining SNS and SQS is a common pattern for reliable, decoupled multi-consumer architectures:
[Application: New Order Created]
|
[SNS Topic: new-order]
/ \
[SQS: email-q] [SQS: inventory-q]
| |
[Lambda: send [EC2: update
email to inventory
customer] database]
Benefits of this pattern:
- Both systems process independently — one slow consumer does not affect the other.
- SQS queues provide buffering — if the Lambda function is throttled, messages wait in the queue.
- Easy to add more consumers in the future — just add another SQS subscription to the SNS topic.
SQS vs SNS — When to Use Which
| Feature | SQS | SNS |
|---|---|---|
| Pattern | Point-to-point queue | Publish-subscribe (one-to-many) |
| Message consumers | One consumer processes each message | All subscribers receive each message |
| Message persistence | Messages persist until consumed (up to 14 days) | Messages delivered immediately, not stored |
| Best for | Work queue — one job done once | Event notifications to multiple systems |
| Example | Process payment → one service handles it | Order placed → notify email, SMS, warehouse |
Real-World Example — Ride-Booking App
When a rider books a trip:
- The booking service publishes a BookingCreated event to an SNS Topic.
- SNS fans out to three SQS queues: driver-matching-q, notification-q, analytics-q.
- driver-matching-q: Consumed by a service that finds the nearest available driver.
- notification-q: Consumed by a Lambda that sends an SMS confirmation to the rider.
- analytics-q: Consumed by an analytics service that records trip data.
All three services work in parallel, completely independently. If the analytics service is down for 30 minutes, its messages wait safely in the SQS queue and are processed when the service recovers — with zero data loss.
Summary
- SQS is a message queue — producers send messages, one consumer processes each message. Supports Standard (best-effort) and FIFO (ordered, exactly-once) queues.
- SNS is a pub/sub system — one publisher sends to a topic, all subscribers receive the message simultaneously.
- Dead Letter Queues catch messages that fail processing repeatedly.
- The SNS + SQS fan-out pattern is widely used for decoupled, resilient architectures.
- Message filtering in SNS ensures each subscriber receives only relevant messages.