AWS Services
Amazon SNS
Understand Amazon SNS as managed pub-sub messaging, including topics, subscriptions, fanout, filtering, delivery protocols, and SAA-C03 notification patterns.
After this, you will understand
SNS makes event fanout concrete: one publish can notify many independent subscribers without coupling them to the publisher.
SNS is a managed pub-sub service where publishers send messages to topics and subscribers receive copies.
Learners use SNS like a durable work queue or use SQS when the requirement is broadcast to multiple subscribers.
Use SNS when one event should be pushed to multiple subscribers, and combine it with SQS when each subscriber needs durable buffering.
Think before readingWhy pair SNS with SQS instead of subscribing workers directly to SNS?
Reading in progress
This page is saved in your local study history so you can continue later.
Concepts Covered
- Publish/subscribe messaging
- Topics
- Subscriptions
- Fanout
- Push delivery
- SNS to SQS
- SNS to Lambda
- Subscription filter policies
- Mobile, SMS, and email notifications
- SNS versus SQS
1. Plain-English Mental Model
Amazon Simple Notification Service, or SNS, is managed publish/subscribe messaging.
A publisher sends a message to a topic. SNS delivers a copy of that message to each matching subscription.
The simple model is:
publisher -> SNS topic -> many subscribers
Subscribers can be SQS queues, Lambda functions, HTTP/S endpoints, email addresses, SMS, mobile push endpoints, and other supported protocols.
SNS is about fanout and notification. SQS is about durable queue processing. They are often used together because fanout and durable buffering solve different parts of the messaging problem.
2. Why This Service Exists
Many systems need to tell multiple downstream systems that something happened.
An order is placed. Billing needs to charge the customer. Inventory needs to reserve stock. Email needs to send a receipt. Analytics needs to record the event. Fraud detection needs a copy.
Without pub/sub, the order service calls each downstream service directly:
order service -> billing
order service -> inventory
order service -> email
order service -> analytics
That tightly couples the producer to every consumer.
SNS exists so the producer can publish once and let subscribers receive copies independently.
For SAA-C03, SNS appears in questions about fanout, notifications, pub/sub, SMS/email/mobile push, sending one message to multiple SQS queues, message filtering, and event-driven serverless architectures.
3. The Naive Approach And Where It Breaks
The naive design is direct synchronous notification:
service A -> service B
service A -> service C
service A -> service D
If one subscriber fails, the publisher must handle it. Adding a new subscriber means changing the publisher. Traffic spikes create tight coupling.
Another mistake is using SNS when a single worker pool should process each job once. SNS broadcasts to subscribers. If three Lambda functions subscribe to the topic, all three may receive the message. For work queues, SQS is often the right primitive.
Another mistake is subscribing Lambda directly when the subscriber needs durable buffering and controlled retries. An SQS queue between SNS and the worker gives that subscriber its own backlog and DLQ.
SNS is not a database, queue, or workflow engine. It is pub/sub delivery.
4. Core Primitives
A topic is the named channel that publishers send messages to.
A subscription connects a topic to an endpoint, such as SQS, Lambda, HTTP/S, email, SMS, or mobile push.
Fanout means one published message can be delivered to multiple subscriptions.
Message attributes are metadata attached to messages. Subscription filter policies can use attributes or message body filtering to decide which subscribers receive which messages.
Delivery policies and retry behavior depend on protocol.
FIFO topics support ordered and deduplicated fanout for compatible subscribers, commonly paired with FIFO SQS queues.
Access policies control who can publish or subscribe.
5. Architecture Use Cases
Use SNS when one event should notify many systems.
A common fanout architecture:
order service -> SNS topic
-> billing SQS queue
-> email SQS queue
-> analytics SQS queue
Each subscriber gets its own queue, scaling, retry, and DLQ behavior.
Use SNS to send operational notifications from CloudWatch alarms to email, SMS, chat integrations, or incident systems.
Use SNS to invoke Lambda functions for event-driven processing when durable queue buffering is not required.
Use subscription filters when not every subscriber needs every message.
Use mobile push or SMS when the requirement is user-facing notification delivery, but understand regional, quota, and compliance considerations.
7. Security Model
SNS access is controlled by IAM and topic policies.
Publishers need permission to publish to the topic. Subscribers need permission to subscribe or receive depending on protocol and configuration.
Topic policies can allow cross-account publishing or subscription patterns.
When SNS delivers to SQS, the SQS queue policy must allow the SNS topic to send messages.
Encryption at rest can use KMS. If customer-managed keys are used, key policy must allow SNS and required principals.
Do not publish secrets or sensitive data to broad topics unless every subscriber is authorized to receive it. Pub/sub can spread data quickly.
8. Reliability And Resilience
SNS is managed and highly available, but subscriber reliability varies by protocol.
SQS subscriptions are a strong pattern because each subscriber gets durable buffering, retries, and a dead-letter queue.
Lambda subscriptions can retry according to asynchronous invocation behavior, but they do not give each subscriber a queue backlog unless you add SQS.
HTTP/S endpoints need reachable and reliable endpoints. Delivery policies and retries matter.
Use DLQs or delivery status logging where supported for failed deliveries.
For FIFO patterns, use FIFO topics and FIFO queues when ordering matters.
9. Performance And Scaling
SNS scales pub/sub delivery for high-throughput event fanout.
Subscription filtering reduces unnecessary downstream processing by sending only relevant messages to each subscriber.
Fanout can multiply downstream load. One publish to ten subscribers creates ten deliveries.
SQS subscriptions help absorb spikes per consumer. Each consumer can scale independently based on queue depth.
Message size limits and payload design matter. Large payloads may need S3 object references rather than embedding all data in the message.
10. Cost Model
SNS cost includes publish requests, deliveries, data transfer, SMS/mobile push costs, filtering, and related service usage.
Fanout multiplies delivery costs and downstream processing.
Using SNS plus SQS adds SQS request and storage costs, but it improves durability and isolation.
SMS and mobile push have different pricing and operational concerns from application-to-application messaging.
Filtering can reduce cost by avoiding unnecessary subscriber invocations or queue messages.
12. SAA-C03 Exam Signals
"Fan out one message to multiple subscribers" points to SNS.
"Send one event to multiple SQS queues" points to SNS topic with SQS subscriptions.
"Notify users by email or SMS" points to SNS.
"Filter messages per subscriber" points to SNS subscription filter policies.
"Durable task queue for workers" points to SQS, not SNS alone.
"Trigger Lambda from a published event" can point to SNS subscription to Lambda.
"Each subscriber needs its own retry and backlog" points to SNS plus SQS.
13. Common Exam Traps
Do not use SNS as a single-consumer work queue.
Do not assume SNS stores messages until consumers are ready like SQS does.
Do not forget queue policies when subscribing SQS to SNS.
Do not send sensitive messages to a broad topic without subscriber authorization.
Do not forget that fanout multiplies downstream work.
Do not use subscription filters as a replacement for proper authorization.
15. Related Topics
Review Amazon SQS, AWS Lambda, and Amazon CloudWatch.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.