Day 3: SNS Fan-Out

Phase 5 · Aug 14, 2026

Agenda (2–3 hours)

• Read (45 min): AWS SNS Developer Guide: topics, subscriptions, filter policies, FIFO SNS
• Study (45 min): Design an SNS → SQS fan-out for an order event: what filter policies would you apply to route different event types to different consumer queues?
• Practice (45 min): Create an SNS topic with three SQS subscriptions, each with a different filter policy; publish 50 messages with different types; verify correct routing
• Challenge (30 min): What is the SNS → SQS fan-out pattern? Why can't you subscribe two Lambda functions to the same SQS queue for fan-out?

SNS Architecture

SNS is a pub/sub service: one message → many subscribers.

Supported subscription protocols:

• SQS: messages queued for async processing
• Lambda: function invoked synchronously
• HTTP/HTTPS: webhook delivery
• Email/SMS: human notification

SNS → SQS Fan-Out Pattern

[OrderPlaced event] → SNS Topic
                           ├── SQS Queue (payments team)
                           ├── SQS Queue (inventory team)
                           ├── SQS Queue (analytics)
                           └── Lambda (real-time notification)

Each consumer gets its own queue → independent processing speed, DLQ, and retry policy.

SQS must grant SNS permission to send messages:

{
  "Effect": "Allow",
  "Principal": { "Service": "sns.amazonaws.com" },
  "Action": "sqs:SendMessage",
  "Condition": { "ArnEquals": { "aws:SourceArn": "arn:aws:sns:...topic-arn" } }
}

Filter Policies

Subscriptions can filter on message attributes — only matching messages are delivered:

// Publisher sets message attributes
sns.publish()
    .topic_arn(topic_arn)
    .message(body)
    .message_attributes("event_type", MessageAttributeValue::builder()
        .data_type("String")
        .string_value("OrderShipped")
        .build().unwrap())
    .send().await?;

// Subscription filter (only receive OrderShipped events)
{
  "event_type": ["OrderShipped", "OrderDelivered"]
}

Each subscriber sees only messages matching its filter — reduces SQS traffic by up to 99%.

FIFO SNS

SNS FIFO topics (connected to SQS FIFO queues) preserve message ordering:

FIFO SNS Topic → FIFO SQS Queue A (payments)
              → FIFO SQS Queue B (inventory)

• Same ordering guarantees as FIFO SQS
• Deduplication IDs prevent duplicate delivery
• Use when downstream consumers require strict ordering

Key Takeaways

• SNS fan-out: one publish → multiple SQS queues/Lambdas independently consume
• Filter policies reduce unnecessary message delivery — apply them for event type routing
• SNS → SQS is the standard fan-out pattern; each consumer gets its own queue with independent DLQ
• FIFO SNS → FIFO SQS when ordering is required across fan-out subscribers

Tomorrow: EventBridge — event routing with rules and targets.