SNS & EventBridge: Fan-Out and Event Routing

In one line

SNS pushes one message to many subscribers at once; EventBridge is an event bus that routes events to targets based on their content — together with SQS they let services react to each other without direct calls.

0/4 · 0%

Think of it like this

SNS is a group announcement over the office PA — everyone subscribed hears the same message instantly. EventBridge is a smart mailroom that reads each letter and forwards it only to the departments whose rules match ('anything about refunds over ₹10,000 goes to Finance and Audit').

Key ideas

01
SNS: publishers send to a TOPIC; SNS delivers a copy to every subscription (SQS queues, Lambda, HTTPS endpoints, email/SMS). SUBSCRIPTION FILTER POLICIES let a subscriber receive only messages whose attributes match.
02
The classic FAN-OUT pattern is SNS → multiple SQS queues: one 'order placed' publish lands in the email service's queue, the inventory service's queue, and the analytics queue. Each consumer processes at its own pace with its own retries and DLQ, and a slow or broken consumer doesn't affect the others.
03
EVENTBRIDGE: producers put events (JSON with source, detail-type, detail) on an EVENT BUS; RULES match on any field in the event with patterns (prefix, numeric ranges, exists) and route to targets (Lambda, SQS, Step Functions, API destinations, other buses/accounts). AWS services publish their own events to the default bus — e.g. EC2 state changes, ECS task stops.
04
EventBridge extras: the SCHEMA REGISTRY, ARCHIVE AND REPLAY (re-send past events after a bug fix), EventBridge SCHEDULER for cron and one-off timed tasks, and PIPES for point-to-point source → filter → enrich → target integrations.
05
Rough guide: SNS for high-throughput, simple fan-out of the same message; EventBridge for routing by content between many producers and consumers, cross-account events, and reacting to AWS service events; always put an SQS queue in front of consumers that need buffering and retries.

Code & diagrams

fan-out.shbash

TOPIC=$(aws sns create-topic --name order-placed --query TopicArn --output text)

# Each downstream service owns its own queue subscribed to the topic
aws sns subscribe --topic-arn $TOPIC --protocol sqs \
  --notification-endpoint arn:aws:sqs:ap-south-1:123456789012:email-orders \
  --attributes RawMessageDelivery=true
aws sns subscribe --topic-arn $TOPIC --protocol sqs \
  --notification-endpoint arn:aws:sqs:ap-south-1:123456789012:inventory-orders \
  --attributes '{"RawMessageDelivery":"true","FilterPolicy":"{\"region\":[\"IN\"]}"}'
# (each queue also needs a queue policy allowing sns.amazonaws.com from this topic)

aws sns publish --topic-arn $TOPIC --message '{"orderId":"789"}' \
  --message-attributes '{"region":{"DataType":"String","StringValue":"IN"}}'

eventbridge-rule.jsonjson

Event pattern: route only large refunds to the audit Lambda.

{
  "source": ["acme.payments"],
  "detail-type": ["RefundIssued"],
  "detail": {
    "amount": [{ "numeric": [">", 10000] }],
    "currency": ["INR"]
  }
}

FanOutdiagram

Rendering diagram…

Explain it without notes

Why put an SQS queue between SNS and each consumer instead of subscribing consumers' HTTP endpoints or Lambdas directly?

When would you choose EventBridge over SNS?

Practice

Write an EventBridge pattern that matches ECS task-stopped events for the api service where the container exited with a non-zero code.

The analytics team wants every past OrderPlaced event re-delivered after they fixed a bug in their loader. How would EventBridge help?

Trade-offs

↔
Event-driven decoupling lets teams add consumers without touching producers, but the flow of a business process becomes implicit — scattered across rules and subscriptions — so you need tracing, event schemas, and documentation to know what happens when an event fires.

Done when you can

I can build SNS → SQS fan-out with filter policies.
I can write EventBridge event patterns including numeric and anything-but matches.
I know when to reach for SNS vs EventBridge vs a plain queue.