Amazon SNS

What is Amazon SNS?

Amazon SNS (Simple Notification Service) is AWS’s fully-managed publish/subscribe (pub/sub) messaging service. A publisher sends a message to a topic, and SNS fans it out to all the topic’s subscribers — which can be SQS queues, Lambda functions, HTTP/S endpoints, email, SMS, and more. The defining property is one-to-many: one published message is delivered to every subscriber, each getting its own copy. That makes SNS the natural tool for broadcasting events to multiple independent consumers, sending notifications, and building event-driven fan-out architectures.

Pub/sub vs queue — SNS and SQS are partners, not rivals

The key concept is the contrast with (and complement to) SQS. A queue (SQS) is point-to-point: a message is delivered to and processed by one consumer, then removed — ideal for distributing work. A topic (SNS) is publish/subscribe: a message is delivered to all subscribers — ideal for broadcasting an event that several systems care about. The two combine into the ubiquitous fan-out pattern: a publisher sends an event to an SNS topic, which is subscribed to by multiple SQS queues, so each downstream service gets its own durable copy to process at its own pace. This pairing is powerful because SNS provides the one-to-many distribution while SQS provides the per-consumer durability and buffering — an event published once reliably reaches every interested service, each with its own retryable queue. Using SNS alone (subscribers like Lambda or HTTP get the message pushed directly) works for simple notifications, but the SNS→SQS pattern is preferred when consumers need durability and independent processing, because a raw SNS delivery to an endpoint that’s down can be lost after retries, whereas an SQS queue holds it safely.

Delivery realities and where it fits

SNS delivery characteristics matter: like SQS Standard, standard SNS is at-least-once with best-effort ordering (SNS also offers FIFO topics for ordering/dedup, pairing with FIFO SQS queues), so subscribers should be idempotent. Delivery to endpoints that can fail (HTTP, email) is retried, and undeliverable messages can route to a dead-letter queue. SNS is serverless, scales automatically, and is cheap, which is why it’s a default building block for AWS event-driven systems and application/operational notifications (including alarms from CloudWatch). It contrasts with Kafka/Kinesis (durable replayable streams) and with EventBridge (SNS’s more feature-rich cousin for event routing with content-based filtering and many SaaS integrations) — for sophisticated event routing and filtering, EventBridge is often the better modern choice, while SNS remains the simple, high-throughput fan-out and notification workhorse. The recurring mistakes: using raw SNS delivery where durability is needed (instead of fanning out to SQS), assuming strict ordering on standard topics, and not making subscribers idempotent.

What people get wrong

• Raw SNS delivery where durability matters — an endpoint that’s down can lose the message after retries; fan out to SQS queues so each consumer has a durable copy.
• Assuming ordering: standard topics are best-effort ordered and at-least-once — use FIFO topics for ordering/dedup, and make subscribers idempotent regardless.
• Reaching for SNS when EventBridge fits — for content-based filtering, complex routing, and SaaS event integrations, EventBridge is often the better modern tool.

Primary source: Amazon SNS documentation