AWS Services
SQS vs SNS vs EventBridge
Compare Amazon SQS, Amazon SNS, and Amazon EventBridge for queues, pub-sub fanout, event routing, filtering, retries, durability, and SAA-C03 integration decisions.
After this, you will understand
Messaging decisions stop feeling fuzzy once learners ask whether the system needs a queue, a broadcast topic, or an event router.
Use SQS for durable work queues, SNS for pub-sub fanout, and EventBridge for event buses with routing rules and many AWS/SaaS integrations.
Learners use SNS as a queue, use SQS for broadcast, or use EventBridge when the consumer really needs backlog and polling.
Classify the integration: one producer to one worker pool, one event to many subscribers, or many event sources routed by event patterns.
Think before readingWhich service should buffer jobs for workers that poll and delete messages?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- Queues
- Pub/sub topics
- Event buses
- Fanout
- Event pattern filtering
- Durable backlog
- Push and pull delivery
- Dead-letter queues
- AWS service events
- SAA-C03 messaging traps
1. Plain-English Mental Model
SQS, SNS, and EventBridge are all integration services, but they move information differently.
SQS = durable queue for workers
SNS = publish once, push to subscribers
EventBridge = route events by rules from many sources to targets
SQS is about backlog and work processing. SNS is about fanout and notification. EventBridge is about event routing and integration.
The deciding question is not "which messaging service is best?" It is "what relationship should exist between producer and consumer?"
2. Why This Service Exists
Distributed systems need different communication shapes.
Sometimes a producer creates work and one worker pool should process each job. A queue is the right shape. SQS stores messages until consumers receive, process, and delete them.
Sometimes one event should reach multiple independent subscribers. A topic is the right shape. SNS fans out copies.
Sometimes many sources emit events and rules decide which targets should react. An event bus is the right shape. EventBridge routes by event patterns.
For SAA-C03, the exam often gives you a clue such as "decouple components", "fan out to multiple queues", "route AWS service events", "filter by event pattern", "dead-letter queue", "subscription filter", or "SaaS event source."
3. The Naive Approach And Where It Breaks
The naive approach is to use one messaging service for every asynchronous problem.
Using SNS as a work queue breaks because every subscriber receives a copy. If three workers are subscribed directly, all three may handle the same event.
Using SQS as fanout breaks because one queue represents one backlog. Multiple consumers compete for messages unless each subscriber has its own queue.
Using EventBridge as a queue breaks when workers need polling, backlog control, visibility timeout, or queue-depth scaling. EventBridge can send events to SQS, but the queue is still the backlog primitive.
The common mature pattern is to combine them deliberately.
4. Core Primitives
SQS primitives are queues, messages, producers, consumers, visibility timeout, dead-letter queues, standard queues, FIFO queues, and long polling.
SNS primitives are topics, subscriptions, publishers, message attributes, subscription filters, delivery protocols, and FIFO topics.
EventBridge primitives are event buses, events, rules, event patterns, targets, Scheduler, Pipes, archives, and replay.
SQS consumers pull messages. SNS pushes deliveries to subscribers. EventBridge routes events to rule targets.
5. Architecture Use Cases
Use SQS when producers should hand off work durably:
API -> SQS -> Lambda or ECS workers
Use SNS when one event should notify many systems:
order-created -> SNS topic -> email queue, analytics queue, fraud queue
Use EventBridge when events need flexible routing:
application events + AWS events + SaaS events -> event bus -> rules -> targets
Use SNS to SQS fanout when every subscriber needs its own durable queue.
Use EventBridge to SQS when events need rule-based selection first and queued processing second.
7. Security Model
SQS uses IAM and queue policies. Queue policies are common for cross-account producers or SNS-to-SQS delivery.
SNS uses IAM and topic policies. When SNS delivers to SQS, the SQS queue policy must allow the SNS topic.
EventBridge uses IAM and event bus resource policies for cross-account patterns. Rules or pipes need permission to invoke targets.
All three can move sensitive data. Do not publish broad messages unless every subscriber or target is allowed to see the data.
Encryption with KMS adds key-policy requirements. A message service can allow access while the KMS key blocks it.
8. Reliability And Resilience
SQS is strongest for durable backlog, retry, worker failure recovery, and dead-letter queues.
SNS is strongest for fanout, but subscriber reliability depends on protocol. SNS plus SQS gives each subscriber durability.
EventBridge is strongest for managed event routing, retries, archives, replay, and AWS/SaaS integration. Use DLQs for targets where supported.
Consumers should be idempotent. Duplicate delivery can happen in practical event-driven systems.
Monitor queue depth, message age, failed deliveries, target failures, and DLQ depth.
9. Performance And Scaling
SQS standard queues support high-throughput worker patterns. FIFO queues trade some throughput characteristics for ordering and deduplication semantics.
SNS fanout multiplies downstream delivery. One publish can create many invocations or queued messages.
EventBridge rule matching and target invocation are managed, but targets can still throttle or fail. Filter early to avoid unnecessary downstream work.
For very high-throughput ordered streams, Kinesis may be the better service. For workflow state, Step Functions may fit better.
10. Cost Model
SQS cost is request-based. Long polling and batching can reduce empty receives and API calls.
SNS cost includes publishes, deliveries, filtering, and protocol-specific costs such as SMS.
EventBridge cost includes events, matched rules, API destinations, archives, replay, Scheduler, and Pipes depending on usage.
The cheaper service is the one that matches the integration shape. A wrong primitive often creates extra Lambda glue, retries, duplicate processing, and operational waste.
12. SAA-C03 Exam Signals
"Buffer messages for workers" points to SQS.
"Visibility timeout" points to SQS.
"Dead-letter queue for failed jobs" often points to SQS.
"Fan out one message to multiple subscribers" points to SNS.
"Send one event to multiple SQS queues" points to SNS plus SQS.
"Route AWS service events by pattern" points to EventBridge.
"SaaS partner event source" points to EventBridge.
"Schedule a task at scale" can point to EventBridge Scheduler.
13. Common Exam Traps
Do not use SNS as a single-consumer work queue.
Do not use one SQS queue when every subscriber needs its own copy.
Do not use EventBridge when the core requirement is worker-controlled polling and backlog.
Do not ignore target permissions.
Do not forget filtering differences: SNS subscription filters and EventBridge event patterns are not the same primitive.
Do not skip DLQs for critical asynchronous flows.
15. Related Topics
Review Amazon SQS, Amazon SNS, Amazon EventBridge, AWS Lambda, and Event-Driven Order Processing.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.