Amazon SNS (Simple Notification Service)¶

Model: ONE-TO-MANY (fan-out)

SQS model: PULL — consumer polls queue when ready
SNS model: PUSH — SNS pushes to all subscribers immediately

Publisher → SNS Topic → [  SQS Queue      ]
                         [  Lambda        ]
                         [  HTTP endpoint ]
                         [  Email         ]
                         [  SMS           ]
                         [  Mobile Push   ]

All subscribers receive the SAME message simultaneously

Delivery:   at-least-once (may duplicate)
Ordering:   best-effort (may be out of order)
Throughput: nearly unlimited
Subscribers: up to 12.5 million per topic [aws.amazon](https://aws.amazon.com/sns/features/)
Topics per account: 100,000 [aws.amazon](https://aws.amazon.com/sns/features/)

Compatible subscriber types:
  SQS Standard, SQS FIFO, Lambda, HTTP/HTTPS, Email, SMS,
  Mobile Push, Kinesis Data Firehose

Use case: maximum fan-out, high throughput, duplicate-tolerant

Delivery:   exactly-once
Ordering:   strict FIFO
Throughput: 300 TPS publish (matches FIFO SQS limits)
Subscribers: up to 100 per topic [aws.amazon](https://aws.amazon.com/sns/features/)
Topics per account: 1,000 [aws.amazon](https://aws.amazon.com/sns/features/)

Compatible subscriber types:
  SQS FIFO ONLY

Topic name must end in: .fifo

Use case: order-critical events (financial transactions, inventory updates)

import boto3, json

sns = boto3.client('sns', region_name='us-east-1')

# Simple publish
sns.publish(
    TopicArn='arn:aws:sns:us-east-1:123456789012:order-events',
    Message=json.dumps({
        'orderId': 'ORD-12345',
        'userId': 'USER-789',
        'amount': 149.99,
        'items': ['laptop', 'mouse']
    }),
    Subject='New Order Placed',       # used by Email subscriptions as subject line
    MessageAttributes={
        'eventType': {
            'DataType': 'String',
            'StringValue': 'ORDER_PLACED'
        },
        'region': {
            'DataType': 'String',
            'StringValue': 'pk'
        }
    }
)

{
  "Type": "Notification",
  "MessageId": "abc123-...",
  "TopicArn": "arn:aws:sns:us-east-1:123456789012:order-events",
  "Subject": "New Order Placed",
  "Message": "{\"orderId\":\"ORD-12345\",\"userId\":\"USER-789\"}",
  "Timestamp": "2026-04-08T17:00:00.000Z",
  "SignatureVersion": "1",
  "Signature": "...",
  "MessageAttributes": {
    "eventType": { "Type": "String", "Value": "ORDER_PLACED" }
  }
}

Without filtering:
  SNS topic: all-events
    → SQS: order-service  receives: orders, payments, returns, reviews
    → SQS: payment-service receives: orders, payments, returns, reviews
    (each must filter in code — wasteful, complex)

With filtering:
  SNS topic: all-events
    → SQS: order-service   filter: {"eventType": ["ORDER_PLACED", "ORDER_CANCELLED"]}
    → SQS: payment-service filter: {"eventType": ["PAYMENT_SUCCESS", "PAYMENT_FAILED"]}
    → SQS: review-service  filter: {"eventType": ["REVIEW_SUBMITTED"]}
    (each receives only its own events — clean, decoupled)

MessageAttributes scope (default):
  Filter on MessageAttributes sent with publish call
  Message body can be anything (not parsed)

MessageBody scope:
  Filter on JSON fields inside the message body itself
  Message body must be valid JSON
  Enable: FilterPolicyScope = "MessageBody"

// Exact string match
{ "eventType": ["ORDER_PLACED"] }

// Multiple allowed values (OR logic)
{ "eventType": ["ORDER_PLACED", "ORDER_UPDATED", "ORDER_CANCELLED"] }

// Numeric filter
{ "amount": [{ "numeric": [">=", 100] }] }
{ "amount": [{ "numeric": [">", 50, "<=", 500] }] }

// String prefix
{ "customerId": [{ "prefix": "PREMIUM-" }] }

// Exists / not exists
{ "referralCode": [{ "exists": true }] }
{ "testFlag":     [{ "exists": false }] }

// Anything-but (exclude specific values)
{ "eventType": [{ "anything-but": ["TEST_EVENT", "INTERNAL_PING"] }] }

// Combined (AND logic between keys)
{
  "eventType": ["ORDER_PLACED"],
  "region": ["pk", "in", "bd"],
  "amount": [{ "numeric": [">=", 50] }]
}

Order Service publishes ONE message to SNS:
  sns.publish(TopicArn=ORDER_TOPIC, Message=order_json)

SNS simultaneously delivers to ALL subscribers:
  → SQS: fulfillment-queue    → Lambda polls → picks items → ships
  → SQS: payment-queue        → Lambda polls → processes payment
  → SQS: email-queue          → Lambda polls → SES sends confirmation
  → SQS: analytics-queue      → Lambda polls → updates dashboard
  → Lambda: fraud-detection   → invoked immediately → checks fraud score
  → HTTP: partner-webhook     → notifies fulfillment partner

All processing happens in PARALLEL
One service failure doesn't affect others
Each SQS queue has its own DLQ for failure handling

SNS alone:
  ✅ Instant fan-out to many subscribers
  ❌ If Lambda/HTTP endpoint down → message LOST
  ❌ No retry buffer
  ❌ Consumer must be always available

SQS alone:
  ✅ Durable buffering with retry
  ✅ Consumer reads when ready
  ❌ Only one consumer type per queue
  ❌ Send to multiple consumers = publish to each queue separately

SNS + SQS together:
  ✅ SNS fan-out: publish once → all queues receive simultaneously
  ✅ SQS durability: message buffered if consumer down
  ✅ SQS retry: visibility timeout + DLQ
  ✅ Each queue independently scalable
  ✅ Decoupled: publisher doesn't know about consumers
  This is the standard production architecture [docs.aws.amazon](https://docs.aws.amazon.com/sns/latest/dg/sns-sqs-as-subscriber.html)

For managed endpoints (SQS, Lambda):
  SNS retries until success or message expires
  SQS: durable — message stored until consumed
  Lambda: retried with exponential backoff

For HTTP/HTTPS endpoints:
  Retry policy (exponential backoff with jitter):
    Immediate:    3 retries (0 delay)
    Pre-backoff:  2 retries (1s delay)
    Backoff:      10 retries (exponential: 1s → 20 minutes)
    Post-backoff: 100,000 retries (20 minutes each) ← effectively unlimited

  On final failure (all retries exhausted):
    → Message discarded (unless DLQ configured on subscription)

SNS Subscription DLQ:
  Can attach SQS queue as DLQ on individual subscription
  Failed deliveries → DLQ for investigation
  Different from SQS DLQ (that's on the queue, not the subscription)

SNS as push notification platform for mobile apps:

Platforms supported:
  Apple APNS    → iOS, macOS, tvOS
  Google FCM    → Android
  Amazon ADM    → Kindle Fire
  Baidu         → China Android devices
  Microsoft WNS → Windows

Flow:
  1. Mobile app registers with platform (APNS/FCM) → gets device token
  2. App sends device token to your backend
  3. Backend creates SNS Platform Endpoint using token
  4. Backend calls sns.publish(TargetArn=endpoint_arn, Message=...)
  5. SNS routes to correct platform → platform delivers to device

Fan-out to millions of devices:
  Create SNS topic → subscribe millions of platform endpoints
  sns.publish(TopicArn=...) → SNS pushes to all devices simultaneously
  → Scales to millions of devices per publish

Encryption:
  In-transit: HTTPS by default
  At-rest: SSE-SNS (AES-256) or SSE-KMS (your KMS key)

Access control:
  IAM policy: who can publish to topic, subscribe, manage
  SNS resource policy: cross-account publishing

Cross-account publishing:
  Account B wants to publish to Account A's topic:
  Account A adds resource policy:
  {
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::ACCOUNT-B:root" },
    "Action": "sns:Publish",
    "Resource": "arn:aws:sns:us-east-1:ACCOUNT-A:my-topic"
  }

Subscription confirmation:
  HTTP/HTTPS subscriptions: SNS sends confirmation request
  Endpoint must respond to confirmation URL within 3 days
  Prevents SNS from spamming endpoints without consent

Standard Topic:
  First 1 million publishes/month: FREE
  After: $0.50 per million publish requests

  Deliveries:
    SQS / Lambda / HTTP:        $0.50 per million
    Email:                      $2.00 per 100,000
    SMS (US):                   $0.00645 per message
    Mobile Push (APNS/FCM):     $0.50 per million

FIFO Topic:
  Publish: $0.30 per million
  Delivery to SQS FIFO: $0.30 per million