A team composing managed backend services needs to fan out an 'order placed' event to a handful of consumers today, but expects new consumer teams to keep adding themselves over the next year. They're choosing between publishing to an Amazon SNS topic versus an Amazon EventBridge event bus. What's the actual difference in how each routes events to consumers, and which fits the team's stated growth pattern better?

## The axis the choice turns on Both SNS and EventBridge solve the same underlying problem — **decouple a publisher from its consumers** — but they differ in where routing decisions live and how well they scale to an unpredictable number of future consumers, which is exactly the axis this team's question turns on. | | SNS | EventBridge | |---|---|---| | where routing lives | per-subscription filter policy, on message attributes | rules defined declaratively on the bus, matching on event content | | adding a consumer | subscribing everyone to everything, with each new subscriber writing its own attribute filter, or spinning up parallel topics per interest area — its own coordination burden | a new rule against the existing bus, with no change to the publisher and no coordination needed with existing rules | | latency and cost | lower and more predictable latency, cheaper per message at high volume | slightly higher per-event cost, one more layer of indirection | | common failure | a filter policy typo that silently drops all messages | overlapping rules causing over-delivery | ## How SNS routes SNS (Simple Notification Service) is a **topic-based pub/sub primitive**: a publisher sends a message to a named topic, and SNS delivers a copy of that message to every current subscription on that topic — an SQS queue, a Lambda function, an HTTP/S endpoint, an email address, or a mobile push endpoint. The routing decision is essentially binary at the topic level ('is this subscriber on this topic or not'), with an optional filter-policy feature that lets a subscriber declare 'only send me messages where this attribute equals that value,' but that filtering logic is attached per-subscription and only inspects message attributes, not the full JSON body, and doesn't provide a shared, centrally-visible rule set — every subscriber writes and owns its own filter, and there's no single place to see 'who receives what and why' across the whole system as it grows. ## How EventBridge routes EventBridge inverts where that logic lives. Publishers put structured events onto an **event bus**, each tagged with a source and detail-type plus an arbitrary JSON detail payload. Separately, one or more rules are defined declaratively against the bus — 'match any event where source is `orders-service` and detail-type is `OrderPlaced` and `detail.total > 100`' — and each matching rule fans out to its own target (a Lambda, an SQS queue, a Step Functions workflow, another event bus, or dozens of native AWS service integrations and increasingly third-party SaaS destinations). Crucially, a new consumer is added by writing a new rule against the existing bus — the publisher genuinely never needs to know how many consumers exist or what they care about. ## Why the distinction exists Why this distinction exists: SNS was designed first, for the simpler and extremely common case of 'I have a known, relatively small set of interested parties for this stream of notifications,' where the operational simplicity of 'subscribe to the topic, done' outweighs the value of centralized routing logic. EventBridge was built later specifically to solve the fan-out-to-an-unbounded-and-growing-set-of-consumers-with-different-interests problem that emerges as systems and organizations scale — the exact scenario in this question, where new teams keep showing up wanting a slice of the same event stream, often filtered on rich content rather than a single attribute. ## The trade-offs run both ways The trade-offs run both ways, though. - SNS delivers with lower and more predictable latency and a simpler mental model — for a small, stable set of subscribers, particularly when fanning out reliably to SQS queues (the well-known 'SNS fan-out to SQS' pattern, where each queue gives a consumer its own durable, independently-scaled buffer with retry/DLQ semantics), SNS is the more battle-tested, lower-overhead choice, and it's cheaper per message at high volume. - EventBridge's richer rule matching and larger integration surface come at the cost of a mental model with one more layer of indirection (bus to rules to targets, versus topic to subscriptions directly), slightly higher per-event cost, and rules that can silently overlap or duplicate delivery if not managed carefully as the number of rules grows into the dozens — the exact same team-scaling scenario that makes EventBridge attractive can also make its rule set sprawl into something nobody fully understands without tooling to visualize it. ## Failure modes Failure modes differ correspondingly. - In SNS, a common production issue is a subscriber-side filter policy typo that silently drops all messages for that subscriber (SNS treats a message as 'not a match' and doesn't deliver it, with no error raised anywhere the subscriber would notice) — this shows up as 'we're just not getting any events' with the publisher looking completely healthy. - In EventBridge, a common issue is two overlapping rules both matching the same event and firing the same downstream target twice, or a rule that's too broad (missing a detail-type filter) matching events it was never meant to catch, causing over-delivery to a consumer that isn't built to handle unrelated event types. ## Which one fits this team Given the team's stated trajectory — new consumer teams continuing to attach themselves over the next year, each presumably interested in different slices of the order-event stream — EventBridge is the better structural fit, since it lets that growth happen by adding rules without ever touching the publisher or coordinating with existing consumers, whereas SNS would require either subscribing everyone to everything (with each new subscriber writing its own attribute filter, and no central visibility into who's listening for what) or spinning up parallel topics per interest area, which becomes its own coordination burden.