Amazon SNS and SQS: Decoupling Applications
Learn how Amazon SQS (message queues) and Amazon SNS (pub/sub) help you build loosely coupled, resilient architectures.
Learning outcomes
By the end of this lesson, you will be able to:
- Explain why decoupling matters for cloud architecture.
- Describe Amazon SQS and its pull-based messaging model.
- Describe Amazon SNS and its push-based pub/sub model.
- Compare SQS, SNS, and EventBridge and know when to use each.
- Explain the SNS fan-out pattern.
Why decoupling matters
In a tightly coupled architecture, components call each other directly. If one component fails or slows down, the entire system is affected.
In a loosely coupled (decoupled) architecture, components communicate through an intermediary — a queue or a topic. If one component fails, the others keep working.
Key benefits of decoupling:
- Fault isolation — one component failing does not take down the others
- Independent scaling — each component scales based on its own demand
- Simpler deployments — update one component without touching the others
Amazon SQS: the message queue
Amazon Simple Queue Service (SQS) is a fully managed message queue. Producers send messages to the queue; consumers poll the queue to receive and process messages.
Key characteristics:
- Pull-based — consumers poll the queue for messages
- 1-to-1 delivery — each message is processed by one consumer
- Automatic retention — messages stay in the queue until processed (up to 14 days)
- Scales automatically — no provisioning needed
SQS queue types
| Feature | Standard Queue | FIFO Queue |
|---|---|---|
| Ordering | Best-effort (not guaranteed) | Strict first-in, first-out |
| Duplicates | Possible (at-least-once delivery) | Exactly-once processing |
| Throughput | Nearly unlimited | 300 messages/sec (batching increases this) |
| Use case | High throughput where order doesn't matter | Order-sensitive workflows (e.g., financial transactions) |
Tip
Exam tip: If the question mentions "order matters" or "exactly-once," think FIFO queue. If it mentions "high throughput" or "best effort," think Standard queue.
Amazon SNS: pub/sub messaging
Amazon Simple Notification Service (SNS) is a fully managed pub/sub (publish/subscribe) service. Publishers send messages to a topic, and all subscribers to that topic receive the message.
Key characteristics:
- Push-based — SNS pushes messages to subscribers immediately
- 1-to-many delivery — one message reaches all subscribers
- Multiple subscriber types — email, SMS, Lambda, SQS, HTTP/HTTPS
- No message retention — if a subscriber is unavailable, the message may be lost (unless backed by SQS)
3) EventBridge - The Event Bus
Quick Reference
Event-Driven Integration Services
Amazon EventBridge is a serverless event bus that ingests events from your own applications, SaaS applications, and AWS services, and routes them to targets based on rules you define.
Key features:
- Event routing — Route events to multiple targets based on rules
- Event filtering — Only process events that match specific patterns
- Event transformation — Transform event payloads before delivery
- Scheduled events — Trigger events on a schedule (like cron)
Choosing Event-Driven Services
Choosing Event-Driven Services
Use SQS when...
- Point-to-point messaging needed
- One consumer processes each message
- Decouple application components
Use SNS when...
- Fan-out to multiple consumers
- Push notifications or alerts
- Pub/sub broadcast pattern
Use EventBridge when...
- Event routing and filtering needed
- Cross-service event orchestration
- Scheduled or pattern-based triggers
Key pattern: SNS fan-out
The fan-out pattern combines SNS and SQS. You publish one message to an SNS topic, and SNS delivers a copy to multiple SQS queues. Each downstream system processes messages from its own queue.
Why fan-out?
- Each consumer gets its own copy — no competition for messages
- Each queue buffers messages independently — if Analytics is slow, Inventory is unaffected
- Adding a new consumer is as simple as subscribing a new SQS queue
Note
The SNS + SQS fan-out pattern is one of the most commonly tested integration patterns on the AWS Cloud Practitioner exam.
Comparison: SQS vs SNS vs EventBridge
| Feature | Amazon SQS | Amazon SNS | Amazon EventBridge |
|---|---|---|---|
| Model | Message queue (pull) | Pub/sub (push) | Event bus (push with rules) |
| Delivery | 1-to-1 (one consumer per message) | 1-to-many (all subscribers) | 1-to-many (filtered routing) |
| Consumer action | Consumer polls the queue | SNS pushes to subscribers | Pushes to targets based on rules |
| Message retention | Up to 14 days | No retention (deliver or lose) | 24-hour replay window |
| Best for | Work queues, task buffers | Notifications, fan-out | Event routing, filtering, scheduling |
Micro-activity: SQS or SNS?
Classify each scenario
Decide whether each scenario is a better fit for SQS or SNS.
Buffer tasks so a worker processes them one at a time
Send one order event to inventory, shipping, and analytics
Decouple a producer and a single consumer with message retention
Push a notification to email, SMS, and a Lambda function at once
Guarantee exactly-once processing in strict order
0 of 5 matched so far.