Amazon SNS (Simple Notification Service)

Tổng quan

Amazon SNS là fully managed pub/sub messaging service để gửi notifications đến nhiều subscribers cùng lúc.

┌───────────────────────────────────────────────────────────────────┐
│                    SNS PUB/SUB MODEL                              │
├───────────────────────────────────────────────────────────────────┤
│                                                                   │
│   Publisher (1)                                                   │
│         │                                                         │
│         ↓                                                         │
│   ┌───────────────────────────────────────┐                       │
│   │           SNS TOPIC                   │                       │
│   │    "order-created-topic"              │                       │
│   └───────────────────────────────────────┘                       │
│       │           │           │           │                       │
│       ↓           ↓           ↓           ↓                       │
│   ┌───────┐   ┌───────┐   ┌───────┐   ┌────────┐                  │
│   │  SQS  │   │Lambda │   │ Email │   │ HTTP   │                  │
│   │ Queue │   │       │   │       │   │Endpoint│                  │
│   └───────┘   └───────┘   └───────┘   └────────┘                  │
│                                                                   │
│   Subscribers (many) - TẤT CẢ đều nhận message                    │
│                                                                   │
└───────────────────────────────────────────────────────────────────┘

	SNS	SQS
Model	Pub/Sub (push)	Queue (pull)
Message Delivery	1 message → ALL subscribers	1 message → 1 consumer
Persistence	No (instant delivery)	Yes (up to 14 days)
Consumer	Passive (receive push)	Active (poll messages)

1. Core Concepts

1.1 Topic

┌─────────────────────────────────────────────────────────────────┐
│                       SNS TOPIC                                 │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Topic = "Channel" để publishers gửi messages                  │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  Topic ARN: arn:aws:sns:us-east-1:123456789:my-topic    │   │
│   │                                                         │   │
│   │  Limits:                                                │   │
│   │  • Up to 12,500,000 subscriptions per topic             │   │
│   │  • Up to 100,000 topics per account                     │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

1.2 Message Structure

┌─────────────────────────────────────────────────────────────────┐
│                    SNS MESSAGE                                  │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  {                                                      │   │
│   │    "Type": "Notification",                              │   │
│   │    "MessageId": "uuid",                                 │   │
│   │    "TopicArn": "arn:aws:sns:...",                       │   │
│   │    "Subject": "Optional subject",                       │   │
│   │    "Message": "Your actual message content",            │   │
│   │    "Timestamp": "2024-01-01T00:00:00.000Z",             │   │
│   │    "MessageAttributes": {                               │   │
│   │      "OrderType": {"Type": "String", "Value": "online"} │   │
│   │    }                                                    │   │
│   │  }                                                      │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│   Max message size: 256 KB                                      │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

1.3 Publishers

Publisher	Mô tả
AWS SDK	Publish API từ applications
CloudWatch Alarms	Alert notifications
S3 Events	Bucket notifications
Lambda	Function triggers
Many AWS Services	EventBridge, CodePipeline...

2. Subscription Types

2.1 Tất cả Subscription Protocols

┌─────────────────────────────────────────────────────────────────┐
│                  SUBSCRIPTION PROTOCOLS                         │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   APPLICATION INTEGRATION:                                      │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  • SQS Queue     → Fan-out to queues                    │   │
│   │  • Lambda        → Serverless processing                │   │
│   │  • Kinesis       → Data Firehose (via Firehose)         │   │
│   │  • HTTP/HTTPS    → Custom webhooks                      │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│   DIRECT NOTIFICATIONS:                                         │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  • Email/Email-JSON  → User notifications               │   │
│   │  • SMS               → Mobile text messages             │   │
│   │  • Mobile Push       → iOS, Android, Fire OS            │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

2.2 Protocol Details

Protocol	Use Case	Confirmation
SQS	Decouple processing	Auto-confirmed
Lambda	Serverless processing	Auto-confirmed
HTTP/HTTPS	Webhooks, APIs	Must confirm subscription
Email	User alerts	Must confirm via link
SMS	Mobile alerts	No confirmation needed
Mobile Push	App notifications	Device registration

2.3 Subscription Confirmation

┌──────────────────────────────────────────────────────────────────┐
│              SUBSCRIPTION CONFIRMATION                           │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│   HTTP/HTTPS & Email subscriptions require confirmation:         │
│                                                                  │
│   1. Create subscription → Status: "Pending confirmation"        │
│                                 ↓                                │
│   2. SNS sends confirmation message                              │
│      • HTTP: POST with SubscribeURL                              │
│      • Email: Click confirmation link                            │
│                                 ↓                                │
│   3. Subscriber confirms                                         │
│                                 ↓                                │
│   4. Status: "Confirmed" → Ready to receive messages             │
│                                                                  │
│   ⚠️  Unconfirmed subscriptions auto-delete after 3 days         │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

3. Message Filtering

3.1 Filter Policy

┌─────────────────────────────────────────────────────────────────┐
│                   MESSAGE FILTERING                             │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Without Filter: ALL subscribers receive ALL messages          │
│                                                                 │
│   With Filter Policy (JSON):                                    │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  Publisher sends:                                       │   │
│   │  Message: "Order placed"                                │   │
│   │  MessageAttributes: {                                   │   │
│   │    "eventType": "order",                                │   │
│   │    "store": "online",                                   │   │
│   │    "price": 150                                         │   │
│   │  }                                                      │   │
│   └─────────────────────────────────────────────────────────┘   │
│                        ↓                                        │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  Subscriber 1 (Online Orders Only):                     │   │
│   │  FilterPolicy: {"store": ["online"]}                    │   │
│   │  → ✅ RECEIVES                                          │   │
│   ├─────────────────────────────────────────────────────────┤   │
│   │  Subscriber 2 (In-Store Orders Only):                   │   │
│   │  FilterPolicy: {"store": ["in-store"]}                  │   │
│   │  → ❌ FILTERED OUT                                      │   │
│   ├─────────────────────────────────────────────────────────┤   │
│   │  Subscriber 3 (High Value Orders):                      │   │
│   │  FilterPolicy: {"price": [{"numeric": [">=", 100]}]}    │   │
│   │  → ✅ RECEIVES (150 >= 100)                             │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

3.2 Filter Policy Operators

Operator	Example	Matches
Exact match	`{"color": ["red"]}`	color = "red"
OR	`{"color": ["red", "blue"]}`	color = "red" OR "blue"
Prefix	`{"region": [{"prefix": "us-"}]}`	region starts with "us-"
Numeric	`{"price": [{"numeric": [">", 100]}]}`	price > 100
Exists	`{"color": [{"exists": true}]}`	color attribute exists
Anything-but	`{"color": [{"anything-but": "red"}]}`	color != "red"

3.3 Filter Policy Scope

┌─────────────────────────────────────────────────────────────────┐
│              FILTER POLICY SCOPE                                │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   MessageAttributes (default):                                  │
│   • Filter based on message metadata                            │
│   • FilterPolicyScope: "MessageAttributes"                      │
│                                                                 │
│   MessageBody:                                                  │
│   • Filter based on message content (JSON)                      │
│   • FilterPolicyScope: "MessageBody"                            │
│   • Message body must be valid JSON                             │
│                                                                 │
│   Example (MessageBody filter):                                 │
│   Message: {"customer": {"type": "premium"}, "amount": 500}     │
│   FilterPolicy: {"customer": {"type": ["premium"]}}             │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

4. SNS + SQS Fan-out

4.1 Vấn đề và Giải pháp

Vấn đề: Một event cần trigger nhiều xử lý độc lập

Ví dụ: User upload ảnh → cần làm:
  1. Tạo thumbnail
  2. Phân tích AI
  3. Archive lên Glacier
  4. Gửi email thông báo

❌ KHÔNG TỐT: 1 Lambda xử lý TẤT CẢ
   → Nếu step 3 fail → ảnh hưởng cả hệ thống
   → Không scale được từng phần riêng

Giải pháp: Fan-out = "Phân nhánh" message ra nhiều hướng

                      S3 (upload ảnh)
                           │
                           ↓
                    ┌─────────────┐
                    │  SNS Topic  │  ← Nhận 1 event
                    └─────────────┘
                           │
        ┌──────────┬───────┴───────┬──────────┐
        ↓          ↓               ↓          ↓
    ┌──────┐   ┌──────┐       ┌──────┐   ┌──────┐
    │SQS 1 │   │SQS 2 │       │SQS 3 │   │Lambda│
    └──────┘   └──────┘       └──────┘   └──────┘
        ↓          ↓               ↓          ↓
    Thumbnail   AI phân tích   Archive    Email

4.2 Tại sao dùng SQS thay vì Lambda trực tiếp?

	SNS → Lambda	SNS → SQS → Consumer
Buffering	❌ Lambda phải sẵn sàng	✅ SQS giữ message khi app down
Retry	Lambda tự handle	✅ SQS có built-in retry
DLQ	Phức tạp hơn	✅ DLQ dễ config
Rate limiting	❌ Lambda bị overwhelm	✅ Consumer xử lý theo tốc độ

4.3 Fan-out với Message Filtering

⚠️ QUAN TRỌNG: Filter xảy ra ở tầng SNS, TRƯỚC KHI gửi đến SQS

┌─────────────────────────────────────────────────────────────────────────────┐
│                    MESSAGE FILTERING FLOW                                   │
├─────────────────────────────────────────────────────────────────────────────┤
│                                                                             │
│   Publisher gửi: { "orderType": "online" }                                  │
│                          │                                                  │
│                          ↓                                                  │
│                   ┌─────────────┐                                           │
│                   │  SNS Topic  │                                           │
│                   └──────┬──────┘                                           │
│                          │                                                  │
│        ┌─────────────────┼─────────────────┐                                │
│        ↓                 ↓                 ↓                                │
│   ┌──────────┐     ┌──────────┐     ┌──────────┐                            │
│   │Filter:   │     │Filter:   │     │Filter:   │  ← Filter Policy gắn       │
│   │"online"  │     │"in-store"│     │ (none)   │    VÀO SUBSCRIPTION        │
│   └────┬─────┘     └────┬─────┘     └────┬─────┘                            │
│        │                │                │                                  │
│    ✅ MATCH         ❌ SKIP          ✅ MATCH                               │
│        │                ✖                │                                  │
│        ↓                                 ↓                                  │
│   ┌──────────┐                     ┌──────────┐                             │
│   │SQS Online│                     │SQS All   │                             │
│   └──────────┘                     └──────────┘                             │
│                                                                             │
│   ⚡ SNS filter TRƯỚC → Không match = KHÔNG gửi → Tiết kiệm cost!            │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

Tại sao filter ở SNS tốt hơn filter ở SQS/Consumer?

	Filter ở Consumer	Filter ở SNS
Flow	SQS nhận TẤT CẢ → Consumer đọc rồi bỏ	SNS chỉ gửi message match
Cost	❌ Tốn tiền SQS requests	✅ Tiết kiệm
Load	❌ Consumer xử lý message không cần	✅ Giảm load

4.4 Cross-Region Fan-out

┌─────────────────────────────────────────────────────────────────┐
│              CROSS-REGION REPLICATION                           │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   US-EAST-1                           EU-WEST-1                 │
│   ┌──────────────┐                   ┌──────────────┐           │
│   │  SNS Topic   │ ───────Cross───→  │  SQS Queue   │           │
│   │              │     Region        │              │           │
│   └──────────────┘                   └──────────────┘           │
│         │                                   │                   │
│         ↓                                   ↓                   │
│   ┌──────────────┐                   ┌──────────────┐           │
│   │ Local SQS    │                   │ EU Consumer  │           │
│   └──────────────┘                   └──────────────┘           │
│                                                                 │
│   Use Cases:                                                    │
│   • Data replication across regions                             │
│   • Low-latency processing near users                           │
│   • Disaster recovery                                           │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

5. Spring Boot Integration

Có! Nhưng có 2 cách:

┌──────────────────────────────────────────────────────────────────┐
│              SPRING BOOT + SNS                                   │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│   OPTION 1: SNS → HTTP Endpoint (Spring Boot expose API)         │
│   ┌─────────────────────────────────────────────────────────────┐│
│   │  SNS Topic ──PUSH──→ https://your-app.com/sns-endpoint      ││
│   │                           ↓                                 ││
│   │                    @PostMapping("/sns-endpoint")            ││
│   │                    public void handle(@RequestBody...)      ││
│   │                                                             ││
│   │  ⚠️ Cần public URL, xử lý subscription confirmation         ││
│   └─────────────────────────────────────────────────────────────┘│
│                                                                  │
│   OPTION 2: SNS → SQS → Spring Boot (RECOMMENDED!)               │
│   ┌─────────────────────────────────────────────────────────────┐│
│   │  SNS Topic ──→ SQS Queue ←── Spring Boot @SqsListener       ││
│   │                                                             ││
│   │  ✅ Better: decoupled, retry, DLQ support                   ││
│   │  ✅ No need for public URL                                  ││
│   │  ✅ Buffering when app is down                              ││
│   └─────────────────────────────────────────────────────────────┘│
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

5.2 Option 1: HTTP Endpoint

@RestController
public class SnsController {
 
    @PostMapping("/sns-endpoint")
    public ResponseEntity<String> handleSns(@RequestBody String payload,
                                            @RequestHeader("x-amz-sns-message-type") String messageType) {
        
        // 1. Handle subscription confirmation
        if ("SubscriptionConfirmation".equals(messageType)) {
            // Extract SubscribeURL and call it to confirm
            return ResponseEntity.ok("Subscribed");
        }
        
        // 2. Handle actual notifications
        if ("Notification".equals(messageType)) {
            // Process the message
            processMessage(payload);
        }
        
        return ResponseEntity.ok("OK");
    }
}

5.3 Option 2: SNS → SQS → Spring Boot (Recommended)

@Component
public class OrderEventConsumer {
 
    // SNS publishes to SQS, Spring Boot listens to SQS
    @SqsListener("order-events-queue")
    public void handleOrderEvent(String message) {
        // Message contains SNS wrapper, parse it
        SnsNotification notification = objectMapper.readValue(message, SnsNotification.class);
        String actualMessage = notification.getMessage();
        
        // Process the actual message
        processOrderEvent(actualMessage);
    }
}

5.4 So sánh các patterns

Pattern	Pros	Cons
SNS → HTTP	Simple, direct	Need public URL, handle retries
SNS → SQS → App	Decoupled, buffering, DLQ	Extra hop, slight delay
SNS → Lambda	Serverless, auto-scale	Cold start, 15 min timeout

6. FIFO Topics

6.1 FIFO Topic Features

┌─────────────────────────────────────────────────────────────────┐
│                   SNS FIFO TOPICS                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Standard Topic:                                               │
│   • Best-effort ordering                                        │
│   • At-least-once delivery                                      │
│   • Publish throughput quota depends on Region/account          │
│                                                                 │
│   FIFO Topic:                                                   │
│   • Strict ordering (by Message Group ID)                       │
│   • Exactly-once delivery                                       │
│   • Default per-topic throughput: 3,000 msg/s or 20 MB/s        │
│   • Per message group: up to 300 msg/s                          │
│   • Name must end with ".fifo"                                  │
│                                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  SNS FIFO Topic ──────→ SQS FIFO Queue ONLY             │   │
│   │  (Cannot subscribe to Standard SQS or Lambda)           │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

6.2 Message Group ID

┌─────────────────────────────────────────────────────────────────┐
│                  MESSAGE GROUP ID                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   Publisher sends with MessageGroupId:                          │
│                                                                 │
│   Group "user-123": [Order1] → [Order2] → [Order3]              │
│   Group "user-456": [Order1] → [Order2]                         │
│                                                                 │
│   Delivery guarantees:                                          │
│   • Messages trong SAME group → Ordered                         │
│   • Messages across groups → Parallel processing                │
│                                                                 │
│   FIFO Deduplication:                                           │
│   • Content-based: SNS auto-generates dedup ID                  │
│   • Message-based: You provide MessageDeduplicationId           │
│   • 5-minute deduplication window                               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

7. Limits & Quotas

Nguồn: AWS General Reference — Amazon SNS endpoints and quotas. Các quota publish là per account, per Region và có thể thay đổi theo Region.

7.1 Resource quotas

Resource	Default quota
Standard topics	100,000 topics/account
FIFO topics	1,000 topics/account
Standard topic subscriptions	12,500,000 subscriptions/topic
FIFO topic subscriptions	100 subscriptions/topic
Pending subscriptions	5,000/account
Message size	256 KiB
Message header size	16 KiB
Messages per `PublishBatch` request	10 messages
Email / email-json delivery rate	10 messages/second/subscription — hard limit
Promotional SMS delivery rate	20 messages/second
Transactional SMS delivery rate	20 messages/second

SNS Publish/PublishBatch throughput quota tính theo messages published per second, không chỉ số API calls. PublishBatch có thể gửi tối đa 10 messages/request, nên ví dụ quota 30,000 msg/s có thể đạt bằng:

Publish: 30,000 API requests/s × 1 message
PublishBatch: 3,000 API requests/s × 10 messages
kết hợp Publish và PublishBatch, miễn tổng message/s không vượt quota Region

AWS Region group	Standard topics	FIFO topics
US East (N. Virginia) `us-east-1`	30,000 msg/s	30,000 msg/s
US West (Oregon) `us-west-2`, Europe (Ireland) `eu-west-1`	9,000 msg/s	9,000 msg/s
US East (Ohio), US West (N. California), Mumbai, Seoul, Singapore, Sydney, Tokyo, Frankfurt	1,500 msg/s	3,000 msg/s
All other supported Regions	300 msg/s	3,000 msg/s

7.3 FIFO-specific throughput notes

Scope	Quota / behavior
Per message group	Up to 300 messages/second
Per FIFO topic default	3,000 messages/second or 20 MB/second, whichever comes first, when `FifoThroughputScope = Topic`
High-throughput FIFO	Có thể đạt cao hơn khi dùng message-group-level throughput và request quota increase theo Region
Ordering tradeoff	Cross-Region deliveries có thể giảm throughput trong một message group vì phải giữ strict ordering

7.4 API throttling examples

Một số API throttling là hard quota và không tăng được:

API	Transactions/second
`Subscribe`	100
`Unsubscribe`	100
`ListTopics`	30
`ListSubscriptions`	30
`ListSubscriptionsByTopic`	30
`AddPermission` / `RemovePermission`	10
`GetSMSAttributes`	20
`SetSMSAttributes`	1

Các API quản trị topic/subscription như CreateTopic, DeleteTopic, GetTopicAttributes, SetTopicAttributes, ConfirmSubscription có quota khác nhau theo Region, ví dụ:

Region group	Transactions/second
US East (N. Virginia)	3,000
US West (Oregon), Europe (Ireland)	900
Một số Region lớn khác	150
Các Region còn lại	30

7.5 Exam notes

Standard SNS không có “unlimited throughput” tuyệt đối — publish throughput vẫn bị quota theo account/Region.
Quota publish là soft quota: có thể request tăng qua Service Quotas/AWS Support.
Email delivery 10 msg/s/subscription là hard limit: không tăng được.
Nếu cần throughput cao, ưu tiên PublishBatch, chọn Region phù hợp, và request quota increase trước peak traffic.

8. Security

8.1 Encryption

┌──────────────────────────────────────────────────────────────────┐
│                       ENCRYPTION                                 │
├──────────────────────────────────────────────────────────────────┤
│                                                                  │
│   IN-FLIGHT:                                                     │
│   • HTTPS endpoints required                                     │
│   • TLS for all API calls                                        │
│                                                                  │
│   AT-REST (SSE):                                                 │
│   • SSE-KMS for message encryption                               │
│   • Key: AWS managed or Customer managed CMK                     │
│   • Messages encrypted before stored (temporary)                 │
│                                                                  │
│   ⚠️  Note: SNS doesn't store messages long-term                 │
│       Encryption mostly for in-transit protection                │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘

8.2 Access Control

┌─────────────────────────────────────────────────────────────────┐
│                    ACCESS CONTROL                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   IAM POLICIES:                                                 │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  Control WHO can Publish/Subscribe                      │   │
│   │  Attached to IAM users/roles                            │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│   SNS ACCESS POLICIES (Resource-based):                         │
│   ┌─────────────────────────────────────────────────────────┐   │
│   │  Attached to SNS topic                                  │   │
│   │  Allow cross-account publish/subscribe                  │   │
│   │  Allow AWS services (S3, CloudWatch)                    │   │
│   └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

SNS Access Policy Example (Allow S3 to publish):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"Service": "s3.amazonaws.com"},
    "Action": "sns:Publish",
    "Resource": "arn:aws:sns:region:account:topic",
    "Condition": {
      "ArnLike": {
        "aws:SourceArn": "arn:aws:s3:::my-bucket"
      }
    }
  }]
}

9. Best Practices

9.1 Design Patterns

Pattern	Description
Fan-out	SNS → Multiple SQS queues
Event-driven	SNS → Lambda
Cross-account	SNS topic in Account A, SQS in Account B
Cross-region	SNS topic in region A, SQS in region B

9.2 Message Filtering Best Practices

Practice	Recommendation
Filter at SNS	Don't filter in Lambda/Consumer
Use MessageAttributes	More efficient than body filtering
Keep policies simple	Complex policies = slower processing

9.3 Reliability

┌─────────────────────────────────────────────────────────────────┐
│                  RELIABILITY TIPS                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   SNS → SQS:                                                    │
│   • Configure DLQ on SQS for failed messages                    │
│                                                                 │
│   SNS → Lambda:                                                 │
│   • Configure DLQ on Lambda                                     │
│   • Set appropriate retry count                                 │
│                                                                 │
│   SNS → HTTP:                                                   │
│   • SNS retries with exponential backoff                        │
│   • Configure DLQ on SNS subscription                           │
│   • 3 immediate retries + 23 retries over 3 hours               │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

9.4 Cost Optimization

Strategy	Description
Message Filtering	Reduce unnecessary deliveries
Batch Publishing	PublishBatch API (up to 10 msgs)
Right Protocol	SQS cheaper than SMS for alerts

┌─────────────────────────────────────────────────────────────────┐
│            SNS vs SQS vs EVENTBRIDGE                            │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│   SNS:                                                          │
│   • Pub/Sub, fan-out                                            │
│   • Simple message filtering                                    │
│   • Many subscription types                                     │
│   • No persistence                                              │
│                                                                 │
│   SQS:                                                          │
│   • Queue, point-to-point                                       │
│   • Message persistence                                         │
│   • Consumer polling                                            │
│   • No native fan-out                                           │
│                                                                 │
│   EventBridge:                                                  │
│   • Event bus                                                   │
│   • Advanced filtering (100+ rules)                             │
│   • Event transformation                                        │
│   • Schema registry                                             │
│   • Event replay                                                │
│   • Third-party integration                                     │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

Feature	SNS	SQS	EventBridge
Model	Pub/Sub	Queue	Event Bus
Filtering	Simple (attributes)	None	Advanced (100+ rules)
Persistence	No	Yes	Archive/Replay
Targets	Many protocols	Consumer apps	AWS services
Transform	No	No	Yes
Use Case	Fan-out	Decouple	Event-driven

Amazon SNS (Simple Notification Service)

On this page