This chapter covers Amazon Simple Notification Service (SNS), a fully managed pub/sub messaging service that enables you to decouple microservices, distributed systems, and serverless applications. For the CLF-C02 exam, this falls under Domain 3: Cloud Technology Services, Objective 3.5 (Identify AWS services for application integration and messaging). This objective typically appears in about 5-8% of exam questions. Understanding SNS is crucial because it is a core building block for event-driven architectures and is often compared with Amazon SQS and Amazon EventBridge on the exam.
Jump to a section
Imagine you are the CEO of a large company and need to announce a new policy to all employees. You could walk to each desk and tell them one by one — that's point-to-point communication, like a direct API call. But with thousands of employees, that's inefficient. Instead, you use the company's public address system. You speak into a microphone (the publisher), the audio goes to an amplifier and then to speakers in every room (the subscribers). The key mechanism: you don't need to know who is listening or where they are. The system broadcasts the message to all speakers that are tuned to the same channel. If a new speaker is installed later, it will receive future announcements. Similarly, Amazon SNS is a pub/sub messaging service. A publisher sends a message to an SNS topic (the channel). The topic immediately pushes copies of that message to all subscribed endpoints (like email, SMS, Lambda functions, SQS queues, HTTP endpoints). The publisher doesn't manage subscribers; SNS handles fan-out. This decouples the sender from the receivers, allowing asynchronous, reliable communication. Just as the PA system can have multiple channels (one for emergencies, one for general announcements), SNS topics can be created for different message types. And if a speaker is broken, the system doesn't stop — it delivers to working speakers. SNS similarly retries delivery and can route dead letters to a DLQ.
What is Amazon SNS and the Problem It Solves
Amazon Simple Notification Service (SNS) is a fully managed messaging service for application-to-application (A2A) and application-to-person (A2P) communication. The fundamental problem SNS solves is the need to broadcast messages to multiple recipients or systems simultaneously without the sender having to manage the list of receivers or the delivery mechanism. In traditional point-to-point integration, if you have one producer and ten consumers, the producer must know about each consumer, send ten separate messages, and handle failures for each. This creates tight coupling and makes scaling difficult. SNS introduces a publish/subscribe (pub/sub) pattern where the producer sends a single message to a topic, and SNS automatically delivers copies to all subscribed endpoints.
How SNS Works – The Mechanism
SNS operates around three core components: publishers, topics, and subscribers.
Publishers: Any entity that sends messages to an SNS topic. This could be an AWS service (like CloudWatch alarms, S3 event notifications), an application running on EC2, a Lambda function, or an on-premises system using the AWS SDK.
Topics: An SNS topic is a logical communication channel. Each topic has a unique Amazon Resource Name (ARN), e.g., arn:aws:sns:us-east-1:123456789012:MyTopic. Publishers send messages to a topic ARN. Topics support message filtering, allowing subscribers to receive only messages that match their filter policy.
Subscribers: Endpoints that register to receive messages from a topic. Supported subscriber types include: HTTP/HTTPS endpoints, email (JSON or plain text), SMS (text messages to mobile devices), Amazon SQS queues, AWS Lambda functions, Amazon Kinesis Data Firehose, and platform application endpoints for mobile push notifications (e.g., Apple Push Notification Service, Firebase Cloud Messaging).
When a publisher sends a message to a topic, SNS immediately attempts to deliver the message to every subscriber. For HTTP/HTTPS endpoints, SNS sends an HTTP POST request with the message body. For email, it sends an email. For Lambda, it invokes the function asynchronously. For SQS, it pushes the message into the queue. The message payload can be up to 256 KB in size. If delivery fails, SNS retries according to a configurable retry policy (linear or exponential backoff). After exhausting retries, messages can be sent to a dead-letter queue (DLQ) for later analysis.
Key Features and Configuration
Message Filtering: Subscribers can set a filter policy (a JSON object) so they only receive messages that match certain attributes. For example, a subscriber interested only in "order" events can filter on event_type: order. This reduces unnecessary traffic and processing.
Message Attributes: Publishers can attach metadata (key-value pairs) to messages. These attributes are used for filtering and can be of type String, Number, or Binary.
Message Durability: SNS stores messages across multiple Availability Zones. Once a message is published, it is replicated and durable. However, SNS is a push-based service and does not persist messages after delivery; if no subscribers are present, the message is lost. For guaranteed persistence, combine SNS with SQS (subscribe an SQS queue to the topic).
Encryption: SNS supports server-side encryption (SSE) using AWS KMS. You can specify a KMS key to encrypt messages at rest. In transit, messages are encrypted using HTTPS for HTTP endpoints and TLS for other protocols.
Access Control: Use IAM policies to control who can publish or subscribe to a topic. You can also use topic policies (resource-based policies) to allow cross-account access.
Message Delivery Status Logging: You can enable CloudWatch Logs to capture delivery status (success or failure) for each subscriber type. This helps with debugging and monitoring.
Pricing Model
SNS pricing is based on the number of messages published and delivered, plus any additional charges for SMS, mobile push, and email. The first 1 million Amazon SNS requests per month are free (as of 2025). Beyond that, you pay per 1 million requests. HTTP/HTTPS and SQS deliveries are charged as requests. Email deliveries have a separate per-1000 rate. SMS costs vary by destination country. There is no charge for subscribing or for storing topic configurations. You do not pay for messages that fail delivery (though retries count as requests).
Comparison to On-Premises Approaches
In an on-premises environment, implementing a pub/sub system typically requires setting up and managing message brokers like RabbitMQ, ActiveMQ, or Apache Kafka. This involves provisioning servers, configuring clusters, handling failover, scaling, patching, and monitoring. With SNS, AWS manages all infrastructure, including hardware, software, networking, and durability. You simply create a topic and start publishing. SNS automatically scales to handle any throughput (though there are soft limits on topics per account and subscriptions per topic, which can be increased via support).
When to Use SNS vs Alternatives
Use SNS when: You need to send a single message to multiple recipients (fan-out), you need push-based delivery (as opposed to polling), you need to send notifications to end-users via SMS, email, or mobile push, or you want to trigger multiple downstream actions from one event (e.g., an S3 upload triggers both a Lambda function and an SQS queue).
Use Amazon SQS when: You need decoupled communication between components but only one consumer should process each message (point-to-point), you need message persistence for up to 14 days, or you want consumers to poll for messages at their own pace.
Use Amazon EventBridge when: You need a more sophisticated event bus with advanced filtering, schema registry, and integration with third-party SaaS applications. EventBridge is ideal for event-driven architectures where events are generated by AWS services or custom applications and need to be routed to multiple targets with complex rules.
Hands-On: Creating an SNS Topic
To create an SNS topic using the AWS CLI:
aws sns create-topic --name MyTopicThis returns the topic ARN. To subscribe an SQS queue to this topic:
aws sns subscribe --topic-arn arn:aws:sns:us-east-1:123456789012:MyTopic --protocol sqs --notification-endpoint arn:aws:sqs:us-east-1:123456789012:MyQueueTo publish a message:
aws sns publish --topic-arn arn:aws:sns:us-east-1:123456789012:MyTopic --message "Hello World"To add a filter policy to a subscription:
aws sns set-subscription-attributes --subscription-arn arn:aws:sns:us-east-1:123456789012:MyTopic:1234-abcd --attribute-name FilterPolicy --attribute-value '{"event_type": ["order"]}'Limits and Defaults
Topic limit: 100,000 topics per account (soft limit, can be increased).
Subscriptions per topic: 12,500,000 (soft limit).
Message size: 256 KB maximum.
Message retention: SNS does not retain messages after delivery; for persistence, use SQS.
Delivery retry: For HTTP/HTTPS, SNS retries up to 3 times by default (configurable).
Filter policy size: 1 KB maximum.
Create an SNS Topic
In the AWS Management Console, navigate to SNS and click 'Create topic'. Choose a type: 'Standard' (best-effort ordering, at-least-once delivery) or 'FIFO' (first-in, first-out, exactly-once delivery). For most use cases, Standard is sufficient. Give the topic a name (e.g., 'OrderNotifications'). Optionally, enable encryption with a KMS key, set access policy, and configure tags. Click 'Create topic'. AWS creates the topic and assigns a unique ARN. Behind the scenes, SNS allocates resources to handle messages for this topic across multiple Availability Zones.
Subscribe Endpoints to the Topic
Select the topic and click 'Create subscription'. Choose a protocol (e.g., Email). For email, enter the endpoint (e.g., user@example.com). Optionally, set a filter policy (JSON) to receive only specific messages. Click 'Create subscription'. AWS sends a confirmation message to the endpoint. For email, the user must click a confirmation link in the email to confirm the subscription. Until confirmed, the subscription is in 'Pending confirmation' state. For SQS or Lambda, no confirmation is needed because the subscription is created by the owner of the queue/function. Once confirmed, the subscription becomes 'Confirmed' and will start receiving messages.
Publish a Message to the Topic
To publish, go to the topic and click 'Publish message'. Enter the message body (up to 256 KB). Optionally, add message attributes (key-value pairs) for filtering. You can also structure the message as JSON for machine consumption. Click 'Publish message'. SNS immediately attempts to deliver the message to all confirmed subscribers. For HTTP/HTTPS, SNS sends an HTTP POST. For Lambda, it invokes the function with the message as the event. For SQS, it pushes the message into the queue. SNS logs delivery status to CloudWatch Logs if enabled. If delivery fails, SNS retries based on the retry policy.
Monitor Delivery and Configure Retries
After publishing, you can view delivery status in CloudWatch Logs. To configure retries, go to the topic and edit the 'Delivery retry policy' (for HTTP/HTTPS). You can set the number of retries (1-100), the backoff function (linear or exponential), and the maximum receive rate. For example, set 3 retries with exponential backoff starting at 1 second. If all retries fail, messages can be sent to a dead-letter queue (DLQ) — an SQS queue that stores failed messages. To set up a DLQ, create an SQS queue and subscribe it to the topic as a DLQ. Then, in the subscription, specify the DLQ ARN. This prevents message loss and allows you to reprocess failures later.
Implement Message Filtering
To reduce unnecessary processing, you can set filter policies on subscriptions. For example, suppose you have a topic that receives both 'order' and 'return' events. You want one subscriber (OrderProcessor) to only process orders. In the subscription for OrderProcessor, add a filter policy: {"event_type": ["order"]}. When a message with attribute event_type = "order" is published, SNS delivers it to OrderProcessor. Messages with event_type = "return" are not delivered to that subscriber. Filter policies can include multiple keys and values, and support conditions like exists, numeric matching, and prefix matching. This reduces downstream load and costs.
Set Up Cross-Account Access
Sometimes you need to allow publishers or subscribers from another AWS account. To do this, edit the topic's access policy (resource-based policy). Add a statement that grants the other account's IAM principal the sns:Publish or sns:Subscribe permission. For example, to allow account 111111111111 to publish: {"Effect": "Allow", "Principal": {"AWS": "arn:aws:iam::111111111111:root"}, "Action": "sns:Publish", "Resource": "arn:aws:sns:us-east-1:123456789012:MyTopic"}. The other account's IAM user/role must also have an IAM policy allowing sns:Publish on that topic ARN. This enables cross-account fan-out.
Scenario 1: E-commerce Order Processing Pipeline
An online retailer processes thousands of orders per day. When a customer places an order, the order service (running on EC2) publishes a message to an SNS topic called "OrderEvents". Multiple subscribers process the event: (1) An SQS queue that feeds the fulfillment service (to pack and ship), (2) A Lambda function that updates the customer's loyalty points, (3) An email subscription to notify the customer about the order confirmation, and (4) An HTTP endpoint at the warehouse to trigger packing. This fan-out pattern decouples the order service from downstream services. If the warehouse endpoint is down, SNS retries delivery and eventually sends the message to a DLQ. The order service doesn't need to know about any of these subscribers. Cost: Each order message incurs a single publish request cost plus delivery costs to each subscriber. With millions of orders per month, this is cost-effective. Misconfiguration: If filter policies are not used, all subscribers receive every event, causing unnecessary processing and costs. For example, the loyalty Lambda might process both order and return events, wasting compute time.
Scenario 2: CloudWatch Alarm Notifications
A DevOps team monitors application health using CloudWatch alarms. When a CPU utilization alarm triggers, CloudWatch publishes a message to an SNS topic. The topic has two subscribers: (1) An email subscription to the on-call engineer's pager system, and (2) An HTTP endpoint that triggers an AWS Lambda function to automatically scale the EC2 Auto Scaling group. This setup ensures both human notification and automated remediation. The team also configures a filter policy on the email subscription to only receive alarms with severity "critical", reducing noise. Cost: CloudWatch alarm actions are free for the first 10 alarms, then a small fee per alarm action per month. SNS charges for each message published and each delivery. Misconfiguration: If the HTTP endpoint is not properly secured (e.g., without authentication), an attacker could subscribe their own endpoint to the topic and receive sensitive alarm data. Always use HTTPS and verify the endpoint's identity.
Scenario 3: Mobile Push Notifications
A social media app wants to send push notifications to users' mobile devices. The app backend publishes a message to an SNS topic. The topic has platform application endpoints subscribed, each representing a mobile device registered with Apple Push Notification Service (APNS) or Firebase Cloud Messaging (FCM). SNS handles the delivery to the respective push notification service. This is an A2P use case. The app can send personalized notifications by using message attributes (e.g., user ID). Cost: SNS charges per push notification, plus the platform service fees (APNS, FCM) which are typically free. Misconfiguration: If the device token becomes invalid (e.g., app uninstalled), SNS will attempt delivery and fail. Without a DLQ, these failures are lost. The team should implement a feedback mechanism to remove invalid tokens from the subscription list.
What CLF-C02 Tests on This Objective
The exam objective "Identify AWS services for application integration and messaging" specifically tests your ability to differentiate between Amazon SNS, Amazon SQS, and Amazon EventBridge. For SNS, you need to know: (1) It is a pub/sub messaging service. (2) It supports fan-out to multiple subscribers (SQS queues, Lambda, HTTP, email, SMS, mobile push). (3) Messages are pushed to subscribers (not polled). (4) It supports message filtering via filter policies. (5) It can be used for A2A and A2P communication. (6) FIFO topics provide ordering and exactly-once delivery. (7) SNS integrates with CloudWatch for monitoring and AWS KMS for encryption.
Common Wrong Answers and Why Candidates Choose Them
"SNS stores messages for 14 days" – This is false. SNS does not persist messages; it delivers them immediately. SQS stores messages for up to 14 days. Candidates confuse SNS with SQS.
"SNS requires polling from subscribers" – Incorrect. SNS pushes messages to subscribers. SQS requires polling. The exam often tests push vs. pull.
"SNS guarantees exactly-once delivery" – Only FIFO topics guarantee exactly-once delivery. Standard topics use at-least-once delivery (duplicates possible). Candidates assume all SNS is exactly-once.
"SNS can only send to SQS queues" – False. SNS supports many protocols: HTTP, email, SMS, Lambda, mobile push, Kinesis Firehose. The exam lists these protocols.
Specific Terms That Appear Verbatim
Topic: The logical channel.
Publisher: The message sender.
Subscriber: The message receiver.
Fan-out: Delivering one message to multiple endpoints.
Filter policy: JSON policy on subscriptions to filter messages.
Dead-letter queue (DLQ): SQS queue for failed deliveries.
Message attributes: Key-value pairs for filtering.
Confirmation: For email/HTTP subscriptions, must confirm before receiving.
FIFO: First-in, first-out ordering with exactly-once delivery (topic name must end with .fifo).
Tricky Distinctions Tested on the Exam
SNS vs. SQS: SNS is push-based (pub/sub); SQS is pull-based (point-to-point). SNS sends to multiple; SQS sends to one consumer per message. SNS does not store messages; SQS does.
SNS vs. EventBridge: EventBridge is a more advanced event bus with schema registry, transformation, and integration with SaaS partners. SNS is simpler and better for A2P notifications. EventBridge uses event rules; SNS uses subscriptions.
Standard vs. FIFO: Standard offers high throughput but no ordering guarantee; FIFO offers ordering and exactly-once but lower throughput (300 msg/s per topic).
Decision Rule for Multiple-Choice Questions
If the question mentions: "send a message to multiple receivers", "push notification", "fan-out", or "decouple producers from consumers", think SNS. If it mentions "polling", "message queue", "decouple with one consumer", think SQS. If it mentions "event routing based on rules", "SaaS integration", or "schema registry", think EventBridge. Also, if the scenario involves sending emails or SMS to users, it's definitely SNS.
SNS is a fully managed pub/sub messaging service for decoupling distributed systems.
It supports fan-out: a single message can be delivered to multiple subscribers (SQS, Lambda, HTTP, email, SMS, mobile push).
Standard topics offer at-least-once delivery; FIFO topics offer exactly-once and ordering.
Maximum message size is 256 KB; for larger payloads, use S3 and include a reference.
SNS does not persist messages; use SQS as a subscriber for durable storage.
Message filtering uses subscription filter policies (JSON) to reduce unnecessary deliveries.
SNS integrates with CloudWatch for monitoring and AWS KMS for encryption at rest.
On the CLF-C02 exam, differentiate SNS (push, pub/sub) from SQS (pull, queue) and EventBridge (event bus with rules).
These come up on the exam all the time. Here's how to tell them apart.
Amazon SNS
Pub/sub model: one message to multiple subscribers.
Push-based: SNS pushes messages to subscribers.
No message persistence after delivery.
Supports A2P (email, SMS, mobile push).
Message filtering via filter policies.
Amazon SQS
Point-to-point model: one message to one consumer.
Pull-based: consumers poll for messages.
Messages stored for up to 14 days.
No A2P; only application-to-application.
No built-in filtering; consumer filters manually.
Mistake
SNS is a queue service like SQS.
Correct
SNS is a pub/sub messaging service. It pushes messages to subscribers, not stores them. SQS is a queue service where consumers poll for messages. SNS does not persist messages after delivery; SQS stores messages up to 14 days.
Mistake
SNS guarantees exactly-once delivery.
Correct
Only FIFO topics guarantee exactly-once delivery. Standard SNS topics use at-least-once delivery, meaning duplicate messages can occur. FIFO topics also preserve message ordering, while standard topics do not guarantee order.
Mistake
SNS can only deliver to AWS services.
Correct
SNS supports many protocols including HTTP/HTTPS, email (JSON/plain text), SMS, and mobile push notifications (APNS, FCM, etc.). It can deliver to external endpoints, not just AWS services.
Mistake
Subscribers automatically receive all past messages when they subscribe.
Correct
SNS does not retain messages. A new subscriber will only receive messages published after the subscription is confirmed. Past messages are not replayed. For persistence, use SQS as a subscriber.
Mistake
SNS messages can be larger than 256 KB.
Correct
The maximum message size is 256 KB. For larger payloads, you should store the data in Amazon S3 and include a reference (e.g., S3 URL) in the SNS message.
SNS is a pub/sub messaging service that pushes messages to multiple subscribers. SQS is a queue service where consumers poll for messages. SNS is used for fan-out scenarios (one message to many), while SQS is used for decoupling producers and consumers where each message is processed by one consumer. SNS does not store messages; SQS stores messages for up to 14 days. For the CLF-C02 exam, remember that SNS pushes, SQS polls.
Yes, you can subscribe an AWS Lambda function to an SNS topic. When a message is published, SNS invokes the Lambda function asynchronously with the message as the event payload. This is a common pattern for event-driven processing. The Lambda function must have a resource-based policy allowing SNS to invoke it.
A dead-letter queue is an SQS queue that SNS can send messages to after all delivery retries to a subscription have failed. This prevents message loss and allows you to analyze and reprocess failed messages later. To use a DLQ, you create an SQS queue and configure the subscription to point to it as the DLQ.
Only FIFO (First-In-First-Out) topics guarantee message ordering. Standard SNS topics do not guarantee order; messages may be delivered out of sequence. FIFO topics also provide exactly-once delivery, but have lower throughput (300 messages per second per topic) and the topic name must end with '.fifo'.
SNS retries delivery based on a configurable retry policy. For HTTP/HTTPS, you can set the number of retries (default 3), backoff function, and maximum receive rate. If all retries fail, the message can be sent to a dead-letter queue if configured. For other protocols like email, SNS will attempt delivery but does not have a retry mechanism; it logs the failure to CloudWatch Logs.
Message filtering allows subscribers to receive only messages that match certain criteria. You set a filter policy (a JSON object) on the subscription. For example, a filter policy {"event_type": ["order"]} ensures only messages with attribute event_type equal to "order" are delivered to that subscriber. This reduces unnecessary processing and costs.
Yes, SNS supports sending SMS messages to mobile devices. You can subscribe a phone number (in E.164 format) to a topic, or use the Publish API with a phone number as the endpoint. SMS costs vary by destination country. SNS also supports two-way SMS (receiving replies) through the use of Amazon Pinpoint.
You've just covered Amazon SNS — Simple Notification Service — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?