Amazon SNS: Pub/Sub at AWS Scale

When a customer placed an order in Diana's app, four things needed to happen: send an email confirmation, alert the warehouse, update the analytics database, and notify customer service if the order was over $1,000. The first version of her code did all four sequentially inside one Lambda. When the warehouse API was slow, every order took 8 seconds. When customer service was down, every order failed.

The fix is the pattern called fan-out — publish the event once, let multiple subscribers handle it independently. AWS's flagship service for this is Amazon Simple Notification Service (SNS).

What SNS Is

SNS is a fully managed pub/sub messaging service. The model:

• A topic is a named channel;
• Publishers send messages to the topic — they do not know or care who's listening;
• Subscribers receive every message published to topics they subscribe to;
• One topic can have multiple subscribers; one publisher can send to many topics. Each subscriber gets its own copy of the message. The publisher and subscribers are decoupled — they do not know about each other.

Subscriber Types

SNS can deliver messages to many destinations:

• Amazon SQS queues — most common pattern for serverless;
• AWS Lambda functions — direct invocation;
• HTTP/HTTPS endpoints — webhooks to anywhere on the internet;
• Email — plain or JSON formatted;
• SMS — text messages, with per-country pricing;
• Mobile push notifications — APNS (Apple), FCM (Google), and others;
• Amazon Data Firehose — for streaming to S3 or analytics services;
• Other AWS accounts — cross-account subscriptions. A single topic can have dozens of subscribers across these types.

Diana's Refactor

Diana split her order Lambda into five:

• One Lambda that publishes the order to an order-placed SNS topic;
• Subscribed: a Lambda that sends the email;
• Subscribed: an SQS queue that the warehouse system polls;
• Subscribed: a Lambda that writes to the analytics database;
• Subscribed: a Lambda that checks for high-value orders and notifies customer service. If the warehouse is slow, only the warehouse queue backs up — orders still complete. If customer service is down, the high-value notification fails — the order still completes. Decoupled.

Message Filtering

SNS supports message filtering — a subscriber can specify a filter policy and only receive messages that match it. Diana's customer-service Lambda filters for amount > 1000, so it only gets invoked for orders above the threshold. Without filtering, every Lambda would receive every message and check the amount itself.

A filter policy is JSON:

{ "amount": [{ "numeric": [">", 1000] }] }

This shifts the filtering from your code to SNS, reducing invocations and cost.

FIFO Topics

By default, SNS topics are standard — messages can be delivered out of order, occasionally more than once. For workflows where order matters, FIFO topics guarantee:

• Strict ordering within a message group;
• Exactly-once delivery (with deduplication ID);
• Throughput limit of 300 messages/second (or 3,000 with batching). FIFO topics can only deliver to FIFO SQS queues. Use them when the receiving system cannot tolerate reordering.

SNS Fan-Out to SQS: The Workhorse Pattern

The most common SNS architecture pairs an SNS topic with multiple SQS queues:

• The topic fans out the message to every queue;
• Each queue is consumed by an independent service;
• If a service is slow or down, its queue absorbs the lag — the publisher and other subscribers do not notice. This combination — SNS for fan-out, SQS for buffering — is the default pattern for asynchronous event processing on AWS.

Dead-Letter Queues

If SNS fails to deliver a message after retries, it can be sent to a dead-letter queue (DLQ) — an SQS queue that catches failed messages for inspection. Without a DLQ, undeliverable messages are silently dropped after the retry policy is exhausted.

Every production SNS subscription should have a DLQ. Otherwise, when something breaks, you do not find out until customers do.

SNS vs SQS vs EventBridge

The three messaging services solve similar-looking problems:

• SNS — push to many subscribers, simple filtering, broad delivery types;
• SQS — buffer messages for one consumer (or a consumer group), durable, polled;
• EventBridge — routing and filtering of complex events, schema registry, integration with many AWS services and SaaS partners. Next chapter dives into EventBridge — the one developers most often confuse with SNS.

For the Exam

DVA-C02 tests these patterns:

• Fan-out with SNS + multiple SQS queues — the most-tested SNS pattern;
• Message filtering policies — when to filter at SNS vs in the consumer;
• FIFO topics — when ordering matters;
• Standard vs FIFO throughput limits.