SNS vs SQS vs EventBridge — Overview
AWS offers three core messaging/eventing services that are often confused. Each serves a distinct purpose: SQS for queuing (point-to-point buffering), SNS for pub/sub (fan-out notifications), and EventBridge for event routing (content-based filtering from many sources). Choosing the right one — or combining them — is a frequent SAP-C02 and DOP-C02 exam question.
Feature Comparison
| Feature | SQS | SNS | EventBridge |
|---|---|---|---|
| Model | Queue (pull) | Pub/Sub (push) | Event bus (push) |
| Consumers | 1 consumer per message | Multiple subscribers | Multiple targets per rule |
| Filtering | None (consumer gets all) | Message attributes only | Any field in event body (content-based) |
| Ordering | FIFO queues (per message group) | FIFO topics | Not guaranteed |
| Deduplication | FIFO (5-min window) | FIFO topics | Not built-in |
| Retry/DLQ | Built-in (visibility timeout + DLQ) | DLQ per subscription | DLQ + retry policy per target |
| Persistence | Up to 14 days | No persistence (deliver or lose) | Archive (indefinite) + replay |
| Max message size | 256 KB (extended: 2 GB via S3) | 256 KB | 256 KB |
| Throughput | Unlimited (Standard) / 3K-70K msg/s (FIFO) | Virtually unlimited | 2,400 PutEvents/s (soft limit) |
| AWS sources | Limited (must send explicitly) | Some (S3, CloudWatch) | 35+ native sources + SaaS partners |
| Cross-account | Queue policy | Topic policy | Cross-account event bus + rules |
Decision Guide — When to Use Which
| Requirement | Choose | Why |
|---|---|---|
| Buffer messages between producer and consumer | SQS | Queue absorbs spikes, consumer processes at own pace |
| One event must trigger multiple independent consumers | SNS (or SNS+SQS) | Fan-out to many subscribers simultaneously |
| Route different events to different targets by content | EventBridge | Content-based rules filter on any field |
| React to AWS service events (EC2 state change, S3 upload) | EventBridge | Native integration with 35+ AWS services |
| Exactly-once processing with strict ordering | SQS FIFO | Message groups + deduplication IDs |
| Send notifications (email, SMS, HTTP) | SNS | Multi-protocol delivery (email, SMS, HTTP, mobile push) |
| Replay past events after fixing a bug | EventBridge | Archive + replay feature (SNS/SQS don’t have this) |
| Integrate with SaaS (Shopify, Zendesk, Stripe) | EventBridge | Partner event sources built-in |
| Fan-out + buffering per consumer (reliable) | SNS + SQS | SNS fans out, each SQS queue gives independent retry/DLQ |
Common Architecture Patterns
Pattern 1: SNS + SQS Fan-out (Most Common)
One event → multiple independent processors, each with their own retry and failure handling.
- Flow: Order Service → SNS Topic → SQS-Inventory + SQS-Email + SQS-Analytics (each with Lambda consumer)
- Why not just SNS → Lambda directly? SQS adds buffering, retry with backoff, DLQ, and prevents Lambda throttling from affecting other consumers.
Pattern 2: EventBridge + SNS + SQS (Full Decoupling)
Many producers → EventBridge routes by type → SNS fans out → SQS buffers each consumer.
- Flow: 10 microservices emit events → EventBridge (rules filter by event type) → SNS per domain → SQS per consumer
- Why: Producers don’t know about consumers. New consumers subscribe without changing producers.
Pattern 3: SQS as Lambda Buffer (Load Leveling)
Protect downstream from traffic spikes.
- Flow: API Gateway → SQS → Lambda (controlled concurrency)
- Why: API Gateway has unlimited throughput but Lambda has concurrency limits. SQS absorbs spikes and Lambda processes at a controlled rate.
Pattern 4: EventBridge for AWS Service Events
React to infrastructure changes automatically.
- Flow: EC2 instance terminates → EventBridge rule → Lambda (cleanup DNS/LB) + SNS (alert ops team)
- Why: EventBridge receives AWS service events natively without any configuration on the source side.
Pricing Comparison
| Service | Pricing Model | Approximate Cost |
|---|---|---|
| SQS Standard | Per request (send/receive/delete) | $0.40 per million requests (first 1M free) |
| SQS FIFO | Per request | $0.50 per million requests |
| SNS | Per publish + per delivery | $0.50 per million publishes + delivery cost varies by protocol |
| EventBridge | Per event published | $1.00 per million events (custom). AWS service events are free. |
Cost tip: AWS service events on EventBridge (EC2 state changes, S3 events via EventBridge, etc.) are FREE. Only custom/partner events incur the $1/M charge.
Exam Tips
| Exam | Key Points |
|---|---|
| SAP-C02 | “Decouple” → SQS. “Fan-out” → SNS. “Route by content” → EventBridge. “React to AWS events” → EventBridge. SNS+SQS for reliable fan-out with independent retry per consumer. |
| DOP-C02 | DLQ configuration (SQS maxReceiveCount), EventBridge archive for recovery, Lambda event source mappings (SQS batch size, concurrency), monitoring failed deliveries. |
AWS Certification Exam Practice Questions
Question 1:
An order processing system needs to trigger three downstream services (inventory, billing, shipping) independently. If billing fails, inventory and shipping should still succeed. Each service needs its own retry logic. Which architecture is BEST?
- SNS topic → 3 Lambda subscribers directly
- SNS topic → 3 SQS queues (each with own Lambda consumer and DLQ)
- EventBridge → 3 Lambda targets on one rule
- SQS queue → Lambda → calls 3 services sequentially
Show Answer
Answer: B — SNS+SQS fan-out provides complete independence. Each SQS queue has its own visibility timeout, retry policy, and DLQ. If billing Lambda fails 3 times, that message goes to billing’s DLQ while inventory and shipping process normally. Direct SNS→Lambda risks throttling affecting all subscribers, and has no persistent retry mechanism.
Question 2:
A company receives events from 15 microservices. They need to route “payment” events to the payment processor, “inventory” events to the warehouse system, and “audit” events to the compliance system — based on an “event_type” field in the JSON body. Which service provides this content-based routing?
- SNS with message attribute filter policies
- SQS with multiple queues and client-side routing
- EventBridge with rules filtering on event body content
- Kinesis with partition key-based routing
Show Answer
Answer: C — EventBridge rules can filter on any field within the event JSON body (content-based routing). A rule can match {“detail”: {“event_type”: [“payment”]}} and route only payment events to the payment processor target. SNS filter policies only work on message attributes (metadata), not the message body content.
Question 3:
A bug in a consumer caused it to silently discard events for 6 hours before being discovered. The events were published to SNS. Can they be recovered?
- Yes — replay from SNS message retention
- Yes — if the SQS subscriber had a DLQ configured
- No — SNS does not persist messages; once delivered they are gone
- Yes — retrieve from CloudWatch Logs
Show Answer
Answer: C — SNS is fire-and-forget; it doesn’t retain messages after delivery attempts. If the consumer discarded them (successfully received but didn’t process), they’re lost. This is why EventBridge Archive is valuable — it stores events for replay. For SNS-based systems, use SNS→SQS (messages persist up to 14 days in the queue) rather than SNS→Lambda directly.
Question 4:
A company wants to trigger a Lambda function when ANY EC2 instance in their account changes state (running, stopped, terminated). They want this with zero custom code on the producer side. Which approach works?
- CloudWatch Events (same as EventBridge) rule for EC2 state change → Lambda target
- SNS topic that EC2 publishes to on state change → Lambda subscription
- SQS queue polled by Lambda checking EC2 DescribeInstances
- CloudTrail log with S3 event notification triggering Lambda
Show Answer
Answer: A — EventBridge (successor to CloudWatch Events) natively receives EC2 state change events without any configuration on the EC2 side. You simply create a rule matching {“source”: [“aws.ec2”], “detail-type”: [“EC2 Instance State-change Notification”]} → Lambda target. Zero custom code, no producer changes needed. This is EventBridge’s core advantage — native AWS service integration.
Question 5:
A team uses SNS to fan out order events to 5 subscribers. One subscriber (analytics) only needs “premium” orders (order_value > $100). Currently it receives ALL orders and filters client-side, wasting Lambda invocations. How should they reduce unnecessary invocations?
- Create a separate SNS topic for premium orders
- Add an SNS subscription filter policy matching the “order_tier” message attribute = “premium”
- Replace SNS with EventBridge and use content-based filtering on order_value
- Add a Lambda@Edge function to filter before delivery
Show Answer
Answer: B — SNS subscription filter policies allow each subscriber to receive only messages matching specific message attributes. Set the “order_tier” attribute when publishing, and the analytics subscription filter policy matches only “premium”. Non-matching messages are not delivered to that subscriber. This is the simplest solution with no architecture change. EventBridge would also work but is a larger change for a single filter need.
Related Architecture Patterns
Related Posts
- SQS Standard vs FIFO Queue – Complete Comparison
- AWS Event-Driven Serverless Architecture
- Lambda vs Step Functions vs EventBridge
- Kinesis Streams vs Firehose vs Managed Flink
- GenAI Application Architecture
References
- Choosing Between Messaging Services for Serverless — AWS Blog
- Let’s Architect: Event-Driven Architectures — AWS Blog
- Amazon EventBridge User Guide
- Building Event-Driven Applications with EventBridge — AWS Blog
- Filtering Messages with Amazon SNS — AWS Blog
Frequently Asked Questions
When should I use EventBridge vs SNS?
Use EventBridge when you need content-based filtering on the event body, integration with AWS service events or SaaS partners, schema discovery, or event replay. Use SNS for simple fan-out where attribute-based filtering is sufficient, multi-protocol delivery (email, SMS), or when you need FIFO ordering with topics.
Can I use SQS without SNS?
Yes. Use SQS alone when you have a single producer and single consumer (point-to-point). The producer sends directly to the queue, and one consumer processes messages. Add SNS in front only when you need the same message delivered to multiple independent consumers (fan-out).
What happens if an SNS subscriber is down?
For Lambda/HTTP subscribers: SNS retries with backoff (up to 23 days for HTTP). For SQS subscribers: messages are delivered to the SQS queue immediately (SQS is always “up”) and wait until the consumer processes them. This is why SNS→SQS is more reliable than SNS→Lambda directly — SQS persists messages even if the consumer is temporarily unavailable.