Amazon SNS: What It Is and When to Use It

Definition

Amazon Simple Notification Service (Amazon SNS) is AWS's fully managed publish/subscribe (pub/sub) messaging service. A producer publishes a message to a topic; SNS delivers a copy to every subscriber that has signed up for that topic. Subscribers can be AWS services (SQS, Lambda, Kinesis Data Firehose, HTTP/HTTPS endpoints) or directly-addressed destinations (email, SMS, mobile push). SNS is the canonical way to fan out a single event to many consumers on AWS.

How It Works

The core primitives:

• Topic — a named pub/sub channel. Create one per logical event type (e.g., order-placed, invoice-generated).
• Subscription — a consumer endpoint bound to a topic, with an optional filter policy that selects which messages it receives based on message attributes.
• Publish — the producer calls the Publish API with a message and optional attributes. SNS ensures the message reaches every matching subscription.

Delivery is push — SNS calls each subscriber's endpoint directly, unlike SQS which waits to be polled. For durable consumers that may be temporarily unavailable, subscribe an SQS queue to the topic: SNS publishes to the queue, the queue buffers, the downstream service drains at its own pace. This is the SNS → SQS fan-out pattern.

Topic Types

Standard topic

• Nearly unlimited throughput per topic.
• At-least-once delivery — occasional duplicates possible.
• Best-effort ordering.
• Default choice for most pub/sub workloads.

FIFO topic

• Strict ordering within a message group, exactly-once delivery with a 5-minute deduplication window.
• Throughput limit: 300 messages/second per topic (higher with high-throughput mode).
• Can only fan out to SQS FIFO queues.
• Useful when downstream ordering is mandatory end-to-end.

Key Features and Limits

• Supported subscribers: SQS (Standard and FIFO), Lambda, Kinesis Data Firehose, HTTPS, email, email-JSON, SMS, mobile push (APNs, FCM, ADM, Baidu), platform application endpoints.
• Message size: up to 256 KB. With the Extended Client Library, offload to S3 for larger payloads.
• Filter policies: JSON expressions on message attributes or (newer) message body; subscribers only receive messages that match. Keeps consumers simple and costs low.
• Message attributes: structured metadata alongside the body.
• Message retention: none for push delivery (fire-and-forget). Pair with SQS for persistence, or turn on the new message archiving for FIFO topics.
• Dead-letter queues: per-subscription SQS DLQ for undeliverable messages.
• Server-side encryption: with KMS.
• Cross-Region publishing: Publish can reach topics in other Regions.
• Mobile push: abstracts platform-specific APIs for iOS, Android, Fire OS, etc.
• SMS: transactional and promotional messages; rate-limited by destination country.
• Delivery policies: retry schedules, exponential backoff.
• Access control: IAM + optional topic policies for cross-account publishing.

Common Use Cases

1. Fan-out of a single event to many consumers — publish to SNS once; SQS queues, Lambdas, and webhooks all receive it.
2. Application-to-application decoupling — microservices communicate via topics instead of direct calls.
3. Alerting and notifications — CloudWatch Alarms publish to SNS for email/SMS/Slack webhook delivery.
4. Mobile push notifications — one API for iOS, Android, Fire, and Baidu endpoints.
5. SMS notifications — order confirmations, OTP codes, shipment updates.
6. Event bridging — trigger serverless pipelines from S3, DynamoDB Streams, CloudTrail, or SaaS partners.
7. System-wide notifications — fan out deployment or configuration events to every service in the organization.

Pricing Model

SNS bills by the message path:

• Publishes — per million requests. Free Tier includes 1 million/month.
• Deliveries — per million for each delivery channel. Deliveries to SQS and Lambda are cheap; deliveries to HTTPS, email, and SMS are priced higher per destination country/type.
• Data transfer out — standard AWS rates.
• KMS requests — only when SSE-KMS is enabled.
• Mobile push and SMS: billed per notification with country-specific SMS pricing.

FIFO topic requests and deliveries are priced slightly higher than Standard.

Pros and Cons

Pros

• Push delivery — no polling required on your side.
• One-to-many fan-out with a single publish.
• Broad subscriber ecosystem (SQS, Lambda, HTTPS, email, SMS, mobile push).
• Message filtering keeps consumers simple and costs low.
• FIFO topics give ordering and deduplication when needed.

Cons

• No persistence by default — unless you fan out to SQS, an offline consumer misses messages.
• 256 KB message size limit — large payloads need S3 offloading.
• Filtering is powerful but expressed in a specific JSON dialect; complex filters need care.
• Cross-account and cross-Region delivery requires extra policy configuration.
• Higher per-delivery cost for HTTPS/email/SMS vs SQS/Lambda fan-out.

Comparison with Alternatives

| | SNS | SQS | EventBridge | Kinesis Data Streams | | --- | --- | --- | --- | --- | | Pattern | Pub/Sub | Point-to-point queue | Event bus with content-based routing | Ordered durable stream | | Delivery | Push | Pull | Push to rules/targets | Pull from shards | | Retention | None (fire-and-forget) | 1 min – 14 days | Optional archive | 1 – 365 days | | Subscribers/targets | SQS, Lambda, HTTPS, email, SMS, push, Firehose | One consumer group | Many rules, many targets | Many independent consumers | | Filtering | Attribute / body filter policies | N/A (consumer-side filtering) | Rich JSON-pattern rules, 130+ SaaS sources | Consumer-side | | Best for | Simple fan-out | Work queue | Event-driven architectures with many SaaS events | Streaming analytics with replay |

SNS vs EventBridge: EventBridge is a newer service with richer filtering, direct SaaS integrations (Datadog, Shopify, Zendesk, etc.), schema registry, and archive/replay — but it's slightly higher latency and more expensive than SNS. Use SNS for fast, simple fan-out; use EventBridge when you need content filtering across SaaS and AWS events, or schema validation.

Exam Relevance

• Cloud Practitioner (CLF-C02) — know SNS is pub/sub for notifications.
• Solutions Architect Associate (SAA-C03) — SNS + SQS fan-out pattern, filter policies, CloudWatch Alarm → SNS → email, SNS vs SQS vs EventBridge selection.
• Developer Associate (DVA-C02) — FIFO topics + FIFO SQS, message attributes, subscription filter policies, mobile push setup, dead-letter queues.
• DevOps Professional (DOP-C02) — cross-account publishing via resource policies, monitoring dead-letter queues, encryption with KMS.

Classic exam trap: SNS alone is fire-and-forget — an offline subscriber misses messages. For durable delivery, fan out to SQS, which buffers until the consumer is ready.

Frequently Asked Questions

Q: What's the difference between SNS and SQS?

A: SNS is pub/sub — one publisher, many subscribers, push delivery, no persistence. SQS is a queue — one logical consumer (or a consumer group), pull delivery, durable up to 14 days. Use SNS when you want to fan a single event out to many destinations. Use SQS when you want to buffer work for a single consumer group to process at its own rate. Combine both — SNS → SQS fan-out — when you want both pub/sub and durable per-consumer queues.

Q: How do SNS message filter policies work?

A: A filter policy is a JSON expression attached to a subscription that selects which messages reach it based on message attributes or the message body. For example, a subscription to an orders topic might filter { "event_type": ["payment_failed"] } to receive only payment-failure events. Filtering happens inside SNS — non-matching messages are not delivered (and not charged as deliveries), which makes filtering both efficient and cost-effective.

Q: When should I use EventBridge instead of SNS?

A: Use EventBridge when you need content-based routing (filters on the message body, not just attributes), integrations with 130+ SaaS services (Datadog, Shopify, Zendesk, PagerDuty), a schema registry for event validation, or event replay from an archive. Use SNS for simple, high-throughput fan-out where filter policies on attributes are enough and you're only routing to AWS services or HTTPS/email/SMS.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon SNS documentation before making production decisions.