SNS

Pub/sub messaging service for fan-out notifications and application decoupling

Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service that enables fan-out messaging to large numbers of subscribers including SQS queues, Lambda functions, HTTP endpoints, and email. It decouples producers from consumers, allowing a single message publish to trigger multiple downstream systems simultaneously. SNS is a foundational building block for event-driven architectures on AWS.

How SNS Works: Topics, Publishers, and Subscribers

SNS operates on a topic-based publish/subscribe model. Publishers send messages to a topic, and SNS delivers that message to all confirmed subscribers of that topic. Delivery happens in near real-time and in parallel to all subscribers.

Concept	Description	Example
Topic	Logical access point and communication channel	arn:aws:sns:us-east-1:123:order-placed
Publisher	Any AWS service or application that sends a message	EC2 app, Lambda, CloudWatch alarm
Subscriber	Endpoint that receives messages from the topic	SQS queue, Lambda, HTTP/S endpoint, email, SMS
Message	Up to 256 KB of text data	JSON payload with order details
Subscription filter	Policy to selectively receive messages based on attributes	Only receive messages where order_type=premium

💡

SNS is a push model - it delivers messages to subscribers immediately. Contrast this with SQS where consumers poll for messages. Use SNS when you need immediate fan-out delivery to multiple endpoints.

Standard vs FIFO Topics

SNS offers two topic types with different delivery guarantees and throughput characteristics.

Feature	Standard Topic	FIFO Topic
Message order	Best-effort ordering	Strict first-in, first-out per message group
Delivery	At-least-once (duplicates possible)	Exactly-once processing
Throughput	300 million messages/second	300 messages/second per topic (can request increase)
Subscriber types	SQS, Lambda, HTTP/S, email, SMS, mobile push	SQS FIFO queues only
Message deduplication	Not supported	Supported via deduplication ID
Use case	High-volume fan-out, notifications	Financial transactions, order processing

⚠️

FIFO topics can only deliver to FIFO SQS queues. If you need email or Lambda subscribers with ordering guarantees, you need a different architecture - typically a FIFO queue with a Lambda consumer.

Fan-Out Pattern and Message Filtering

The SNS fan-out pattern is one of the most common architectures in AWS. A single SNS topic fans out to multiple SQS queues, each owned by a different service. This decouples the publisher from consumers and allows each consumer to process at its own pace.

Message filtering reduces the number of messages each subscriber processes. Instead of filtering in consumer code, you attach a filter policy to the subscription.

bash

# Publish a message with attributes
aws sns publish \
  --topic-arn arn:aws:sns:us-east-1:123:orders \
  --message '{"orderId": "abc123", "amount": 99.99}' \
  --message-attributes '{
    "orderType": {"DataType":"String","StringValue":"premium"},
    "region": {"DataType":"String","StringValue":"us-east"}
  }'

# Create a subscription with filter policy
aws sns subscribe \
  --topic-arn arn:aws:sns:us-east-1:123:orders \
  --protocol sqs \
  --notification-endpoint arn:aws:sqs:us-east-1:123:premium-orders \
  --attributes '{"FilterPolicy":"{\"orderType\":[\"premium\"]}"}'

💡

Filter policies can match on string values, string prefixes, numeric ranges, and existence of attributes. A single filter policy can have up to 5 attribute conditions. This is far more efficient than routing in Lambda code.

Delivery Policies, Retries, and Dead-Letter Queues

SNS has built-in retry logic for HTTP/S endpoints. For Lambda and SQS subscribers, AWS manages retries at the destination service level. Understanding retry behavior is critical for building reliable systems.

Subscriber Type	Retry Behavior	DLQ Support
HTTP/HTTPS	Immediate, then 1s, 20s, 20s... up to 23 days total	No native DLQ - use SQS in front
SQS	SQS handles retries via visibility timeout and redrive policy	Yes - SQS DLQ
Lambda	Lambda retries twice on async invocation errors	Yes - SNS subscription DLQ or Lambda destination
Email	No retries - one delivery attempt	No
SMS	Carrier-level retries only	No

⚠️

For critical workflows, never publish directly from SNS to Lambda without a DLQ configured on the Lambda function or SNS subscription. A Lambda cold-start error or throttle will drop the message permanently without a DLQ.

bash

# Set a DLQ on an SNS subscription (redrive policy)
aws sns set-subscription-attributes \
  --subscription-arn arn:aws:sns:us-east-1:123:orders:abc-sub-id \
  --attribute-name RedrivePolicy \
  --attribute-value '{"deadLetterTargetArn":"arn:aws:sqs:us-east-1:123:sns-dlq"}'

SNS Pricing and Cost Optimization

Delivery Type	Pricing	Notes
HTTP/HTTPS	$0.60 per million deliveries	First 100k free per month
SQS deliveries	Free	No charge for SNS-to-SQS
Lambda deliveries	Free	Pay only for Lambda execution
Email/Email-JSON	$2.00 per 100k notifications	Not for transactional - use SES
SMS (US)	$0.00645 per message	Varies heavily by country
Mobile push	$0.50 per million notifications	APNS, GCM, ADM

💡

SNS-to-SQS delivery is free, which is why the fan-out pattern (SNS to multiple SQS queues) is so cost-effective. The SNS cost is essentially zero - you only pay for what processes the messages downstream.

🎯

Interview Focus Points

1Explain the SNS fan-out pattern and why you would use it instead of publishing directly to multiple consumers.
2What is the difference between SNS Standard and FIFO topics, and when would you choose FIFO?
3How does SNS message filtering work, and what is the performance benefit of filtering at the subscription level vs consumer code?
4How would you ensure no messages are lost when SNS delivers to a Lambda function that is throttled or errors?
5What happens to an SNS message if the HTTP endpoint is down? Walk me through the retry behavior.
6Can you subscribe an SQS FIFO queue to an SNS Standard topic? Why or why not?
7How would you implement a pattern where only certain consumers receive certain messages from a single SNS topic?
8What is the difference between SNS and EventBridge for event routing?