Service 51

Amazon SNS

IntegrationPub/SubAsync

Amazon SNS (Simple Notification Service) is managed pub/sub. Producers publish to a topic; SNS fans the message out to every subscriber — email, SMS, mobile push, HTTP/HTTPS endpoints, Lambda, SQS queues, or Firehose. The producer publishes once; SNS delivers many times in parallel, without the producer knowing the subscriber list.

Launched alongside SQS in 2010, the two are siblings: SNS for fan-out, SQS for durable per-consumer buffering.

Standard vs FIFO and Subscribers

Standard topics give at-least-once delivery and unlimited throughput; FIFO topics give strict per-group ordering and exactly-once publishing within a dedup window, at lower throughput. A FIFO topic delivers only to SQS queues — a FIFO queue to carry ordering end to end, or a standard queue where strict ordering past the topic is not needed (it cannot deliver to HTTP/S, email, SMS, push, or Lambda directly).

Subscribers cover email (one message per email), SMS (billed per message, varying by country), mobile push (APNs, FCM), HTTP/HTTPS, Lambda, SQS, and Firehose. SNS handles per-platform credential plumbing for push.

Message Filtering and the Fan-Out Pattern

A subscription filter policy matches message attributes (or body, if enabled) so each subscriber gets only the messages it cares about — cutting both cost and complexity versus every subscriber receiving everything and discarding most.

SNS + SQS Fan-Out — One Publish, Many Durable Consumers

subscriber Aconsumer

subscriber Bconsumer

subscriber Cconsumer

SNS delivers the message to every subscribed queue in parallel; each consumer scales, fails, and retries independently with its own durable buffer. Filter policies limit what each subscriber receives.

The canonical SNS + SQS fan-out pattern subscribes several SQS queues to one topic: publishers send one message, SNS fans it to each queue, and each consumer scales, fails, and retries independently with its own durable buffer — better than direct service-to-service calls.

SNS vs SQS vs EventBridge

SNS — fan-out — one message to many subscribers, including email, SMS, and push.

SQS — durable buffering for a single consumer group; often subscribed to an SNS topic.

EventBridge — content-based routing of AWS-native events with richer rules than SNS filtering.

Common Mistakes

Sending high-volume SMS through SNS without checking per-country rates, where SMS fees can dwarf the rest of the bill.
Skipping subscription filter policies, so every subscriber receives every message and must discard most.
Omitting dead-letter queues on SNS subscriptions, losing failed deliveries.
Subscribing a standard SQS queue to a FIFO topic and still expecting strict end-to-end ordering — the standard queue does not preserve it; use a FIFO queue when ordering must survive the topic.
Using SNS for content-based routing across many AWS services where EventBridge's rules fit better.
Calling services directly instead of using SNS + SQS fan-out, coupling producer and consumers tightly.

Best Practices

Use SNS + SQS fan-out so publishers do not depend on subscribers and each consumer gets a durable queue.
Use filter policies to limit what each subscriber receives.
Put dead-letter queues on SNS subscriptions.
For high-volume SMS, evaluate mobile push or a dedicated SMS provider.
For end-to-end ordering, pair an SNS FIFO topic with SQS FIFO queues.
Monitor NumberOfNotificationsFailed for broken subscribers.

Comparable services GCP Pub/SubAzure Event Grid, Notification Hubs

Knowledge Check

What is the core model of SNS?

Publish once to a topic; SNS fans the message out to every subscriber in parallel
Consumers poll a queue and pull pending messages one at a time
A single producer sends to exactly one consumer and blocks waiting for it synchronously
Events match content-based rules and route to targets

What is the SNS + SQS fan-out pattern?

Several SQS queues subscribe to one topic, giving each consumer its own durable buffer
One SQS queue publishes upstream into many SNS topics
SNS replaces SQS entirely and durably buffers all the messages for each consumer by itself
SNS calls each consumer's API synchronously and waits

What does an SNS subscription filter policy do?

Delivers to a subscriber only the messages whose attributes or body match
Encrypts the messages at rest for that one subscriber
Guarantees strict in-order delivery of every single message to that one subscriber
Converts the message into an email-formatted payload

What is the surprising cost line in SNS?

SMS — per-message fees vary by country and can dwarf the rest of the bill at volume
Lambda invocations that SNS triggers for every published message across all subscribers
Per-gigabyte topic storage charged on retained messages held for later redelivery
Filter policy evaluation billed on every delivery attempt across every subscription

You got correct