AWS offers three messaging services that look similar from a distance but solve distinct problems. SNS pushes notifications to subscribers. SQS queues work for consumers. EventBridge routes events based on their content. Teams that treat them as interchangeable end up fighting their chosen service instead of leveraging its strengths.
The key is understanding what each service optimizes for—and when to combine them.
Three Models, Three Jobs
SNS is pub/sub fan-out. A publisher sends a message to a topic, and SNS delivers it to every subscriber—Lambda functions, SQS queues, HTTP endpoints, email addresses. The publisher doesn’t know or care who’s listening. One message in, many copies out.
SQS is a work queue. Messages land in a queue, consumers pull them out, and processed messages disappear. It’s built for distributing tasks across workers and buffering between services. One message in, one consumer processes it.
EventBridge is an event router with content-based filtering. Events flow onto a bus, rules inspect event content and route matching events to targets. It doesn’t just deliver messages—it understands them. EventBridge decides where events go based on what they contain.
These aren’t competing services. They’re complementary tools that excel in different roles.
SNS: Fan-Out and Notification
SNS topics act as broadcast channels. When a service publishes a message to a topic, SNS pushes that message to all subscribers simultaneously. Subscribers can be Lambda functions, SQS queues, HTTP/S endpoints, SMS numbers, or email addresses.
When Fan-Out Is the Right Pattern
Consider an order service that needs to notify multiple downstream systems when an order is placed. The payment service needs to charge the card. The inventory service needs to reserve stock. The notification service needs to send a confirmation email. SNS handles this naturally: publish once, deliver to all three.
Without SNS, the order service would need to know about every downstream consumer and call each one directly. SNS decouples the publisher from subscribers entirely.
Message Filtering
SNS supports subscription filter policies that let subscribers receive only messages matching specific attributes. An “orders” topic might carry all order events, but a subscriber can filter for only high-value orders or orders from a specific region. This avoids the overhead of creating separate topics for every variation.
Filter policies work on message attributes (key-value metadata), not message bodies. They support exact matching, prefix matching, numeric comparisons, and exists/not-exists checks. Useful, but limited compared to EventBridge’s content-based filtering.
The SNS + SQS Fan-Out Pattern
SNS’s most powerful pattern combines it with SQS. Subscribe multiple SQS queues to a single SNS topic. SNS fans the message out to every queue, and each queue provides independent, reliable consumption for its downstream service.
This gives you the best of both: SNS handles the broadcast, SQS handles the buffering and retry logic. If one consumer falls behind or goes down, its queue accumulates messages while other consumers continue processing normally. It’s the backbone of many event-driven architectures on AWS.
SQS: Reliable Work Distribution
SQS is the simplest of the three. Send a message, a consumer pulls it, the consumer deletes it after processing. If the consumer crashes, the message reappears after a visibility timeout and another consumer picks it up. No messages lost, no infrastructure to manage.
Standard vs FIFO
Standard queues offer virtually unlimited throughput with at-least-once delivery. Messages might arrive out of order or be delivered more than once. For most workloads—background jobs, image processing, webhook delivery—this is fine. Design your consumers to be idempotent and ordering rarely matters.
FIFO queues guarantee strict ordering within message groups and exactly-once processing, but cap at 3,000 messages per second (with batching). Use them when processing order matters and duplicates would cause real problems: financial transactions, sequential workflow steps, inventory updates.
Dead-Letter Queues
When a message fails processing repeatedly, SQS can move it to a dead-letter queue (DLQ) after a configured number of attempts. This prevents poison messages from blocking the queue and gives you a place to inspect and reprocess failures. Every production SQS queue should have a DLQ configured—skipping this is asking for trouble.
Lambda Integration
SQS integrates directly with Lambda as an event source. Lambda polls the queue, scales up based on queue depth, and processes messages in batches. This combination eliminates the need for a dedicated consumer fleet for many workloads. Combined with the SNS fan-out pattern, it enables fully serverless event-driven pipelines.
For a deeper comparison of SQS against streaming alternatives, see our SQS vs Kafka comparison.
EventBridge: Content-Based Event Routing
EventBridge takes a fundamentally different approach. Instead of topics you subscribe to or queues you pull from, EventBridge provides event buses where rules inspect event content and route matching events to targets.
Event Buses and Rules
Every AWS account gets a default event bus that receives events from AWS services—EC2 state changes, S3 operations, CodePipeline executions. You can also create custom event buses for your application events.
Rules define patterns that match against event content. Not just metadata or attributes, but the actual event payload. A rule can match events where source is “orders.service”, detail-type is “OrderPlaced”, and detail.amount is greater than 500. This content-based routing is EventBridge’s defining feature.
Schema Registry and Discovery
EventBridge includes a schema registry that automatically detects and stores the structure of events flowing through your buses. This gives your team a catalog of available events without manually maintaining documentation. Combined with code bindings for TypeScript, Python, and Java, it reduces the friction of consuming events from services you didn’t build.
Cross-Account and Cross-Region
EventBridge supports sending events across AWS accounts and regions natively. An event bus in your production account can forward specific events to a monitoring account, an analytics account, or a disaster recovery region. This cross-boundary routing is difficult to replicate cleanly with SNS or SQS alone.
Third-Party Integrations
EventBridge has partner event sources from services like Stripe, Auth0, Twilio, Zendesk, and dozens more. These SaaS platforms can publish events directly to your EventBridge bus, letting you react to external events—a Stripe payment succeeded, an Auth0 user signed up—using the same routing rules you use for internal events. No webhook endpoints to manage, no custom integration code.
Common Patterns
SNS + SQS for Reliable Fan-Out
Publish to an SNS topic, subscribe multiple SQS queues, attach Lambda functions or worker fleets to each queue. This is the standard pattern for distributing events to multiple independent consumers with guaranteed delivery and independent processing rates.
EventBridge for Cross-Service Routing
Use EventBridge as the central event bus for a microservices architecture. Services publish events to a custom bus. Rules route events to the appropriate consumers based on content. New consumers add new rules without modifying producers. The schema registry helps teams discover available events.
SQS for Task Processing
SQS remains the best choice for pure work distribution: background jobs, async task processing, request buffering during traffic spikes. It does one thing and does it reliably.
Cost Comparison
Pricing differs across the three services, and the right choice can affect your bill significantly at scale.
SNS charges $0.50 per million publishes. Deliveries to SQS and Lambda are free. HTTP/S deliveries cost $0.60 per million. SMS and email have separate, higher pricing.
SQS charges $0.40 per million requests (standard) or $0.50 per million (FIFO). A “request” includes sends, receives, and deletes, and batch operations reduce costs since a batch of up to 10 messages counts as one request.
EventBridge charges $1.00 per million events published to custom event buses. AWS service events on the default bus are free. Rules and target invocations don’t incur additional charges.
For a simple fan-out to three SQS queues processing 10 million messages per month: SNS costs roughly $5 for publishes, plus $12 for SQS operations across the three queues. The same routing through EventBridge costs $10 for event publishing plus the SQS costs. At low volumes the difference is trivial, but at hundreds of millions of events, EventBridge’s higher per-event cost adds up.
However, EventBridge’s content-based filtering can reduce costs downstream by routing only relevant events to each target. If SNS without filtering delivers every event to every subscriber, those subscribers waste compute processing irrelevant messages.
When to Use Each
Choose SNS when:
- You need simple fan-out to multiple subscribers
- Subscribers are diverse (Lambda, SQS, HTTP, email, SMS)
- Message attribute filtering is sufficient for your routing needs
- You want the cheapest option for high-volume broadcast
Choose SQS when:
- You need reliable work distribution to competing consumers
- Buffering between services matters (handling traffic spikes)
- You want exactly-once processing (FIFO) or at-least-once with retries
- The pattern is point-to-point, not broadcast
Choose EventBridge when:
- You need routing based on event content, not just metadata
- Cross-account or cross-region event delivery is required
- You’re integrating with SaaS platforms that support partner event sources
- You want a central event bus with schema discovery for a microservices architecture
- You need event archiving and replay (EventBridge supports this natively)
When to Combine Them
The strongest architectures use these services together.
EventBridge + SQS: EventBridge routes events based on content to SQS queues that buffer work for consumers. You get smart routing and reliable consumption.
SNS + SQS: The classic fan-out pattern. SNS broadcasts, SQS buffers. Each consumer processes at its own pace with independent retry and DLQ handling.
EventBridge + SNS: EventBridge can target SNS topics, useful when you need content-based routing and fan-out to non-EventBridge-supported targets like SMS or email.
All three: An EventBridge rule matches high-priority events and sends them to an SNS topic that fans out to multiple SQS queues for parallel processing by different services. Each layer does what it does best.
The mistake is picking one service for everything. SNS isn’t great as a work queue. SQS can’t fan out or route by content. EventBridge costs more than SNS for simple broadcast at high volume. Let each service play its role.
The Bottom Line
SNS, SQS, and EventBridge aren’t competitors—they’re layers in AWS’s messaging stack. SNS broadcasts messages. SQS reliably queues work. EventBridge intelligently routes events based on what they contain.
Start with SQS if you need a queue. Use SNS when one event needs to reach multiple consumers. Reach for EventBridge when you need content-based routing, cross-account delivery, or SaaS integrations. Combine them when a single service doesn’t cover your pattern. The teams that get messaging right on AWS are the ones that stop looking for one service to rule them all and start composing the right services for each job.