Tuần 7 - Ngày 2: Amazon SNS
Mục tiêu học tập
- Hiểu SNS: managed pub/sub messaging
- Phân biệt Topic types: Standard vs FIFO
- Nắm subscription protocols và message filtering
- Áp dụng fanout pattern (SNS + SQS)
1. Tổng quan SNS
Amazon SNS (Simple Notification Service) = fully managed pub/sub messaging service.
Đặc điểm
- Push-based (vs SQS pull-based)
- Fanout: 1 message → multiple subscribers
- Multiple protocols: HTTP/S, Email, SMS, Lambda, SQS, mobile push, Kinesis Firehose
- Highly scalable: millions of messages/sec
- Message retention: 14 days (if subscribers down, retry)
Use cases
- Application notifications (email, SMS)
- Fanout to multiple SQS queues
- Lambda triggers
- Mobile push notifications (iOS, Android, Fire OS)
- CloudWatch alarm notifications
2. Topic Types
Standard Topic
- At-least-once delivery
- Best-effort ordering
- Unlimited throughput
- All subscription types supported
FIFO Topic
- Exactly-once delivery
- Strict ordering (per Message Group)
- 300 publishes/sec (without batching)
- Only SQS FIFO subscribers (no email, SMS, HTTP, Lambda)
- Topic name must end with
.fifo
When FIFO
- Need ordering across messages
- Need exactly-once
- Trade-off: lower throughput, limited subscriber types
3. Subscription Protocols
| Protocol | Use case |
|---|---|
| HTTP / HTTPS | Webhook to your endpoint |
| Email / Email-JSON | Send notification to email |
| SMS | Send text message to phone (charged per SMS) |
| SQS | Fanout to SQS queue |
| Lambda | Invoke Lambda function |
| Application (mobile push) | iOS APNs, Android FCM, Fire OS ADM, Baidu, WNS, MPNS |
| Amazon Data Firehose (cũ: Kinesis Data Firehose) | Stream to S3, Redshift, OpenSearch |
| SMS to 200+ countries | Direct SMS |
Subscription confirmation
- For HTTP/email: subscriber must confirm subscription (click link / verify)
- Prevents spam
4. Fanout Pattern (SNS + SQS)
Architecture
Lợi ích
- 1 publish → N consumers (no publisher rewrite)
- Each consumer independent (own queue, own processing rate)
- Add/remove consumers without affecting publisher
- Each queue can have own DLQ, own visibility timeout
Use case examples
- E-commerce order placed → Email notification + Update inventory + Trigger analytics
- File upload to S3 → Generate thumbnail + Index for search + Send notification
Setup
- Tạo SNS Topic
- Tạo multiple SQS queues
- Subscribe each queue to topic
- Configure SQS access policy allowing SNS to publish
5. Message Filtering
Định nghĩa
Message Filtering = subscribers receive only messages matching filter policy (instead of all).
Filter Policy (subscriber-level)
{
"event_type": ["order_placed", "order_shipped"],
"amount": [{ "numeric": [">=", 100] }],
"country": [{ "anything-but": ["US"] }]
}
Use case
- 1 topic for all events, subscribers pick relevant ones
- Reduce processing for irrelevant messages
- Simpler architecture than multiple topics
Example
6. SNS Security
Access Control
- IAM policies (identity-based)
- SNS Topic Policy (resource-based, cross-account)
Encryption
- In transit: TLS
- At rest: KMS encryption
VPC Endpoint
- Interface Endpoint cho SNS
- Private subnet publish to SNS
Message data protection (NEW)
- Detect/mask PII trong SNS messages (similar to Macie)
7. Mobile Push Notifications
Supported platforms
- APNs (Apple Push Notification Service) - iOS
- FCM (Firebase Cloud Messaging) - Android
- ADM (Amazon Device Messaging) - Fire OS
- WNS (Windows Push) - Windows
- MPNS (Microsoft Push Notification) - Windows Phone (legacy)
- Baidu Cloud Push - Android China
Workflow
1. App registers with platform (APNs/FCM)
2. App sends device token to your backend
3. Backend creates "endpoint" in SNS for device
4. SNS endpoint added to topic (or directly published)
5. Publish to topic → SNS forwards to APNs/FCM → device
8. SNS with Amazon Data Firehose
Integration (2023+)
- SNS subscribe to Amazon Data Firehose delivery stream
- Stream messages to:
- S3
- Redshift
- OpenSearch
- HTTP endpoint
- 3rd party (Splunk, Datadog)
Use case
- Centralize event logging from SNS to S3 data lake
- Real-time analytics with OpenSearch
9. SNS vs SQS vs EventBridge (deep)
| SNS | SQS | EventBridge | |
|---|---|---|---|
| Model | Pub/Sub | Queue | Event Bus + Routing |
| Subscribers | Push to all | Pull by 1 | Push to all matching rules |
| Filtering | Yes (subscription) | No (consumer filter) | Yes (rules) |
| Sources | Producers | Producers | AWS services, custom, SaaS |
| Targets | HTTP, email, SMS, SQS, Lambda, mobile, Firehose | EC2, Lambda, Fargate (poll) | 25+ AWS services |
| Retry | Built-in | Visibility timeout + DLQ | Built-in + DLQ |
| Use case | Fanout, notifications | Decouple async work | Event-driven architecture |
Decision guide
- Notify multiple subscribers: SNS
- Decouple producer-consumer pace: SQS
- Route AWS events to targets with filtering: EventBridge
- Combo: SNS for fanout, SQS for each subscriber queue, EventBridge for AWS-native events
10. SNS Pricing
- $0.50 per million publishes (Standard)
- $1.00 per million publishes (FIFO)
- HTTP deliveries: $0.60 per million
- Email: $2.00 per 100K (US)
- SMS: per message + country-specific (~$0.00645/SMS in US)
- Lambda invocations: free (Lambda billed separately)
- SQS delivery: free (SQS billed separately)
- Mobile push: $0.50 per million
Free tier
- 1M publishes/month
- 100,000 HTTP deliveries
- 1,000 emails
- 1M mobile push
11. Common Patterns
Pattern 1: Order processing fanout
Pattern 2: Multi-channel alerts
Pattern 3: Mobile app push
Pattern 4: Event filtering
Câu hỏi ôn tập
-
SNS push hay pull?
Xem đáp án
Push — SNS chủ động push messages đến subscribers ngay khi publish. Khác với SQS (pull model — consumers phải poll). SNS subscriber nhận message ngay lập tức mà không cần polling. Đây là pub/sub model: publisher publish một lần, SNS fan-out đến nhiều subscribers cùng lúc.
-
FIFO topic subscriber type bị giới hạn gì?
Xem đáp án
FIFO SNS topic chỉ hỗ trợ FIFO SQS queues làm subscribers. Không thể subscribe Lambda, HTTP endpoints, email, SMS, mobile push vào FIFO topic. Standard topic hỗ trợ tất cả subscriber types. Giới hạn này vì FIFO ordering và exactly-once delivery chỉ có thể guarantee khi cả topic lẫn subscriber đều FIFO.
-
Fanout pattern với SNS + SQS giải quyết vấn đề gì?
Xem đáp án
Cho phép một message được xử lý độc lập bởi nhiều consumers. Ví dụ: order placed → SNS topic → (1) SQS queue cho inventory service, (2) SQS queue cho notification service, (3) SQS queue cho analytics. Mỗi service có queue riêng — có thể scale và fail independently. Nếu một service down, messages vẫn trong SQS queue chờ — không mất. Đây là pattern decoupling mạnh nhất cho microservices.
-
Message filtering set ở topic hay subscription level?
Xem đáp án
Subscription level — mỗi subscription có thể có filter policy riêng. Filter policy dựa trên message attributes (key-value metadata trong message). Subscriber chỉ nhận messages matching filter — giảm processing và cost. Ví dụ: subscription A filter
{"type": ["order"]}, subscription B filter{"type": ["payment"]}— cùng topic nhưng mỗi subscriber chỉ nhận relevant messages. -
SNS có hỗ trợ mobile push notifications không? Platforms nào?
Xem đáp án
Có — SNS là platform chuẩn cho mobile push. Hỗ trợ: APNs (Apple Push Notification service — iOS/macOS), FCM/GCM (Firebase Cloud Messaging — Android), ADM (Amazon Device Messaging — Kindle), Baidu Cloud Push (China Android). Cần configure platform application với credentials từ platform. SNS handle authentication với push platforms — không cần code riêng per platform.
Bài tập thực hành
- Tạo Standard SNS Topic
- Subscribe email, confirm subscription, test publish
- Fanout: 1 topic → 3 SQS queues, publish 1 message, verify all 3 received
- Add message filter cho 1 subscription, test filtering works
- Setup CloudWatch alarm → SNS → email
- (Optional) Mobile push setup with FCM
Tài liệu tham khảo chính thức
Tiếp theo: EventBridge