Amazon SNS
Fully managed pub/sub messaging for pushing one message to many subscribers at once.
Verified against AWS documentation · 2026-08-24
Key facts
- 01Push, not poll — publisher sends once, SNS delivers to every subscription; publisher never learns who is listening
- 02Standard: near-unlimited throughput, at-least-once, best-effort ordering
- 03FIFO: strict ordering and deduplication by message group; SQS queues only as subscribers
- 04Subscriber protocols: SQS, Lambda, HTTP/S, email, SMS, mobile push, Kinesis Data Firehose
- 05Subscription filter policies match on message attributes or body — filtering happens in SNS, before delivery
- 06No retention or replay on Standard topics: a failed delivery retries, then hits the subscription DLQ or is gone
- 07Limits: 256 KB max message size, 12.5M subscriptions per topic, 100K topics per account (default)
Exam triggers
Phrases and scenarios that point here.
- "Fan out", "notify multiple systems", "one event, several consumers"
- "Push notification", "immediately notify", "without polling" → SNS, not SQS
- Multiple teams need the same event but must process independently → SNS + one SQS queue each
- Alert an operator by email or SMS when a CloudWatch alarm fires → SNS topic
- Subscribers need different subsets of the same stream → one topic + filter policies, not many topics
- Ordering required across a fanout → FIFO topic into FIFO queues
Not this service
- One message consumed by exactly one worker, with retry until processed → SQS
- Rule-based routing from AWS service events, SaaS partners, or a schema registry → EventBridge
- Marketing or transactional email with templates, bounce handling, and deliverability reporting → SES
- Consumers that need to replay history or read at their own pace → Kinesis Data Streams
Use cases
- 01Classic fanout: one `order-placed` topic feeding separate SQS queues for billing, inventory, and analytics — new consumers subscribe without the publisher shipping a single line of code
- 02Operational alerting spine: CloudWatch alarms, Auto Scaling lifecycle events, and Budgets all publish into one topic that fans out to on-call SMS, a team inbox, and an HTTPS webhook into Slack or PagerDuty
- 03Priority routing with filter policies: a single events topic where the paging subscription filters `severity = critical` and the logging subscription takes everything — one publisher, two very different downstream costs
- 04Cross-account event hub: a topic in a shared-services account with a resource policy allowing publishes from workload accounts, so audit and security tooling subscribes once instead of per account
- 05Mobile push at the application layer: publish to a platform endpoint and let SNS handle APNs and FCM delivery rather than maintaining two push integrations
- 06Fanning a strictly ordered stream: FIFO topic into FIFO queues when several consumers each need the same events in the same sequence — inventory adjustments, ledger entries, state machine transitions
How it's charged
- 01Two separate meters: publish requests, and then each delivery — the same message costs different amounts depending on the protocol it fans out to
- 02Deliveries to SQS and Lambda carry no SNS delivery charge, which is why fanout-into-queues is by far the cheapest pattern
- 03SMS is the cost trap: priced per message per destination country and orders of magnitude above other protocols — set an account spend limit before shipping
- 04Email, mobile push, and HTTP/S each bill on their own per-delivery rate, so a topic with many low-value subscribers gets expensive quietly
- 05FIFO topics bill on a separate tier — per publish plus payload data volume — so large ordered messages scale in cost faster than Standard
- 06Filter policies are free and evaluated before delivery, so filtering at the topic is cheaper than delivering everything and discarding downstream
- 07No charge for topics, subscriptions, or idle topics; data transfer out to the internet is billed separately
