SQS vs. SNS vs. EventBridge: The AWS Messaging Triangle the SAA-C03 Can't Stop Testing

Picture this: you're mid-exam, you've just hit a question about an e-commerce company that needs to "process orders, send confirmation emails, and update inventory in parallel when an order is placed." The answer choices include SQS Standard, SQS FIFO, SNS, and EventBridge. They all seem plausible. The clock ticks.

This is the AWS messaging triangle. The SAA-C03 returns to it constantly — in its Design Resilient Architectures domain, in its Design High-Performing Architectures domain, even disguised as cost-optimization questions. It's one of the "close cousins" that fails the most people. But here's the thing: these three services don't actually do the same job. Each has a distinct shape, and once you see that shape clearly, the exam scenarios snap into focus.

This post gives you the deep understanding — not just "SQS is a queue" — that lets you nail every variant of this question under a two-minute timer.

The Three Shapes: A 60-Second Orientation

Before going deep, get the shape of each service locked in your head:

SQS (Simple Queue Service): A buffer between a sender and a receiver. Messages sit in the queue until a consumer pulls them out. One producer, typically one consumer group processing each message. Think: work distribution.
SNS (Simple Notification Service): A publisher sends one message to a topic; every subscriber receives a copy simultaneously. One producer, many subscribers. Push-based. Think: fan-out notification.
EventBridge: An event bus. Events arrive from AWS services, your own application, or third-party SaaS. Rules match events by JSON pattern and route them to one or more targets. Think: intelligent event routing.

These are not three tiers of the same capability — they're three architecturally different shapes that solve three different problems. The exam confusion comes from the fact that all three appear under the umbrella of "decoupling services," and your job is to pick the right shape for the specific requirements in the question stem.

SQS in Depth

SQS is AWS's oldest messaging service and one of the most heavily tested. The model is simple: producers put messages in, consumers pull them out and delete them after processing. But the details matter enormously.

Standard vs. FIFO: The First Major Fork

Dimension	Standard Queue	FIFO Queue
Ordering	Best-effort (not guaranteed)	Strict first-in, first-out
Delivery	At-least-once (duplicates possible)	Exactly-once processing
Throughput	Nearly unlimited	Up to 3,000 msg/sec with batching
Deduplication	Not built in	Built-in deduplication ID
Primary use	High-throughput, order-tolerant work	Order-critical, duplicate-sensitive work

The exam uses this fork ruthlessly. Any time you see the words "strict order," "sequence," "exactly once," or "no duplicate processing" in the requirements, Standard SQS is eliminated and FIFO is required. Any time you see very high throughput requirements (well above 3,000 messages/second) alongside ordering needs, you may need to reach for Kinesis instead — FIFO has a ceiling.

Visibility Timeout: The Subtlest SQS Concept

When a consumer reads a message from SQS, the message is not deleted. Instead, it becomes invisible to other consumers for the visibility timeout period (default: 30 seconds). If the consumer processes the message successfully and calls DeleteMessage, it's removed permanently. If the consumer crashes or the timeout expires before deletion, the message becomes visible again and another consumer can pick it up.

This is how SQS achieves at-least-once delivery — and it's exactly why Standard queues can produce duplicates. If your application can't tolerate duplicates, you need FIFO (which uses a deduplication ID to prevent re-delivery) or you need your processing logic to be idempotent.

The exam exploits visibility timeout in "why are messages being processed twice?" or "how do you handle a slow processor that takes longer than expected?" questions — the fix is to extend the visibility timeout during processing via ChangeMessageVisibility.

Dead Letter Queues (DLQs)

Configure a maxReceiveCount on an SQS queue (e.g., 5), and any message that fails processing that many times gets moved to a Dead Letter Queue rather than retried indefinitely. DLQs are the exam's canonical answer to:

"Poison pill messages are blocking the queue"
"Failed messages are causing the application to back up"
"How do you preserve failed messages for debugging without blocking new work?"

DLQs work on both Standard and FIFO queues. The DLQ must be the same type as the source queue (FIFO → FIFO DLQ).

Long Polling vs. Short Polling

By default, SQS uses short polling — a ReceiveMessage call returns immediately, even if the queue is empty, and you pay for that empty API call. Long polling (set WaitTimeSeconds to up to 20) holds the connection open until a message arrives or the wait time expires. Long polling is almost always better: fewer API calls, lower cost, reduced CPU load on the consumer. The exam uses this as the cost-optimization answer when a question describes an application "making too many SQS API calls" or incurring unexpectedly high costs from a low-traffic queue.

Key SQS Limits to Know Cold

Message size: 256 KB max. For larger payloads, use the Extended Client Library, which stores the body in S3 and puts a pointer in the queue.
Message retention: 4 days default, configurable up to 14 days.
Consumers must explicitly delete messages — SQS never auto-deletes after delivery.
SQS does not push — consumers must poll. If you need push-based delivery, that's SNS's job.

SNS in Depth

SNS is AWS's pub/sub notification service. You publish once to a topic; every subscriber to that topic receives a copy of the message simultaneously. The defining characteristic is simultaneous delivery to multiple subscribers — that's what the exam means when it says "fan-out."

Subscribers and Protocols

SNS can push messages to: Lambda functions, SQS queues, HTTP/S endpoints, email addresses, SMS numbers, and mobile push notifications (Apple APNS, Google GCM/FCM). The breadth of subscriber types is one of SNS's main strengths on the exam.

Message Filtering: Fan-Out with Selectivity

By default, all subscribers receive every message published to the topic. Subscription filter policies (JSON attribute matchers) let you narrow that: a subscriber only receives messages whose attributes match its filter. This lets you fan out selectively — an "orders" SNS topic sends orderType: "electronics" messages only to the electronics fulfillment SQS queue, and orderType: "clothing" messages only to the clothing queue. One topic, targeted routing, no code changes to add a new subscriber.

The exam tests this when the question asks: "How can the company route different types of events to different downstream systems without the publisher needing to know which systems exist?"

Critical Limitation: No Durable Storage

SNS is push-based and does not durably store messages waiting for a slow consumer. When SNS publishes a message, it attempts to deliver to each subscriber immediately. If an HTTP endpoint is down, SNS has a retry policy, but after that policy is exhausted, the message is gone. Compare this to SQS, where a message waits patiently for up to 14 days regardless of whether the consumer is available.

This difference drives the most important composite pattern on the exam: SNS fan-out with SQS durability (covered in the scenario walkthroughs below).

SNS FIFO Topics

SNS also has FIFO topics, but they only support SQS FIFO queues as subscribers and share the same throughput ceilings. They're relatively uncommon on the current SAA-C03 exam; know they exist, but don't over-study them.

EventBridge in Depth

EventBridge is the evolution of CloudWatch Events (same API, rebranded and extended) and has become an increasingly heavy topic on recent SAA-C03 versions. Think of it as a sophisticated event routing layer that sits at the center of your architecture.

The Core Model

Events arrive on an event bus — the default bus, a custom bus you create, or a partner event bus from a SaaS provider (Salesforce, Zendesk, GitHub, DataDog, and many others).
Rules are evaluated against each event. Each rule has an event pattern (a JSON matcher) and one or more targets.
Events that match a rule are sent to their targets: Lambda, SQS, SNS, Step Functions, Kinesis Data Streams, EC2 Auto Scaling actions, API Gateway, and dozens more.

Why EventBridge, Not SNS, for AWS Service Events

EC2 instance state changes, S3 object creation, GuardDuty findings, CloudTrail API calls, CodePipeline failures, AWS Config rule violations — all of these emit events that automatically flow to the EventBridge default event bus. EventBridge has native integrations with 90+ AWS services as event sources. SNS does not receive AWS service events directly.

This is one of the most reliably tested distinctions on the exam. When you see "triggered by an AWS service doing X" — automatically react to an EC2 launch, respond to an S3 object upload, detect a non-compliant resource — the answer is almost always EventBridge, not SNS.

Scheduling

EventBridge supports two types of scheduled triggers:

Rate expressions: rate(5 minutes), rate(1 hour) — fire at a fixed interval.
Cron expressions: cron(0 12 * * ? *) — fire at a specific time of day, day of week, etc.

Scheduled rules are the exam-standard answer to "run this Lambda function every night at midnight" or "trigger a batch job every Monday morning." Do not confuse this with CloudWatch Alarms, which trigger on metric thresholds, not time.

Cross-Account Event Routing

EventBridge can route events from one AWS account to another by granting a target account permission to receive events. This is the canonical architecture for centralized security monitoring — all member accounts forward GuardDuty and CloudTrail events to an event bus in a dedicated security account, where a single set of rules and Lambda functions processes them. The exam tests this under "multi-account" or "AWS Organizations" security scenarios.

EventBridge vs. CloudWatch Events

If an answer choice says "Amazon CloudWatch Events rule," treat it as equivalent to EventBridge. They share the same underlying API. The exam may use either name; both are correct.

The Master Comparison Table

Dimension	SQS	SNS	EventBridge
Model	Queue (consumer pulls)	Pub/sub (producer pushes)	Event bus (rule-based routing)
Fan-out?	No — one consumer per message	Yes — all subscribers get a copy	Yes — per-rule, multiple targets
Ordering guarantee	FIFO only	No	No
Exactly-once delivery	FIFO only	No	No
Message durability	Up to 14 days	No — push and retry only	No
AWS service events	No	No	Yes — 90+ native sources
Scheduling	No	No	Yes (rate + cron)
Filtering	Not built-in	Subscription filter policies	Native, rich JSON pattern matching
Cross-account	No (queue stays in one account)	No	Yes — event bus resource policies
SaaS integrations	No	No	Yes — partner event buses
DLQ support	Native	For Lambda/SQS subscribers	Per-target DLQ
Max message size	256 KB (+ S3 ext. client)	256 KB	256 KB
Throughput ceiling	Very high (Standard); 3K/s (FIFO)	Very high	High
Pricing model	Per API call	Per API call	Per event (5M/month free)

Three Scenario Walkthroughs

Scenario 1: Financial Trade Processing with Strict Ordering

A financial services company processes stock trade updates. Each update for a given stock symbol must be processed in strict order and must not be processed more than once. The system receives up to 500 updates per second per symbol. Which service and configuration should the solutions architect recommend?

Correct answer: Amazon SQS FIFO queue with one message group per stock symbol.

Reasoning through the requirements:

"Strict order" eliminates Standard SQS (best-effort ordering only) and SNS (no ordering guarantee) and EventBridge (no ordering guarantee).
"Must not be processed more than once" (exactly-once) is available only in SQS FIFO via the message deduplication ID.
500 updates/second per symbol — SQS FIFO supports up to 3,000 messages/second with batching across message groups. Using the stock symbol as the message group ID, ordering is maintained per symbol independently, so 500/second per symbol is well within limits.

Why not Kinesis Data Streams? Kinesis also guarantees ordering per shard and is appropriate for high-throughput streaming with multiple independent consumers. But the question emphasizes exactly-once processing and a work-queue pattern — SQS FIFO's deduplication handles exactly-once more directly. Kinesis shines when the requirement is replayable, multi-consumer streaming (e.g., multiple analytics consumers reading the same stream).

Why not SNS? SNS does not guarantee ordering and does not support exactly-once delivery. It's a fan-out notification service, not a work queue.

Scenario 2: New User Registration Triggering Multiple Downstream Systems

When a new user registers on an e-commerce platform, the system must: (1) send a welcome email, (2) create a record in the analytics data warehouse, and (3) add the user to a third-party CRM. All three must happen independently without blocking the registration response. The email service occasionally goes offline for planned maintenance windows. Which architecture should the solutions architect recommend?

Correct answer: SNS topic with three SQS queue subscribers (the fan-out + durability pattern).

Reasoning:

"All three must happen" — the single registration event needs to reach three separate systems. That's fan-out. → SNS.
"Without blocking the registration response" — the registration service publishes to SNS and returns immediately. It doesn't wait for three downstream systems to finish. → Decoupled via SNS.
"The email service occasionally goes offline" — this is the decisive trap. If you use SNS with an HTTP endpoint for the email service, when the email service is down, SNS retries until its retry window closes and then drops the message permanently. You need durability during the outage. → Place an SQS queue in front of the email processor. The message waits in the queue until the email service comes back online, then processes.

Final architecture: Registration Service → SNS Topic → [SQS Email Queue → Email Processor, SQS Analytics Queue → Analytics Processor, SQS CRM Queue → CRM Processor]

This is the SNS fan-out + SQS durability pattern — one of the most important composite patterns on the SAA-C03. SNS achieves simultaneous fan-out to all three systems; each SQS queue absorbs its message and holds it until its downstream system is ready to process.

Why not just write directly to three SQS queues from the registration service? The registration service is now coupled to three consumers. Adding a fourth consumer requires changing the registration service code. With SNS, you add a new SQS subscriber to the topic and the registration service is unaware. The exam rewards loose coupling.

Why not EventBridge instead of SNS here? EventBridge works too — you could publish a custom event to a custom bus and create three rules with three SQS queue targets. However, for application-generated events that are simple notification messages (not attribute-rich event records from AWS services), SNS with filter policies is the exam's canonical, simpler answer. EventBridge's power shines when you're routing AWS service events or need rich JSON pattern matching across many event types.

Scenario 3: Automated Security Response to Non-Compliant Resources

A security team wants to automatically remediate EC2 instances launched without a required "CostCenter" tag. Whenever an EC2 instance enters the "running" state without the tag, a Lambda function should stop the instance and send an alert to the security team. No custom code should be required to detect the state change. Which service should be used to trigger the Lambda function?

Correct answer: Amazon EventBridge rule targeting Lambda.

Reasoning:

The trigger is an AWS service event — specifically, EC2 emits an EC2 Instance State-change Notification event every time an instance changes state.
This event flows automatically to the EventBridge default event bus without any configuration. You write a rule to match events where source is aws.ec2, detail-type is EC2 Instance State-change Notification, and detail.state is running.
EventBridge routes matching events to the Lambda function (the target), which checks for the tag and stops the instance if absent.
"No custom code required to detect the state change" — EventBridge's native EC2 integration handles detection automatically.

Why not SNS? SNS does not subscribe to EC2 state-change events natively. You cannot configure an SNS topic to automatically receive EC2 events without EventBridge in front of it.

Why not SQS? SQS is a queue for messages your application puts in. EC2 doesn't write state-change events to an SQS queue by default. And even if you got events into SQS somehow, you'd still need something to trigger the Lambda consumer — that something would be EventBridge.

Why not "CloudWatch Events"? That's a valid answer too — CloudWatch Events was the previous name for EventBridge. If the answer choice says "Amazon CloudWatch Events rule targeting Lambda," that's correct.

The Mental Model: Who's in Control?

Here's the durable mental model that works across every variant of this question:

Ask: who is in control — the consumer, the producer, or the event itself?

SQS: the consumer is in control. The consumer decides when to poll, how many messages to fetch in one call, how long to wait, and when to delete. The queue waits patiently without caring about the consumer's schedule. This is the right shape when you need to smooth out bursty traffic, decouple a slow downstream processor from a fast producer, or distribute work across a pool of workers.

SNS: the producer is in control. When the producer publishes, every subscriber receives immediately regardless of whether they're "ready." It's a megaphone — publish once, and everyone in earshot hears it at the same moment. The right shape when you need to notify multiple independent systems about the same event and when those systems are expected to be reliably available (or you add SQS for the ones that aren't).

EventBridge: the event is in control. Neither a specific producer nor a specific consumer is calling the shots — an event arrives, a rule matches it by examining its attributes, and routing happens automatically. Neither the producer nor the target needs to know about each other. This is the right shape when your trigger is an AWS service doing something (an EC2 launch, an S3 upload, a GuardDuty finding), or when you need rich pattern-based routing across many event types from many sources.

Apply the mental model to the scenario:

Need a patient buffer where consumers control the processing rate? → SQS
Need one message to reach many destinations simultaneously? → SNS (+ SQS per destination for durability)
Need to react to an AWS service event or fire something on a schedule? → EventBridge

Common Exam Traps and How to Dodge Them

Trap 1: Picking SNS when ordering or exactly-once is required. Any time the question contains "strict order," "sequence," "process exactly once," or "no duplicate processing" — SNS is eliminated. These properties only exist in SQS FIFO. This is the most reliable keyword signal on the entire topic.

Trap 2: Using SQS alone when a message must reach multiple independent consumers. SQS sends each message to one consumer. If three systems all need to act on the same event, SQS alone won't fan out. You need SNS + three SQS subscriber queues (or EventBridge with multiple targets per rule).

Trap 3: Picking SNS for AWS service events instead of EventBridge. EC2 state changes, S3 object notifications, GuardDuty findings, CloudTrail API calls — these are EventBridge events, not SNS messages. SNS doesn't receive them natively. When the trigger is "when AWS service X does Y," the answer is EventBridge.

Trap 4: Forgetting the SQS FIFO throughput ceiling. SQS FIFO supports 3,000 messages/second with batching (300 API calls/second × 10 messages/batch). Standard SQS is effectively unlimited. If a question pairs very high throughput with an ordering requirement, check whether FIFO can handle the load. If not, Kinesis Data Streams — which provides ordering per shard with much higher throughput — may be the correct answer.

Trap 5: Misidentifying the fan-out pattern components. The canonical pattern is SNS topic → multiple SQS queue subscribers. Not "the producer writes to three SQS queues directly" (that's producer-coupled fan-out — wrong). Not "SNS with three HTTP endpoints" (no durability when an endpoint is down — wrong for scenarios that mention offline windows). The right answer always has SNS providing the fan-out and SQS providing the durable buffer per downstream system.

Trap 6: Confusing EventBridge scheduling with CloudWatch Alarms. EventBridge scheduled rules (rate/cron) trigger targets on a time basis. CloudWatch Alarms trigger on metric thresholds (CPU > 80%, error rate exceeds X). If the question says "run this Lambda every night at midnight" → EventBridge scheduled rule. If it says "trigger when CPU exceeds a threshold" → CloudWatch Alarm. These are not interchangeable.

Trap 7: Not noticing that the DLQ must match the source queue type. If you configure a DLQ for a FIFO queue, the DLQ must also be a FIFO queue. Attempting to configure a Standard SQS queue as the DLQ for a FIFO queue is invalid. The exam may test this subtlety in an "which configuration is valid?" style question.

Exam-Day Checklist: Messaging and Decoupling Questions

When you hit a messaging or decoupling question on exam day, run through this sequence:

Does the scenario require strict ordering or exactly-once delivery? → If yes, SQS FIFO is the only viable AWS queue. Eliminate Standard SQS, SNS, and EventBridge as the primary delivery mechanism.
Does one event need to reach multiple independent systems simultaneously? → Fan-out needed. Reach for SNS (or EventBridge with multiple targets per rule). Do not use SQS alone.
Is the trigger an AWS service event (EC2 state, S3 object, GuardDuty, CloudTrail, Config, CodePipeline, etc.) or a scheduled time? → EventBridge. Not SNS.
Is a downstream system sometimes offline, slow, or rate-limited? → Add an SQS queue in front of it. SQS's 14-day retention absorbs the gap. SNS alone cannot.
Does the question describe too many SQS API calls or unexpectedly high SQS costs on a low-traffic queue? → Switch from short polling to long polling (WaitTimeSeconds > 0).
Does the question mention messages that fail repeatedly and block the queue? → Add a Dead Letter Queue with an appropriate maxReceiveCount.
Is the required throughput very high AND ordering required? → Check FIFO ceiling (3,000/sec with batching). Above that, consider Kinesis.
Does the question mention routing different event types to different targets based on attributes? → EventBridge event patterns or SNS subscription filter policies. EventBridge if the source is an AWS service; SNS if the source is your application with simple attribute-based routing.
Is the question about cross-account event delivery? → EventBridge cross-account event bus, not SNS.

Drill This Until It's Automatic

The messaging triangle — SQS, SNS, EventBridge — appears across multiple SAA-C03 scored domains. Missing one question here costs you in Resilient Architectures, High-Performing Architectures, and Cost-Optimized Architectures scoring buckets simultaneously. It's one of the highest-leverage topics to get right.

Reading about the distinctions is one thing. Getting them right under a two-minute timer, on a question deliberately written to make SQS FIFO look like the answer to a fan-out problem, is another. That's what practice under realistic conditions is for.

CertCoach generates SAA-level scenario questions on exactly these trade-offs, scores you by domain so you can see whether messaging is a weak spot, and lets you ask follow-up questions — "wait, why not SNS here?" — until the concept actually clicks rather than just feeling familiar.

Start free: take the 10-question diagnostic — no signup, no card — and find out where you stand on decoupled architecture questions in under 10 minutes. When you're ready to drill, the CertCoach Pass is $29, one-time — no subscription, well under the cost of your $150 exam voucher.

→ Find your weak domains now