AWS Application Integration: Amazon SNS
Amazon Simple Notification Service (SNS) is a highly available, durable, secure, fully managed pub/sub messaging service. It allows you to decouple microservices, distributed systems, and serverless applications by enabling a “push” based communication model.
The Real-World Analogy
Think of Amazon SNS like a Radio Station. The station (Publisher) broadcasts a signal to a specific frequency (Topic). Anyone who tunes their radio to that frequency (Subscribers) receives the broadcast instantly. The station doesn’t care who is listening or how many people are tuned in; it just pushes the message out.
Core Concepts for SAA-C03
1. Pub/Sub Model
- Publishers: Entities that send messages to an SNS Topic (e.g., S3 Events, CloudWatch Alarms, EC2).
- Topics: Logical access points and communication channels.
- Subscribers: Entities that “listen” to the topic (e.g., SQS, Lambda, Kinesis Data Firehose, HTTP/S endpoints, Email, SMS, Mobile Push).
2. Standard vs. FIFO Topics
| Feature | Standard Topics | FIFO Topics |
|---|---|---|
| Delivery Order | Best-effort (no guarantee) | Strictly Ordered (First-In-First-Out) |
| Durability | At-least-once delivery | Exactly-once delivery |
| Throughput | Nearly unlimited | Up to 300 msg/sec (or 30,000 with batching) |
| Use Case | General decoupling, alerting | Banking transactions, inventory updates |
3. The “Fan-Out” Pattern
This is a critical SAA-C03 architecture pattern. In a Fan-out scenario, an SNS message is sent to multiple SQS queues or Lambda functions simultaneously. This allows for parallel processing of the same event by different services (e.g., one queue for image processing, another for metadata indexing).
Security and Reliability
- Encryption: Supports Server-Side Encryption (SSE) using AWS KMS to protect message content at rest.
- Access Control: Uses IAM Policies for API access and SNS Topic Policies (similar to S3 Bucket Policies) to allow cross-account access.
- Message Filtering: Subscribers can define a “Filter Policy” so they only receive messages that meet specific attributes, reducing unnecessary processing.
- Dead Letter Queues (DLQ): SNS can move messages that couldn’t be delivered to an SQS DLQ for later analysis.
Decision Matrix: If-Then Guide
- If you need to send a message to multiple different consumers… Then use SNS (Pub/Sub).
- If you need to ensure a message is processed by only one consumer… Then use SQS (Queue).
- If you need to fan-out to SQS queues in different regions… Then use SNS (Standard topics support cross-region delivery).
- If you need to trigger a Lambda function based on an S3 upload… Then use S3 Event Notifications with SNS or SQS.
Exam Tips and Gotchas
- SNS is “Push”: Unlike SQS (which is “Pull/Polling”), SNS pushes data to subscribers immediately.
- No Message Persistence: If no one is subscribed to a topic when a message is sent, the message is lost (unless using specific delivery retry policies). SNS is not a database.
- Message Size: Maximum message size is 256KB (same as SQS).
- Cross-Account: To allow another AWS account to publish to your topic, you must update the SNS Topic Policy.
- Protocols: Remember that SNS can send SMS and Email directly, which is a common distractor for “how to alert an admin.”
Topics covered:
Summary of key subtopics covered in this guide:
- Pub/Sub Architecture (Publishers, Topics, Subscribers)
- Standard vs. FIFO Topic comparison
- Fan-out architectural pattern
- Message Filtering and Fan-out logic
- Security (KMS Encryption and Topic Policies)
- SNS vs. SQS Decision Logic
Amazon SNS Architecture Infographic
Visualizing the Fan-out Pattern: One message, multiple downstream consumers.
IAM: Control who can Publish/Subscribe.
KMS: Encrypt sensitive payloads at rest.
CloudWatch: Monitor NumberOfMessagesPublished and NumberOfNotificationsFailed.
Scaling: SNS scales automatically to handle massive spikes in traffic without manual intervention.
Latency: Low-latency delivery, typically within milliseconds.
Pricing: You pay per 1 million requests and per number of notifications delivered (varies by protocol).
Tip: Email and SMS are significantly more expensive than SQS or Lambda delivery.
Production Use Case: Order Processing
When a user places an order (Publisher), the Order Service sends a message to an SNS Topic. This message is then fanned out to:
- SQS Queue A: Shipping Service processes the delivery.
- SQS Queue B: Invoice Service generates the PDF.
- Lambda: Analytics Service updates the real-time dashboard.
- SNS Email: Sends a confirmation to the customer.