SNS & EventBridge: Pub/Sub and Event Buses
Fanning a single event out to many subscribers with SNS, and routing events between many producers and consumers based on content with EventBridge.
Want a visual for this topic?
Generate a diagram tailored to SNS & EventBridge: Pub/Sub and Event Buses — the AI picks whichever visual (architecture, flowchart, ER diagram, etc.) best fits this specific AWS concept.
Sign in to generate a visual →🎓 Learning objectives
- •Explain the pub/sub pattern and how it differs from a queue
- •Explain SNS fan-out to multiple SQS queues
- •Explain what EventBridge adds beyond SNS — content-based routing and a schema registry
- •Choose between SNS, SQS, and EventBridge for a given integration need
What is it?
Amazon SNS (Simple Notification Service) is a pub/sub messaging service — a publisher sends one message to a Topic, and every current subscriber (which could be SQS queues, Lambda functions, HTTP endpoints, email, or SMS) automatically receives a copy. Amazon EventBridge is a more sophisticated event bus service, purpose-built for routing events from many different sources to many different targets based on the event's actual content, with built-in integrations for both AWS services and third-party SaaS applications.
Why it exists
A queue (SQS) delivers each message to exactly one consumer — great for distributing work, but wrong when multiple independent systems all need to know about the same event (e.g. 'an order was placed' might need to trigger inventory update, send a confirmation email, AND update analytics, all independently). SNS exists to broadcast one event to many interested subscribers at once. EventBridge exists to go further: as an application grows to have many event sources and many possible consumers, EventBridge lets you route events based on their actual content (not just which topic they were published to), decoupling producers from needing to know anything about their consumers at all.
Problem it solves
SNS solves the fan-out problem (one event, many independent subscribers, each getting their own copy without the publisher needing to know who's listening). EventBridge solves the content-based routing problem at scale (many event sources, many potential consumers, with rules determining which events go where based on their actual payload content, not just a fixed topic subscription) and the third-party integration problem (built-in event sources from dozens of SaaS applications without custom integration code).
Intuition
SNS is like a radio broadcast: the station (publisher) sends out one signal, and every tuned-in radio (subscriber) receives the exact same broadcast simultaneously, with no direct relationship between the station and any specific listener. EventBridge is more like a sophisticated mail sorting facility: it looks at the actual content of each piece of mail (the event) and routes it to whichever specific destinations match rules you've defined, potentially very differently for different types of mail passing through the same facility.
Analogy
SNS is a company-wide announcement system — one message goes out, and every department that's subscribed hears it identically. EventBridge is more like a smart office mail room that reads each package's label and routing slip and sends it to exactly the right combination of departments based on what's actually inside and what it's about, not just which single announcement channel it came in on.
Technical explanation
A common and powerful pattern is SNS fan-out to SQS: an SNS topic's subscribers are multiple SQS queues (rather than direct Lambda/HTTP subscribers), combining SNS's fan-out with SQS's durability, retry, and buffering — if one downstream consumer's queue backs up or its consumer is briefly down, the other subscribers' queues are unaffected. EventBridge Rules use an event pattern (a JSON structure matching against parts of the incoming event) to determine which events route to which targets — this content-based filtering is more powerful than SNS's simpler message filtering. EventBridge also provides a Schema Registry that can infer and store the structure of events flowing through it, and comes with pre-built integrations ('partner event sources') for numerous third-party SaaS platforms.
Architecture
An e-commerce platform publishes an 'OrderPlaced' event to an SNS topic, fanned out to three separate SQS queues: one feeding an inventory-update Lambda, one feeding an email-confirmation service, and one feeding an analytics pipeline — each consumer processes independently, and adding a fourth consumer later (e.g. a fraud-detection service) means just adding a new subscription, with zero changes to the original order-placing code. A more complex platform-wide architecture instead uses a central EventBridge bus, where events from many different microservices are published once, and EventBridge Rules route specific event types/content to the appropriate handful of interested consumers among dozens of possible targets, without any producer needing to know who's listening.
Workflow
- For a straightforward one-event-many-subscribers fan-out need, use SNS, typically fanning out to SQS queues for durability. 2) For a more complex system with many event sources and consumers needing content-based routing (not just topic-based), or needing built-in third-party SaaS integrations, use EventBridge. 3) Define EventBridge rules with event patterns matching the specific event shapes/content you want routed to each target. 4) Consider EventBridge's schema registry to formalize and document event shapes as your event-driven architecture grows.
Example
A SaaS company uses EventBridge as their central event bus: their billing service publishes 'SubscriptionCancelled' events, and separate EventBridge rules route these events to a customer-retention Lambda (attempting a win-back offer), an analytics pipeline (via Kinesis), and a Slack notification (via a third-party target) — all three consumers were added independently over time, at different points, without ever modifying the billing service's original event-publishing code.
Real-world usage
SNS fan-out to SQS is one of the most common decoupling patterns in AWS architectures, extensively documented in AWS's own well-architected messaging guidance; EventBridge has become the standard choice for building larger event-driven architectures spanning many microservices and, increasingly, integrating with external SaaS tools directly via its partner event source catalog.
Trade-offs
SNS is simpler to reason about for straightforward one-to-many fan-out, but scales awkwardly (topic sprawl, limited filtering) as the number of distinct event types and routing needs grows. EventBridge handles that complexity better through content-based routing and a single (or few) central event buses, but comes with more upfront conceptual overhead and is arguably overkill for a simple, small fan-out need that SNS would handle just as well with less setup.
Visual explanation
Picture an SNS Topic as a single point with one arrow in (the publisher) and multiple arrows out (each subscriber — an SQS queue, a Lambda function, an email address) — every subscriber gets an identical copy of every message published to that topic, no filtering by content by default (though basic message filtering is supported as an add-on). Picture an EventBridge Event Bus as a more complex hub: many different arrows in (from AWS services, custom applications, and third-party SaaS sources), a set of Rules that inspect each event's actual JSON content, and arrows out to different Targets depending on which rules match — a single event might match multiple rules and fan out to multiple targets, or match none and simply not be routed anywhere.
Advantages
- —
SNS fan-out lets you add new independent subscribers to an event without any change to the publisher's code
- —
EventBridge's content-based routing scales cleanly to many event types and consumers without needing a topic-per-event-type SNS sprawl
- —
EventBridge's built-in SaaS integrations (partner event sources) eliminate custom integration code for many common third-party tools
- —
Both services are fully managed with no infrastructure to provision or scale manually
Disadvantages
- —
SNS's message filtering is simpler than EventBridge's pattern matching, becoming unwieldy for complex content-based routing needs as topic count grows
- —
EventBridge has a real learning curve for writing correct event patterns, and debugging why an event didn't match an expected rule can be non-obvious
- —
Neither service guarantees message ordering by default (EventBridge event buses don't guarantee delivery order across events)
- —
Adding too many EventBridge rules and targets across a large system can make it hard to trace an event's full downstream impact without good documentation/tooling
Common mistakes
- —
Building complex content-based routing logic on top of SNS's simpler filtering (or worse, inside each subscriber) when EventBridge would handle that routing far more cleanly and centrally
- —
Subscribing an SNS topic directly to Lambda/HTTP endpoints for a critical workflow instead of fanning out to SQS first, losing SQS's retry/durability guarantees if the direct subscriber briefly fails
- —
Writing an EventBridge rule's event pattern incorrectly and being confused why events aren't reaching a target — always test event patterns against real sample event payloads
- —
Creating an excessive number of narrow SNS topics (one per very specific event type) instead of using a smaller number of topics or an EventBridge bus with proper content-based filtering
In the AWS Console
- 1
AWS Console → SNS → Topics → Create topic
Choose Standard or FIFO topic type, then add subscriptions (SQS queues, Lambda functions, email, etc.) under the topic's Subscriptions tab.
For durability, prefer fanning out to SQS queues rather than subscribing Lambda/HTTP endpoints directly, especially for workflows where losing a message matters.
- 2
AWS Console → EventBridge → Event buses → Rules → Create rule
Define an event pattern (JSON matching against the source, detail-type, and specific fields within the event's detail) and select one or more targets to route matching events to.
Use the 'Sample events' testing feature in the console to validate your event pattern actually matches real event payloads before relying on it in production.
- 3
EventBridge → Schema registry → Schemas
Browse or search for the schema of AWS service events flowing through your bus, or create a custom schema for your own application's events.
EventBridge can auto-discover and infer schemas from events actually flowing through a bus, useful for documenting an evolving event-driven architecture.
🎤 Interview questions
What's the difference between SQS and SNS in terms of how many consumers receive a message? (Listen for: SQS delivers each message to exactly one consumer (competing consumers pattern); SNS broadcasts to every current subscriber (pub/sub fan-out).)
Why would you fan out an SNS topic to multiple SQS queues instead of subscribing consumers directly? (Listen for: SQS adds durability, retry, and buffering per-consumer, so one consumer's failure or slowness doesn't affect the others or risk message loss.)
What does EventBridge add beyond what SNS provides? (Listen for: content-based routing via event patterns rather than just topic-based subscription, built-in third-party SaaS integrations, and a schema registry.)
How would you decide between SNS and EventBridge for a new event-driven integration? (Listen for: SNS for simple, straightforward one-to-many fan-out; EventBridge for more complex routing needs, many event sources/types, or third-party SaaS integration requirements.)
Describe a real scenario using SNS fan-out to solve a specific problem. (Listen for: a concrete example — e.g. one 'order placed' event triggering multiple independent downstream systems (inventory, email, analytics) without the order service needing to know about any of them.)