SQS vs SNS vs EventBridge — Decoupling Patterns for SAA-C03
Choosing between SQS, SNS, and EventBridge is one of the most frequently tested architectural decisions on the AWS SAA-C03 exam. The services look similar but serve different patterns. This page walks through the key decision rules and a representative practice question.
This question is part of the free AWS Solutions Architect Associate practice test.
Short answer
The correct answer is B. Have the order service publish to an Amazon SNS topic; each consumer subscribes to the SNS topic.
This scenario describes a fan-out pattern: one event needs to be delivered to multiple independent consumers simultaneously. Amazon SNS is designed exactly for this. The order service publishes a single message to an SNS topic. Each consumer (inventory system, email service, data warehouse) subscribes to the topic and receives its own independent copy. SNS supports multiple subscription protocols: SQS queues, Lambda functions, HTTP endpoints, email, and SMS. Option A is wrong because a standard SQS queue delivers each message to exactly ONE consumer — if three consumers poll the same queue, each message will typically only be processed once by one of them, not all three. Option C introduces unnecessary complexity and polling overhead. Option D creates tight coupling — the order service depends on each downstream service being available, and latency increases with each sequential call.
The Question
A company processes online orders. When a new order is placed, the system must simultaneously trigger an inventory update, send a confirmation email, and log the transaction to a data warehouse. Each of these three systems needs to receive its own copy of the order event. The company wants to minimize coupling between the order service and the downstream consumers. Which architecture should a solutions architect recommend?
Why B is correct
This scenario describes a fan-out pattern: one event needs to be delivered to multiple independent consumers simultaneously. Amazon SNS is designed exactly for this. The order service publishes a single message to an SNS topic. Each consumer (inventory system, email service, data warehouse) subscribes to the topic and receives its own independent copy. SNS supports multiple subscription protocols: SQS queues, Lambda functions, HTTP endpoints, email, and SMS. Option A is wrong because a standard SQS queue delivers each message to exactly ONE consumer — if three consumers poll the same queue, each message will typically only be processed once by one of them, not all three. Option C introduces unnecessary complexity and polling overhead. Option D creates tight coupling — the order service depends on each downstream service being available, and latency increases with each sequential call.
Why the other options are wrong
An SQS queue is point-to-point: each message is delivered to one consumer. Multiple consumers competing on the same queue will each receive different messages, not the same message. For fan-out (one message to many consumers), you need SNS or EventBridge.
DynamoDB Streams can trigger Lambda functions on changes, but this adds unnecessary architectural complexity for a simple fan-out use case. It is not the AWS-recommended pattern for publishing events to multiple consumers.
Synchronous API calls create tight coupling: if any downstream service is slow or unavailable, the order service fails. This violates the decoupling requirement and is the opposite of event-driven architecture.
SQS, SNS, and EventBridge: which to use when
AWS has three main messaging services for decoupling architectures and the SAA-C03 exam tests all three. Understanding the distinctions is essential. Amazon SQS (Simple Queue Service) is a pull-based, point-to-point queue. Producers write messages; consumers poll and process them. Each message is delivered to exactly one consumer (in a standard queue, with at-least-once delivery). SQS Standard queues have unlimited throughput but may deliver messages out of order or more than once. SQS FIFO queues guarantee ordering and exactly-once processing, but have lower throughput (up to 3,000 messages/sec with batching). SQS is ideal for: work queues, background jobs, rate limiting, load leveling. Key words: "process messages one at a time," "retry failed jobs," "decouple producer from consumer rate." Amazon SNS (Simple Notification Service) is a push-based, pub/sub service. One publisher, many subscribers. Each subscriber gets its own copy of the message. SNS supports SQS, Lambda, HTTP/HTTPS, email, and SMS subscriptions. The SNS + SQS fan-out pattern is critical: publish to SNS → SNS pushes to multiple SQS queues → each queue is processed independently. This is the canonical multi-consumer, durable fan-out pattern. Amazon EventBridge (formerly CloudWatch Events) is an event bus with content-based routing. It routes events based on rules that match patterns in the event payload. It natively receives events from 300+ AWS services, SaaS applications, and your own code. Use EventBridge when you need: routing based on event content, integration with third-party SaaS events, scheduled events (cron), or event archiving and replay. The decision tree: one message → one consumer? SQS. One event → many consumers, same message? SNS (or EventBridge). Event routing based on content, AWS service events? EventBridge. EventBridge versus SQS is the pairing candidates most often get wrong, because the two are not really alternatives. SQS is a buffer: it stores messages durably until a consumer pulls them, retains them for up to 14 days, and gives you a dead-letter queue, visibility timeouts, and backpressure control. EventBridge is a router: it takes an event, matches it against rules, and pushes it to up to five targets per rule, with no consumer-side polling and no long-term storage unless you enable archive and replay. EventBridge retries a failed target with exponential backoff for up to 24 hours and then drops the event unless you attached a dead-letter queue. That is why the production pattern is usually EventBridge in front of SQS: the bus does content-based routing, the queue absorbs load and preserves failures. Choose SQS alone when the requirement is load leveling, throttling a slow consumer, ordering with FIFO, or guaranteed retention. Choose EventBridge alone when the requirement is filtering on event content, reacting to AWS service events such as an EC2 state change or an S3 upload, ingesting SaaS partner events from Zendesk, Datadog, or Shopify, running a cron schedule, or fanning one event out to heterogeneous targets like Lambda, Step Functions, and Kinesis at once. EventBridge versus SNS is a closer comparison, since both fan out. SNS is the higher-throughput, lower-latency option, with near-unlimited subscriptions, millisecond delivery, and protocols EventBridge lacks such as email, SMS, and mobile push; its filtering works on message attributes rather than the message body. EventBridge adds richer JSON content filtering on the payload itself, a schema registry, archive and replay, cross-account and cross-region buses, and 300-plus native AWS and SaaS event sources, at a latency measured in tens to hundreds of milliseconds. On price, SQS and SNS bill per million requests, while EventBridge bills roughly $1 per million custom events published and passes AWS service events through free. Exam shorthand: notify people or push to many subscribers fast, use SNS; route structured events by content or from AWS services, use EventBridge; hold work for a consumer to process at its own pace, use SQS.
EventBridge vs SQS vs SNS
| Feature | Amazon EventBridge | Amazon SQS | Amazon SNS |
|---|---|---|---|
| Use case | Route events by content; react to AWS service and SaaS events; schedules | Buffer work for one consumer; load leveling; retry slow jobs | Fan one message out to many subscribers; notifications (email, SMS, push) |
| Delivery model | Push to targets that match a rule | Pull: consumers poll the queue | Push to every subscriber |
| Ordering | No ordering guarantee | Standard: best effort; FIFO: strict ordering | Standard: no guarantee; FIFO topics: ordered (to FIFO queues) |
| Fan-out | Yes, up to 5 targets per rule; many rules per bus | No, each message goes to one consumer | Yes, many subscribers per topic |
| Retry and durability | Retries a failed target up to 24 hours, then drops unless a dead-letter queue is set | Stores messages up to 14 days; visibility timeout; dead-letter queue | Retries per protocol; no long-term storage; use SQS subscribers for durability |
| Price model | About $1 per million custom events; AWS service events are free | Per million requests | Per million requests, plus per-message delivery for SMS and email |
SQS vs SNS vs EventBridge decision table
| Scenario clue | Choose | Avoid | Why |
|---|---|---|---|
| One message must be processed by exactly one worker; consumers are slow or bursty | Amazon SQS | SNS, EventBridge | Only SQS is a durable pull-based buffer with visibility timeouts, retention up to 14 days, and a dead-letter queue. |
| One event, many subscribers, each needs its own copy, lowest latency, or email/SMS/mobile push | Amazon SNS | EventBridge, SQS | SNS is the high-throughput pub/sub fan-out service and the only one with email, SMS, and mobile push protocols. |
| Route events to different targets based on fields inside the event payload | Amazon EventBridge | SNS, SQS | EventBridge rules pattern-match the full JSON event body. SNS filtering only inspects message attributes. |
| React to an AWS service event (EC2 state change, S3 upload, CodePipeline) or a SaaS partner event | Amazon EventBridge | SNS, SQS | EventBridge natively receives events from 300+ AWS services and SaaS partners; the default bus gets them for free. |
| Scheduled or cron-style triggering of a Lambda function or Step Functions workflow | Amazon EventBridge Scheduler | SQS, SNS | Neither SQS nor SNS can originate an event on a schedule. |
| Need to replay past events or enforce an event schema across teams | Amazon EventBridge | SNS, SQS | Archive, replay, and the schema registry are EventBridge-only features. |
| Fan out AND survive a downstream outage without losing messages | SNS or EventBridge in front of SQS queues | SNS or EventBridge delivering straight to Lambda | The queue provides durability and retry; the bus or topic provides the fan-out. This combination is the canonical exam answer. |
Ready to see how you'd score?
Take the free practice quiz and find out which AWS Solutions Architect Associate domains you need to focus on. No signup required.
Practice 5 similar questions
Same cert, same or adjacent domain. Use these after reviewing the explanation.
Related AWS Solutions Architect Associate Practice Questions
Quick FAQ
Amazon EventBridge vs SQS: which one should I use?
Use Amazon EventBridge when you need to route events to different targets based on the event content, react to AWS service or SaaS events, or run a schedule. Use Amazon SQS when one consumer must process each message at its own pace, or when you need retries, ordering with FIFO, or retention. In production they are often combined: EventBridge routes the event and an SQS queue buffers it for the consumer.
What is the difference between EventBridge and SQS?
EventBridge is a push-based event router: it matches events against rules and delivers them to targets, with no polling and no long-term storage unless you enable archive. SQS is a pull-based durable queue: it stores messages for up to 14 days until a consumer polls them, and gives you visibility timeouts, dead-letter queues, and backpressure control. They are complementary, and the common production pattern is EventBridge routing events into SQS queues.
When should I use SQS vs SNS vs EventBridge on the SAA-C03 exam?
Use SQS when one message should be processed by exactly one consumer, or when you need load leveling and retries. Use SNS when one event must fan out to many subscribers with the lowest latency, or when you need email, SMS, or mobile push. Use EventBridge when routing depends on the content of the event, when the source is an AWS service or SaaS partner, or when you need scheduling, archive and replay, or a schema registry.
What is the difference between SNS and EventBridge?
Both fan out one event to multiple targets. SNS is faster and higher throughput, supports near-unlimited subscriptions, and offers email, SMS, and mobile push, but filters only on message attributes. EventBridge filters on the full JSON event body, natively ingests events from 300+ AWS services and SaaS partners, supports cross-account and cross-region buses, archive and replay, and a schema registry, but has higher latency and a limit of five targets per rule.
Can EventBridge replace SQS?
No. EventBridge retries a failing target with exponential backoff for up to 24 hours and then drops the event unless a dead-letter queue is attached. It has no consumer-paced polling, no visibility timeout, and no 14-day retention. If you need durable buffering or want to protect a slow consumer, put an SQS queue behind EventBridge rather than replacing it.
How do SQS, SNS, and EventBridge compare on cost?
SQS and SNS are billed per million API requests, which makes them very cheap at high volume. EventBridge charges roughly $1 per million custom events published, while events emitted by AWS services onto the default bus are free. For very high-volume fan-out, SNS is typically the cheaper choice; for content-based routing of moderate event volumes, EventBridge cost is usually negligible.