If you’ve started practicing SAA-C03 questions, you’ve already noticed a pattern: a huge share of the “Design Resilient Architectures” domain comes down to one idea — decoupling. Two components that talk to each other directly are fragile; if one is slow or down, the other fails. AWS gives you a small family of messaging services to break that tight coupling, and the exam tests whether you can pick the right one from a scenario.
This guide covers the three services you’ll see constantly — Amazon SQS, Amazon SNS, and Amazon EventBridge — plus the patterns that combine them. By the end you’ll be able to read a question, spot the decision-driving keywords, and choose confidently.
New to the exam itself? Start with the AWS Solutions Architect Associate Guide 2026 and the exam domains strategy, then use this article to go deep on the messaging services.
Why Decoupling Matters on the Exam
Tightly coupled systems share a failure mode: a spike or an outage in one component cascades into the others. Decoupling inserts a buffer or a broker between components so they can scale, fail, and recover independently. On the SAA-C03 exam, watch for these phrases — they almost always signal a decoupling answer:
- “decouple the components”
- “handle sudden spikes in traffic”
- “process orders asynchronously”
- “must not lose messages if the consumer is down”
- “notify multiple systems when an event occurs”
The three services map to three different communication shapes:
| Service | Shape | One-line mental model |
|---|---|---|
| SQS | Queue (1 producer → 1 consumer group) | A buffer that holds work until something pulls it |
| SNS | Pub/Sub (1 publisher → many subscribers) | A megaphone that pushes to everyone subscribed |
| EventBridge | Event bus + routing | A smart router that filters events to targets by rules |
Get those three mental models solid and most questions answer themselves.
Amazon SQS: The Buffer
Simple Queue Service is a fully managed message queue. A producer sends messages in; consumers poll to pull them out. The queue absorbs bursts so consumers can process at their own pace — the canonical “smooth out spiky traffic” answer.
Standard vs FIFO queues
This distinction is a guaranteed exam topic:
| Property | Standard | FIFO |
|---|---|---|
| Ordering | Best-effort | Strict, guaranteed order |
| Delivery | At-least-once (possible duplicates) | Exactly-once processing |
| Throughput | Nearly unlimited | 300 msg/s (3,000 with batching) per group |
| Use when | Maximum throughput, order doesn’t matter | Order matters, no duplicates (e.g. financial transactions) |
Scenario clue: if a question says “order of operations must be preserved” or “payments must not be processed twice,” the answer is FIFO. If it stresses massive scale and order doesn’t matter, it’s Standard.
Visibility timeout and dead-letter queues
Two SQS concepts show up repeatedly:
Visibility timeout — when a consumer picks up a message, SQS hides it from other consumers for a set period. If the consumer finishes and deletes the message, it’s gone. If it crashes before deleting, the message reappears after the timeout and another consumer retries it. Set it slightly longer than your worst-case processing time.
Dead-letter queue (DLQ) — after a message fails processing maxReceiveCount times, SQS moves it to a separate DLQ instead of retrying forever. This is the answer whenever a question asks how to isolate and inspect messages that repeatedly fail.
# Create a queue and send a message (CLI)
aws sqs create-queue --queue-name orders
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123456789012/orders \
--message-body '{"orderId":"A-1001","amount":42.00}'
# Consumer polls (long polling reduces empty receives + cost)
aws sqs receive-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123456789012/orders \
--wait-time-seconds 20 \
--max-number-of-messages 10Cost/efficiency clue: “reduce the number of empty API calls” or “reduce cost of polling” → enable long polling (
--wait-time-seconds 20).
The classic SQS decoupling pattern
A web tier writes orders to a queue; a fleet of workers (often behind an Auto Scaling group) pulls and processes them. If orders spike, the queue grows; you scale workers on queue depth (the ApproximateNumberOfMessagesVisible CloudWatch metric). The web tier never blocks, and nothing is lost if workers fall behind.
[ Web Tier ] --> [ SQS Queue ] --> [ Auto Scaling Worker Fleet ]
|
(scale workers on queue depth)Amazon SNS: The Fan-Out
Simple Notification Service is publish/subscribe. A publisher sends one message to a topic, and SNS pushes a copy to every subscriber — Lambda functions, SQS queues, HTTP endpoints, email, or SMS. The keyword is push, and the pattern is fan-out: one event, many parallel reactions.
Scenario clue: “notify multiple systems,” “send to several endpoints at once,” or “one event must trigger several independent processes” → SNS.
The SNS + SQS fan-out pattern (memorize this)
The single most tested integration pattern on SAA-C03 is SNS fanning out to multiple SQS queues. A publisher sends one message to an SNS topic; the topic delivers a copy to several subscribed SQS queues; each queue feeds a different downstream service that processes at its own pace.
┌──> [ SQS: inventory ] --> inventory service
[ Order API ] --> [ SNS topic ] ──> [ SQS: billing ] --> billing service
└──> [ SQS: analytics ] --> analytics serviceWhy this beats SNS pushing directly to each service:
- Each queue buffers independently — a slow analytics service doesn’t slow billing.
- If a consumer is down, its queue retains the message (durability) instead of dropping it.
- Each consumer gets its own DLQ for failures.
If a question describes one event that must reliably reach several decoupled, independently-scaling consumers, this is almost always the intended answer.
Standard vs FIFO topics and message filtering
SNS also offers FIFO topics (which must pair with FIFO queues) for ordered fan-out. And message filtering lets each subscription receive only the messages matching a filter policy — so a single topic can serve many subscribers who each care about different event types, without a separate topic per type.
Amazon EventBridge: The Smart Router
EventBridge (formerly CloudWatch Events) is an event bus that routes events to targets based on rules that match the event content. It overlaps with SNS — both do pub/sub-style delivery — but EventBridge adds capabilities SNS lacks.
When EventBridge wins over SNS
| Need | Choose |
|---|---|
| Simple, high-throughput fan-out to SQS/Lambda/email | SNS |
| Route based on event content with rich filtering | EventBridge |
| Ingest events from AWS services or SaaS partners | EventBridge |
| Schedule events (cron-like) | EventBridge Scheduler |
| Archive and replay past events | EventBridge |
| Transform the event payload before delivery | EventBridge |
Scenario clues for EventBridge: “react to AWS service events” (e.g. an EC2 state change, an S3 upload via CloudTrail), “integrate with a third-party SaaS,” “route based on the event’s content,” or “run on a schedule.”
A rule that routes by content
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["stopped", "terminated"]
}
}This rule matches only EC2 stop/terminate events and forwards them to a target — say, a Lambda that updates a CMDB or an SNS topic that pages an on-call engineer. SNS alone can’t inspect and route on the event body like this.
EventBridge Scheduler vs cron on a server
If a scenario needs a task to run on a schedule (nightly report, hourly cleanup) without managing a server, EventBridge Scheduler triggering a Lambda is the serverless answer — no EC2 instance running cron, no patching, pay only when it fires.
Choosing the Right Service: A Decision Guide
When you read a messaging question, walk this short decision tree:
- One sender, one logical consumer group, needs a buffer for spikes or retries? → SQS.
- One event must reach many subscribers at once (fan-out)? → SNS (and usually SNS → SQS for durability per consumer).
- Need content-based routing, AWS/SaaS event sources, scheduling, or replay? → EventBridge.
- Need ordering / no duplicates? → FIFO (SQS FIFO, or SNS FIFO + SQS FIFO).
- Failed messages must be isolated for inspection? → Dead-letter queue.
Side-by-side summary
| Question keyword | Likely answer |
|---|---|
| ”decouple,” “buffer,” “spiky traffic” | SQS |
| ”process must not be lost if consumer is down” | SQS (or SNS→SQS) |
| “order must be preserved,” “no duplicates” | SQS FIFO |
| ”notify several systems,” “fan out” | SNS |
| ”one event, many independent consumers, durable” | SNS → SQS fan-out |
| ”route based on event content” | EventBridge |
| ”react to an AWS service event” | EventBridge |
| ”run on a schedule, serverless” | EventBridge Scheduler |
| ”messages failing repeatedly” | Dead-letter queue |
Common Exam Traps
- SNS does not store messages durably for offline consumers. If a subscriber is down when SNS pushes, that delivery can be lost. That’s why the SNS→SQS pattern exists. Don’t pick “SNS direct to Lambda” when the question stresses durability.
- SQS is pull, not push. If a question says messages must be pushed to consumers, SQS alone isn’t it.
- EventBridge ≠ a queue. It routes and filters; it doesn’t buffer work for a polling fleet the way SQS does. Need a buffer? That’s SQS.
- Kinesis is a different animal. If a scenario mentions real-time streaming analytics, ordered replay of a high-volume data stream, or multiple consumers reading the same stream at different positions, think Kinesis Data Streams, not SQS/SNS.
Practice With Realistic Scenario Questions
Decoupling questions are won by pattern recognition — and pattern recognition comes from doing dozens of scenario questions until the keywords trigger the right answer automatically. Reading about SNS→SQS fan-out once is not the same as having answered fifteen variations of it.
Sailor.sh’s AWS Certified Solutions Architect – Associate (SAA-C03) Mock Exam Bundle gives you exam-realistic, scenario-based questions across exactly these decoupling patterns, with detailed explanations of why each option is right or wrong — which is where the real learning happens. It’s built to mirror the SAA-C03 format and difficulty so exam day feels familiar.
Combine it with focused study using the AWS Solutions Architect study plan, and round out your service knowledge with the deep dives on IAM for SAA-C03, S3, and the Well-Architected Framework.
Frequently Asked Questions
What’s the difference between SQS and SNS in one sentence?
SQS is a pull-based queue where one consumer group processes buffered messages; SNS is a push-based pub/sub topic that delivers each message to many subscribers at once.
When should I use EventBridge instead of SNS?
Use EventBridge when you need content-based routing (match on the event body), events from AWS services or SaaS partners, scheduling, payload transformation, or archive-and-replay. Use SNS for simple, high-throughput fan-out to many subscribers.
Why combine SNS with SQS instead of using SNS alone?
SNS delivery to an offline subscriber can be lost. Putting an SQS queue between SNS and each consumer makes delivery durable — the queue holds the message until the consumer is healthy — and gives each consumer independent scaling and its own dead-letter queue.
When do I need a FIFO queue?
When message order must be preserved and duplicates are unacceptable — financial transactions, inventory adjustments, anything where “process exactly once, in order” matters. FIFO trades some throughput for these guarantees.
Is SQS or Kinesis the right answer for streaming data?
For decoupling discrete units of work, use SQS. For real-time streaming, ordered replay, or multiple consumers reading the same high-volume stream independently, use Kinesis Data Streams. The exam distinguishes these deliberately.
Conclusion
Decoupling is the backbone of resilient AWS architecture, and SQS, SNS, and EventBridge are the tools the SAA-C03 exam expects you to wield. Lock in the three mental models — SQS is a buffer, SNS is a megaphone, EventBridge is a smart router — then learn the SNS→SQS fan-out pattern cold, because it appears more than any other.
Once the keyword-to-service mapping is automatic, these questions go from intimidating to free points. Practice enough realistic scenarios that you recognize the shape of the problem before you’ve finished reading the question — that’s what a prepared Solutions Architect does, on the exam and in the real world.