SQS, SNS, or EventBridge? Choose by Delivery Model
Amazon SQS, Amazon SNS, and Amazon EventBridge often appear in the same architecture because all three help decouple systems. That overlap makes them easy to compare as if they were interchangeable messaging products. They are better understood as different delivery models: SQS gives consumers a durable queue to work through, SNS pushes a published message to subscribers, and EventBridge routes events to targets according to rules.
The choice matters because it changes who controls processing speed, what happens when a consumer is unavailable, how one event reaches many destinations, whether ordering matters, and where filtering logic lives. AWS now publishes a dedicated decision guide for these services, reinforcing that good architecture starts with communication semantics rather than a feature checklist. Those trade-offs are central to the distributed-system thinking behind SAA-C03.
A practical decision process begins with one question: after a producer creates work or announces that something happened, what behavior should the receiving side have? The answer usually makes the service choice much clearer.
Use SQS when the consumer needs a backlog
SQS is a queue. Producers place messages into it, and consumers retrieve and process them. That creates temporal decoupling: the producer can keep creating work even when consumers are slower or temporarily unavailable, subject to queue retention and the rest of the design. The queue becomes a buffer between demand and processing capacity.
This model is especially useful for background jobs, work distribution, smoothing bursts, protecting a slower downstream system, and pipelines where consumers should process each unit of work independently. Consumers can scale based on queue depth, and visibility timeouts prevent another worker from immediately taking a message that is already being processed.
SQS also forces architects to think about duplicate delivery and idempotency. Standard queues provide at-least-once delivery, so a consumer should be safe when the same logical message is handled more than once. FIFO queues add ordering and deduplication capabilities for cases that genuinely require them, but ordering should be a requirement rather than a default preference.
Use SNS when one publication should fan out
SNS follows a publish-subscribe model. A producer publishes to a topic, and the topic pushes notifications to its subscriptions. That makes SNS a natural fit when the same event or message should be delivered to multiple independent destinations such as SQS queues, Lambda functions, HTTP endpoints, or notification channels.
The strongest pattern is often SNS plus SQS rather than SNS instead of SQS. A single publication can fan out to several queues, giving each downstream team or service its own durable backlog and processing rate. One consumer can be temporarily slow without forcing every other subscriber to wait.
Subscription filtering can also prevent every subscriber from receiving every message. But SNS is still best understood as a broadcast mechanism. If the main problem is durable work consumption by one logical consumer group, a queue usually provides the clearer abstraction.
Use EventBridge when the event itself drives routing
EventBridge is an event bus. Producers emit events that describe something that happened, and rules match event content and route matching events to targets. This is useful when the architecture should react to business events, AWS service events, SaaS events, or application events without the producer knowing each consumer.
The difference from simple fanout is the routing model. EventBridge rules can inspect event structure and direct different event types to different targets. That makes it useful for event-driven systems where “order.created,” “payment.failed,” and “customer.updated” trigger different workflows and where new consumers may be added later without modifying the original producer.
EventBridge also supports capabilities such as archives and replay, but the live bus should not be mistaken for a queue that consumers drain at their own pace. If a downstream system needs backlog control, buffering, or explicit worker-rate management, routing an EventBridge target into SQS can combine the two models.
Consumer control is the fastest way to separate the choices
Ask who should control the processing rate. With SQS, consumers pull messages and therefore have direct control over how quickly they drain the queue. That makes backpressure visible: queue depth grows when incoming work exceeds processing capacity. You can then scale consumers or accept a longer processing delay.
With SNS, delivery is pushed toward subscribers. Subscribers need retry and failure handling that matches their endpoint type. With EventBridge, the bus evaluates rules and invokes targets according to event delivery behavior. These are excellent models for notification and reaction, but they do not give every target the same backlog semantics as a dedicated queue.
This distinction is important for developers working with serverless and event-driven systems, which is why DVA-C02 is a natural deeper relationship when architecture decisions turn into application-level event handling, retries, idempotency, and deployment behavior.
Ordering is expensive enough to justify consciously
Many architectures say they need ordered messages when they really need correct state transitions. Global ordering can reduce parallelism and create hot spots, while per-entity ordering may be enough. Before selecting a FIFO design, define exactly which events must be observed in order and what the application should do if messages are delayed, repeated, or arrive after a newer state.
SQS FIFO and SNS FIFO can support ordered workflows, but the whole path must preserve the required semantics. EventBridge does not provide a general ordering guarantee. If ordered processing is essential, the event bus can route into a FIFO-capable downstream design, or the application can carry sequence information and reject stale updates.
Architects should separate “the business cannot accept out-of-order effects” from “we would prefer the infrastructure to deliver in order.” The former is an application invariant and often deserves protection in the data model as well as the messaging layer.
Retries and dead letters belong in the architecture
Distributed systems fail in partial ways. A message can be delivered while a database is unavailable, a target can time out after performing the work, or a downstream API can throttle. Retrying is necessary, but uncontrolled retries can amplify an outage. Backoff, jitter, retry limits, idempotency, and dead-letter handling should be designed together.
SQS gives especially visible control because failed messages can return to the queue after the visibility timeout and eventually move to a dead-letter queue according to redrive policy. SNS and EventBridge have their own retry and dead-letter options for supported targets. The important point is to define what happens after repeated failure instead of assuming managed services make failure disappear.
PrepAway’s discussion of serverless architecture with AWS Lambda becomes more useful when Lambda is viewed as one consumer inside this larger delivery system rather than as an isolated compute feature.
Composing services is often better than choosing only one
Real systems frequently use all three services. An application can publish a domain event to EventBridge, route one event type to an SNS topic for broad notification, and route another to an SQS queue that buffers a CPU-heavy worker fleet. SNS can fan out the same event into several SQS queues so each consumer has independent retry and throughput behavior.
Composition works when each service has one clear responsibility. It becomes confusing when every message is copied through several layers without a reason. Each hop introduces cost, observability needs, IAM permissions, retry behavior, and another place where duplicate delivery must be understood.
The architecture should therefore be explainable in plain language: the bus routes events, the topic broadcasts, the queue buffers work. If a component cannot be described that clearly, the design may be using a service because it is familiar rather than because its delivery semantics match the requirement.
Security boundaries should follow the same contract. Producers should publish only to the queues, topics, or buses they own; consumers should receive only the event classes they need; and cross-account event flows should be explicit. Resource policies on queues, topics, and event buses can support that separation, but broad wildcard publishing permissions can turn a clean event architecture into an accidental shared integration layer.
Observability should follow the message lifecycle
Messaging failures are often invisible if teams monitor only producer success. A producer can publish successfully while consumers are throttled, a queue is aging, a subscription is repeatedly retrying, or an EventBridge target is failing. Useful telemetry follows the message after publication: queue depth and message age, failed deliveries, dead-letter activity, consumer latency, duplicate handling, and target errors.
Correlation identifiers are equally important. A business event may cross a topic, queue, function, workflow, and database before completion. Carrying a stable event or transaction identifier through that path makes it possible to reconstruct what happened without relying on timestamps alone. This operational visibility is part of the architecture because a decoupled system that cannot be traced is difficult to recover safely.
Choose the communication contract before the AWS service
Start with the producer-consumer contract. Is this work that must eventually be processed? Is it a notification that several subscribers should receive? Is it an event that should be routed by content to loosely coupled targets? Does the consumer need to control its processing rate? Must messages be ordered? Can duplicates occur safely? How long can downstream systems be unavailable?
Once those answers are written down, SQS, SNS, and EventBridge become much easier to place. The broader AWS Certified Solutions Architect – Associate discipline is valuable because it trains this kind of requirement-first thinking across security, resilience, performance, and cost rather than rewarding product selection by keyword.
At more complex organizational scale, SAP-C02 pushes the same reasoning into multi-account event flows, integration boundaries, and architectures that evolve over time. The principle remains simple: pick the delivery model first, then choose the service that implements it with the fewest surprises.