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.

foundation5 min readUpdated 2026-06-03CloudCertificationReliabilityTradeoffs
Amazon SQSAmazon SNSAmazon EventBridgeQueuePub/SubEvent BusFanoutEvent Pattern

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.

Plain version

Use SQS for durable work queues, SNS for pub-sub fanout, and EventBridge for event buses with routing rules and many AWS/SaaS integrations.

Decision pressure

Learners use SNS as a queue, use SQS for broadcast, or use EventBridge when the consumer really needs backlog and polling.

Exam-ready model

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?
Amazon SQS, because it is a managed queue built for durable backlog and consumer-controlled processing.

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.

  1. 1Event-Driven Order Processingaws-scenarios

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.

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.