Comparisons / SQS vs SNS vs EventBridge
Application Integration

SQS vs SNS vs EventBridge

SQS is a polling-based queue for one-to-one delivery. SNS is a push-based pub/sub service for one-to-many fan-out. EventBridge is an event bus that flexibly routes events to multiple targets based on rules.

AspectAmazon SQSAmazon SNSAmazon EventBridge
Communication modelPolling-based queue (one-to-one)Push-based pub/sub (fan-out)Event bus (rule-based routing)
Message retentionRetained in queue up to 14 daysStandard has no built-in replay; FIFO supports archive/replay for up to 365 daysNot retained, routed immediately (archive/replay available)
Delivery targetPolling consumers (Standard is at-least-once, so processing must be idempotent)Multiple subscribers simultaneouslyMultiple targets based on rules
OrderingNone by default; FIFO queue guarantees orderNone by default; FIFO topic guarantees orderNot guaranteed
Typical useDecoupling async processing, worker queuesFan-out delivery, notifications (email/SMS/push)SaaS integration, event-driven service coordination, scheduling

How to Choose

Use SQS to queue work for asynchronous consumers. Standard queues provide at-least-once delivery, so consumers must be idempotent and tolerate duplicates. Use SNS to fan out one event to multiple subscribers at once. Use EventBridge for SaaS partner integration, complex event pattern routing, or scheduled execution. Many architectures combine SNS → SQS fan-out, giving each subscriber its own queue for retry resilience.

Exam Points

  • SAA frequently tests "process an S3 event with multiple Lambdas" → SNS fan-out vs "queue orders for sequential worker processing" → SQS
  • The SNS + SQS fan-out pattern for loose coupling is a recurring architecture question
  • DOP/SAP cover EventBridge scheduling and SaaS integration via partner event sources

Related Service Guides

Last updated: 2026-09-06

This page is created from AWS official documentation and reviewed/edited by the operator. See our editorial & quality policy for details.