SQS vs SNS vs EventBridge: AWS Decoupling for SAA-C03 (2026)

Loose coupling is an AWS design principle and a reliable source of SAA-C03 questions, and three services deliver it: SQS, SNS, and EventBridge. They overlap enough to confuse and differ enough that the wrong one is a wrong answer. This guide draws the lines, covers the fan-out pattern that combines them, and maps the scenarios AWS tests.

Decoupling sits in the Resilience domain (26%); pair this with the high availability guide for the full picture.

Why Decouple at All

A tightly-coupled system calls its components directly and synchronously, so a slow or failed downstream drags everything with it: the web tier waits on the processing tier, and if processing is down, requests are lost. Inserting a messaging layer lets components produce and consume work independently. The web tier hands work to a queue and moves on; the processing tier pulls when it can; a traffic spike fills the buffer instead of dropping requests. That independence is both a resilience and a scalability win, which is why the exam reaches for it constantly.

The Three Services

SQS is a queue: a producer puts messages in, a consumer pulls them out, and messages wait until processed. Its superpower is buffering: it absorbs load spikes and shields consumers from being overwhelmed. Two flavors:

• Standard: near-unlimited throughput, at-least-once delivery, best-effort ordering (occasional duplicates and reordering).
• FIFO: strict ordering and exactly-once processing, lower throughput. The answer when the stem says "order must be preserved" or "no duplicates."

SNS is pub/sub: a publisher sends to a topic and every subscriber gets a copy, pushed immediately. It fans one event out to many recipients (email, SQS queues, Lambda, HTTP). No buffering, so if a subscriber is down when the message is sent, it misses it, unless the subscriber is an SQS queue.

EventBridge is an event bus with content-based routing: events from AWS services, SaaS partners, or your apps flow in, and rules route each to targets based on its content. It carries a schema registry and native integrations SNS lacks. The answer when the stem describes "route different event types to different targets" or "react to events from a SaaS application."

The Fan-Out Pattern (SNS + SQS)

The most-tested combination: SNS fans an event out to multiple SQS queues, one per consumer. This marries SNS's broadcast with SQS's durability, so each consumer gets its own buffered copy and none miss a message even if temporarily down.

Order placed -> SNS topic ─┬─> SQS: billing queue    -> billing service
                           ├─> SQS: shipping queue   -> shipping service
                           └─> SQS: analytics queue  -> analytics service

A scenario where "one event must reliably reach several independent systems, each processing at its own pace" is describing SNS + SQS fan-out. Plain SNS alone risks a down subscriber missing the event; the SQS queues fix that with buffering.

Choosing Under Pressure

The decision the exam makes you make, distilled:

• One producer, one consumer, buffer the load -> SQS.
• Order matters or no duplicates -> SQS FIFO.
• Broadcast one event to many consumers -> SNS (or SNS + SQS for durability).
• Route events by their content to different targets, or ingest SaaS/AWS events -> EventBridge.
• Scale a worker fleet with the backlog -> SQS queue depth as the Auto Scaling metric.

A useful tiebreaker: if the question emphasizes routing logic ("send order events here, inventory events there"), it is EventBridge; if it emphasizes broadcast ("notify all these systems"), it is SNS; if it emphasizes buffering and independent processing, it is SQS.

How This Shows Up on the Exam

• A spike in orders overwhelms the processing service and requests are lost. (Buffer with an SQS queue; scale consumers on queue depth.)
• Payment events must be processed in exact order with no duplicates. (SQS FIFO.)
• One "order placed" event must reach billing, shipping, and analytics reliably and independently. (SNS + SQS fan-out.)
• Route events from a third-party SaaS to different Lambda functions by event type. (EventBridge with routing rules.)
• Broadcast a notification to email, a queue, and a Lambda at once. (SNS topic with multiple subscribers.)

Key Takeaways

• SQS = queue that buffers; SNS = pub/sub broadcast; EventBridge = event bus with content routing
• SQS FIFO when order or exactly-once matters; Standard for maximum throughput
• SNS + SQS fan-out gives broadcast plus per-consumer durability, the canonical reliable pattern
• EventBridge when routing logic or SaaS/AWS event integration is the requirement
• Scale consumers on SQS queue depth to absorb spikes gracefully

Continue with cost optimization, or drill decoupling scenarios in Preporato's SAA-C03 practice exams.

Sources:

• Amazon SQS Documentation
• Amazon SNS Documentation
• Amazon EventBridge Documentation

Last updated: July 10, 2026