Amazon SNS (Simple Notification Service)¶

Introduction¶

Amazon SNS is a fully managed pub/sub messaging service that enables you to decouple microservices, distributed systems, and event-driven serverless applications. It can deliver messages to multiple subscribers through various protocols.

Key Features¶

Pub/Sub model - One-to-many messaging
Multiple protocols - HTTP, Email, SMS, SQS, Lambda, mobile push
Message filtering - Subscribers receive only relevant messages
FIFO topics - Ordered delivery with deduplication
Message fanout - Deliver to multiple endpoints simultaneously
Dead-letter queues - Handle delivery failures

When to Use¶

Ideal Use Cases¶

Application alerts - Notify multiple systems of events
Push notifications - Mobile app notifications
Email/SMS notifications - User notifications
Fanout pattern - Distribute to multiple SQS queues
Event-driven architecture - Trigger multiple services from one event
Application integration - Decouple microservices

Need to send messages to multiple subscribers
Want push-based delivery
Need multiple delivery protocols
Want to decouple publishers from subscribers
Need message filtering capabilities

Core Concepts¶

Topics¶

Named resource for publishing messages
Subscribers receive messages from topics
Standard or FIFO types

Publishers¶

Send messages to topics
Don't know about subscribers
Various AWS services can publish

Subscribers¶

Receive messages from topics
Multiple subscriber types supported
Can filter messages

Subscription Protocols¶

Protocol	Description	Use Case
SQS	Queue integration	Decoupled processing
Lambda	Serverless processing	Event handling
HTTP/HTTPS	Webhook endpoints	External integrations
Email	Email notifications	User alerts
Email-JSON	JSON-formatted email	Structured notifications
SMS	Text messages	Mobile alerts
Platform endpoint	Mobile push	App notifications
Kinesis Firehose	Data streaming	Analytics

What to Be Careful About¶

Message Delivery¶

No persistence - Messages not stored; use SQS for durability
At-least-once delivery - Duplicates possible
Delivery retry - Different retry policies per protocol
Order not guaranteed - Use FIFO topics when needed
Message size - Max 256 KB

Cost Management¶

Per-request pricing - Each publish and delivery costs
SMS costs - Can be expensive; set spending limits
Free tier - 1 million publishes, 100K HTTP deliveries
Large fanout - Each subscriber delivery costs

Security¶

Topic policies - Control who can publish/subscribe
Encryption - Enable server-side encryption
Message filtering - Reduce unnecessary deliveries
Access control - Use IAM policies

Operational¶

Subscription confirmation - HTTP/Email require confirmation
Dead-letter queues - Configure for failed deliveries
Message filtering - Reduce processing overhead
FIFO limits - 300 publishes/second (3,000 with batching)

Message Filtering¶

Subscribers can filter messages based on attributes:

Filter Policy Example¶

{
  "eventType": ["order_placed", "order_shipped"],
  "store": ["store-a"],
  "price": [{"numeric": [">=", 100]}]
}

Filter Operations¶

String matching (exact, prefix, suffix, anything-but)
Numeric comparison
Exists/not exists
Logical operators (AND, OR)

Fanout Pattern¶

SNS Fanout Pattern

Benefits¶

Parallel processing
Different processing speeds
Independent scaling
Protocol flexibility

Standard vs FIFO Topics¶

Feature	Standard	FIFO
Throughput	Unlimited	300/3,000 TPS
Ordering	Best-effort	Guaranteed
Deduplication	None	5-minute window
Subscribers	All protocols	SQS FIFO only
Use case	High volume	Strict order

FIFO Topic Requirements¶

Topic name ends with .fifo
Only FIFO SQS queues as subscribers
Message group ID required

Common Interview Questions¶

What's the difference between SNS and SQS?
SNS: Pub/sub, push-based, multiple subscribers, no persistence
SQS: Queue, pull-based, one consumer, messages persist
Often used together: SNS → multiple SQS queues
How does SNS fanout work?
Single message published to topic
Delivered to all subscribers simultaneously
Each subscriber processes independently
Common pattern: SNS → multiple SQS queues
What is message filtering?
Subscribers specify filter policy
Only receive messages matching policy
Reduces processing overhead
Filtering on message attributes
When would you use SNS vs EventBridge?
SNS: Simple fanout, various protocols, SMS/Email
EventBridge: Complex routing, transformations, schema registry
How do you handle failed deliveries?
Configure dead-letter queue
Retry policies per protocol
Monitor delivery failures
Alert on DLQ messages

Integration Patterns¶

Application Integration¶

Application Integration

Event Notification¶

Event Notification Pattern

Mobile Push¶

Mobile Push Notification

Alternatives¶

AWS Alternatives¶

Service	When to Use Instead
SQS	Need message persistence, pull-based
EventBridge	Complex routing, transformations
Kinesis	Real-time streaming, data replay
MQ	Need AMQP, MQTT, JMS protocols
Pinpoint	Marketing campaigns, analytics

External Alternatives¶

Provider	Service
Google Cloud	Cloud Pub/Sub
Azure	Service Bus, Event Grid
Twilio	SMS/Voice notifications
Firebase	Cloud Messaging
Apache Kafka	Streaming with persistence

Best Practices¶

Use message filtering - Reduce unnecessary processing
Configure dead-letter queues - Handle failures
Set SMS spending limits - Prevent unexpected costs
Use FIFO when ordering matters - Financial transactions
Enable encryption - Server-side encryption with KMS
Monitor delivery metrics - CloudWatch alarms
Use SNS + SQS for durability - Messages persist in SQS
Confirm subscriptions - Verify HTTP/Email endpoints
Use message attributes - Enable filtering
Apply topic policies - Control access

Pricing¶

Component	Cost
Publishes	$0.50 per million
HTTP/S deliveries	$0.60 per million
SQS deliveries	Free
Lambda deliveries	Free
Email deliveries	$2.00 per 100K
SMS deliveries	$0.00645+ per message (US)
Mobile push	$0.50 per million
Free tier	1M publishes, 100K HTTP

Mobile Push Notifications¶

Platform Applications¶

APNS (Apple)
FCM/GCM (Android/Chrome)
ADM (Amazon devices)
Baidu (China Android)
WNS (Windows)

Flow¶

Mobile Push Notification Flow