LearningTree · AWS · Integration

Amazon SNS —
Simple Notification Service

A fully managed publish-subscribe messaging service that lets one event simultaneously reach many consumers — decoupling your systems and enabling event-driven architectures at scale.

📡 SNS in 30 Seconds

Managed pub/sub service — one message published, many subscribers receive it simultaneously
Decouples producers from consumers — they don't need to know about each other
Supports SQS, Lambda, HTTP/S, Email, and SMS as subscriber targets
Fan-out architecture: SNS + SQS is the standard reliable multi-consumer pattern
Push-based — SNS delivers to subscribers immediately (not pull like SQS)

Chapter One

What is Amazon SNS

The Problem: Tightly Coupled Systems Introductory

Imagine an e-commerce platform where a customer places an order. The Order Service needs to:

Send a confirmation email to the customer
Update the inventory system
Notify the shipping service to prepare a package
Trigger a fraud detection check

⚠️

Tightly Coupled (Bad)

Order Service calls each system directly
If Email Service is down → order fails
Adding a new service requires changing Order Service code
All services must be available simultaneously
One slow consumer slows everything

✅

Loosely Coupled with SNS (Good)

Order Service publishes one event to SNS
SNS fans out to all subscribers independently
Each system works independently
New systems subscribe without touching Order Service
One slow subscriber doesn't affect others

The Mental Model: A Broadcasting System Introductory

👉 SNS is like a public address system in a building. One announcement is made from a single microphone — and every speaker in every room hears it at the same time. The speaker doesn't know who is listening, and the listeners don't know who is speaking.

Real-world analogies that work well:

📻

Radio Broadcast

One station broadcasts a signal. Many radios tuned to that frequency receive it. The station doesn't care how many listeners exist.

📰

You publish one newsletter. All subscribers receive the same content. Subscribers can opt in or out without affecting the publisher.

🔔

Push Notification

An app sends one alert. All users with notifications enabled receive it simultaneously — regardless of how many they are.

What SNS Actually Is Introductory

Amazon SNS (Simple Notification Service) is a fully managed publish-subscribe (pub/sub) messaging service. It enables you to decouple applications by:

Publishers sending messages to a central Topic
SNS immediately delivering that message to all Subscribers
Subscribers receiving the same message in parallel — independently

The core formula is simple:

SNS — Core Concept: One Publisher → Many Subscribers

Why This Matters in Distributed Systems Core

SNS solves three fundamental distributed systems problems:

🔗

Decoupling

Producers and consumers don't know about each other. The Order Service doesn't need to know that Email, Lambda, and SQS exist — it just publishes to a topic.

📈

Scalable Communication

Adding a new consumer doesn't require changes to the producer. Subscribe a new service to the topic and it instantly starts receiving all future events.

⚡

Event-Driven Architecture

Systems react to events rather than being directly called. This is the foundation of modern microservice and serverless architectures on AWS.

SNS vs Synchronous Calls — Why It Scales Core

Concern	Direct API Calls (Synchronous)	SNS (Asynchronous Pub/Sub)
Adding new consumer	Modify publisher code	Subscribe to topic — no code change
Consumer goes down	Publisher fails too	Other consumers unaffected
Scaling consumers	Publisher must coordinate	Each consumer scales independently
Latency sensitivity	Publisher waits for all calls	Publisher returns instantly after publish
Architecture complexity	Grows with each new consumer (N×N)	Always 1×N — one publisher, N subscribers

🎓 Exam Insight

When an exam question describes a scenario where one event needs to trigger multiple actions simultaneously — order placed → email + inventory + shipping — the answer pattern is SNS fan-out. SNS is the "broadcasting" service; SQS is the "buffering queue" service. They are complementary, not competing.

👉 Key Takeaway

SNS is the broadcast backbone of event-driven AWS architecture — one message reaches many consumers instantly, without the publisher knowing who is listening

Chapter Two

Core Messaging Concepts

The Four Building Blocks Introductory

Every SNS interaction involves four elements. Understanding these clearly is the foundation for everything else on this page.

📢

Topic

The central communication channel. A named endpoint that publishers write to and subscribers listen on. Think of it as a named event stream — order-placed, user-signup, payment-failed.

Has a unique ARN identifier
Can have up to 12.5 million subscriptions
Two types: Standard and FIFO

📤

Publisher

Any application or service that sends a message to a topic. The publisher has no knowledge of who the subscribers are or how many exist.

EC2 instance, Lambda function, microservice
AWS services (CloudWatch, CodePipeline, S3)
Calls Publish API with topic ARN + message

📥

Subscriber

Any endpoint that registers interest in a topic. When a message arrives, SNS pushes it to every active subscriber in parallel.

SQS queue, Lambda function, HTTP/S endpoint
Email address, SMS phone number
Amazon Kinesis Data Firehose

✉️

Message

The payload sent by the publisher. Up to 256 KB of text (JSON, XML, plain text). Can carry attributes (metadata) for filtering without touching the message body.

Message body: up to 256 KB
Message attributes: key-value metadata pairs
Message ID: unique identifier assigned by SNS

Understanding the 256 KB Message Limit Core

The 256 KB limit applies to the entire publish request — message body + attributes + metadata combined. Multi-byte characters (emoji, CJK) consume more bytes than they appear.

📦

What counts toward 256 KB

Message body (JSON / text / XML)
Message attribute keys and values
Topic ARN + request metadata

🌍

Character encoding

All messages are UTF-8
ASCII: 1 byte per character
Emoji / CJK: 3–4 bytes each
256 KB ≈ 256,000 ASCII chars

📐

If you exceed 256 KB

Store payload in S3, send S3 URI in SNS
Compress with gzip before publishing
Split into multiple sequenced messages
Best practice: keep SNS <10 KB

Concept Diagram — The Four Elements Introductory

SNS Building Blocks — Topic, Publisher, Subscriber, Message

The Fan-Out Pattern Core

👉 Fan-out is the defining capability of SNS: one message in → N deliveries out. Each subscriber receives a full, independent copy of the message and processes it in parallel.

Fan-out solves a classic distributed systems challenge: how do you notify many systems about the same event without the event source needing to know about all of them?

1️⃣

One Publish Call

The publisher makes a single API call to SNS. No loops, no parallel threads, no knowledge of downstream systems.

⚡

Parallel Delivery

SNS delivers to all subscribers simultaneously. Subscriber A doesn't wait for Subscriber B to finish processing.

🔌

Independent Processing

Each subscriber processes at its own pace, in its own way. A Lambda function and an SQS queue behave entirely differently — and that's fine.

Standard Topic vs FIFO Topic Core

SNS offers two topic types. Choose based on whether message order and deduplication matter for your workload:

Feature	Standard Topic	FIFO Topic
Message ordering	Best-effort (not guaranteed)	Strict order guaranteed
Deduplication	Possible duplicates	Exactly-once delivery
Throughput	Near-unlimited	300 msg/s (3,000 with batching)
Subscriber types	SQS, Lambda, HTTP, Email, SMS	SQS FIFO queues only
Use case	Most event-driven workloads	Financial transactions, stock tickers, strict sequencing

FIFO Topic — Throughput, Limits & Key Restrictions In-Depth

⚡

Throughput

300 msg/sec — default without batching
3,000 msg/sec — with batching (10 messages per batch × 300 TPS)
Can request limit increase via AWS Support
Each batch counts as one API transaction

⚠️

Hard Restrictions

Subscriber types: SQS FIFO only — no Lambda, HTTP, Email, SMS
No subscription filter policies — all subscribers get all messages
No cross-account — SQS FIFO must be in same AWS account
Message deduplication ID required (or enable content-based deduplication)
Messages with same group ID are strictly ordered

Aspect	Detail
Message group ID	Required — defines ordering scope. Messages with same ID are processed in FIFO order.
Deduplication window	5 minutes — same deduplication ID within 5 min is silently dropped
Content-based dedup	Enable on topic to avoid managing dedup IDs — SNS hashes the message body
When NOT to use FIFO	Lambda/HTTP/Email subscribers, filter policies needed, throughput > 3,000 msg/sec

Message Flow Diagram Core

Message Lifecycle — From Publish to Delivery

Subscription Filter Policies In-Depth

By default, every subscriber receives every message published to a topic. Filter policies let subscribers declare which messages they care about — based on message attributes — without the publisher needing to route differently.

📋

Without Filters

All subscribers get all messages
Each subscriber must ignore irrelevant messages in code
Wastes Lambda invocations and SQS receives
Fine for homogeneous consumers

🔍

With Filter Policies

Subscriber only receives matching messages
Filter evaluated by SNS — no code needed
Example: "event-type": ["order-placed"]
Reduces cost and processing overhead

Filter Policy — Route Messages to the Right Subscriber

Filter Policy — JSON Structure Examples In-Depth

Filter policies are JSON objects you attach to a subscription. SNS evaluates them server-side before delivering. The publisher must include matching message attributes for filtering to work.

📌

Match by string value

{"event-type": ["order.placed",
               "order.updated"]}

Array = OR logic. Delivers if attribute equals any listed value.

🔢

Numeric comparison

{"price": [{"numeric": [">", 100]}]}

Supports >, <, >=, <=, =. Also supports ranges: [">", 0, "<=", 500].

🧩

AND logic (multi-key)

{"event-type": ["order.placed"],
 "region": ["NA","EU"],
 "amount": [{"numeric":[">=",500]}]}

Multiple keys = AND. All conditions must match.

🔍

Prefix & exists checks

{"tier": [{"prefix": "gold"}]}
{"priority": [{"exists": true}]}

Prefix: match strings starting with value. Exists: require attribute to be present.

👉 Publishing with attributes (required for filtering): Message attributes must be set by the publisher — SNS cannot filter on the message body. If a message has no attributes, it is delivered to ALL subscribers regardless of filter policies.

🎓 Exam Insight

A common exam scenario: "You have one SNS topic with multiple subscribers. Each subscriber should only receive messages relevant to them, without code changes." The answer is SNS Subscription Filter Policies — set a filter on each subscription based on message attributes, and SNS handles the routing server-side.

👉 Key Takeaway

SNS topics, publishers, subscribers, and filter policies are the four core building blocks — master these and every architecture pattern follows naturally

Chapter Three

How SNS Works in AWS Architecture

The General Architecture Flow Introductory

In any AWS architecture, SNS sits as the event broadcast layer between event producers (applications, AWS services, Lambda functions) and event consumers (queues, functions, endpoints). The flow is always the same:

👉 Application or AWS Service → publishes event → SNS Topic → SNS pushes to all subscribers in parallel

Supported Subscriber Types Core

🗂️

SQS Queue

Most common subscriber. SNS pushes the message into the queue where workers poll and process at their own pace. Enables durable, buffered processing.

Lambda Function

SNS triggers Lambda directly. Ideal for real-time processing, transformation, or routing. Lambda scales automatically with the message volume.

🌐

HTTP / HTTPS Endpoint

SNS sends an HTTP POST to any publicly reachable URL. Useful for webhook-style integrations with third-party systems or custom services.

📧

Email / Email-JSON

SNS sends an email to a subscribed address. Requires manual confirmation by the recipient. Used for CloudWatch alarms and operational alerts.

📱

SMS

Delivers text messages to mobile numbers. Used for critical alerts, OTP notifications, and on-call paging. Supports transactional and promotional tiers.

🔥

Kinesis Firehose

SNS fans events directly into a Firehose delivery stream. Used for real-time analytics pipelines — events flow to S3, Redshift, or OpenSearch automatically.

AWS Architecture Diagram Core

SNS in AWS — EC2/Lambda → SNS Topic → Multiple Subscriber Types

How AWS Services Natively Publish to SNS Core

SNS isn't just for application code. Many AWS services can publish directly to an SNS topic without any custom code:

AWS Service	What It Publishes	Common Use
CloudWatch Alarms	Alarm state changes (OK → ALARM → INSUFFICIENT)	Notify on-call team, trigger auto-remediation Lambda
S3 Event Notifications	Object created, deleted, or restored	Trigger processing pipeline when file arrives in S3
CodePipeline / CodeBuild	Pipeline state changes, build pass/fail	Notify dev team of deployment success or failure
AWS Health	Service disruptions, maintenance events	Proactive alerts to ops teams
Auto Scaling	Scale-out / scale-in lifecycle events	Warm up new instances before traffic hits them
RDS	Database events (failover, backup, restore)	Alert on database failover events

Message Delivery Latency — What to Expect Core

SNS delivery is near-instant but not zero. Latency varies by subscriber type — plan your architecture around realistic expectations:

Subscriber Type	Typical Latency	Notes
SQS (same region)	30–100 ms	Fastest — queue is co-located in same region
Lambda (same region)	50–200 ms	Add cold-start time (~200ms) if function is not warm
HTTP/S endpoint	100–500 ms	Depends on endpoint response time; SNS waits for 200 OK
Cross-region SQS	200–800 ms	Data transfer across AWS regions adds overhead
Email	2–10 seconds	Email provider and spam filter delays
SMS	2–15 seconds	Carrier network delays; varies by country

👉 SNS offers no delivery latency SLA — it is best-effort with high throughput. Do not use SNS for hard real-time requirements (<10 ms). For near-real-time (100–200 ms), use SQS + long-polling consumers.

SMS & Email — Production Limitations In-Depth

SMS and Email subscriptions have significant regional and operational constraints that matter in production:

Region	SMS Supported	Sender ID	Notes
United States	Yes	No (10DLC required)	Must register 10-digit long code (10DLC) for A2P messaging
Canada	Yes	No	Registration required for A2P; short codes available
Europe	Yes	Yes (varies)	Sender ID registration varies per country; some require approval
India	Yes	No	DLT (Distributed Ledger Technology) registration mandatory
Australia	Yes	Yes (pre-register)	Sender IDs require pre-registration with carriers
China	Limited	N/A	Requires local ICP providers; SNS direct SMS not reliable

⚠️

Email Subscription Limits

Requires manual confirmation by recipient (double opt-in)
Not suitable for high-volume automated sends
No attachments — plain text or HTML only
For scale: use Lambda subscriber → Amazon SES instead

📱

SMS Best Practices

Test in target countries before production
Use Transactional type for OTP / alerts (higher priority)
Use Promotional type for marketing (lower cost)
Set monthly SMS spend limits to avoid surprise bills

Event Flow Diagram — CloudWatch Alarm → SNS → Action Core

Real-World Event Flow — CloudWatch Alarm triggers SNS fan-out

Why SNS Makes Microservices Powerful Core

In a microservices architecture, each service owns a narrow slice of business logic. Without SNS, services communicate by calling each other directly — creating a tight mesh of dependencies. With SNS:

🕸️

Without SNS — Direct Calls

Order API calls Inventory API, Email API, Shipping API directly
3 services to keep track of from 1 producer
Add a 4th consumer → update Order API code, redeploy
If any downstream service is slow → Order API is slow

⭐

With SNS — Event Bus

Order API publishes OrderPlaced event to SNS topic
Inventory, Email, Shipping subscribe independently
Add a 4th consumer → just subscribe to the topic — zero code change in Order API
Each consumer processes asynchronously at its own speed

🎓 Exam Insight

Key architecture trigger words: When you see "one event should trigger multiple independent actions", "services should not be tightly coupled", or "adding a new consumer without changing existing code" — the answer is SNS topic with multiple subscribers. This pattern maps directly to real-world microservice design.

👉 Key Takeaway

SNS acts as the broadcast backbone of AWS event-driven systems — AWS services, applications, and microservices all publish to topics, and any number of consumers receive events without coupling

Chapter Four

SNS + SQS Fan-Out Architecture

Why SNS Alone Isn't Always Enough Introductory

👉 SNS delivers messages immediately and does not store them. If a subscriber is temporarily unavailable, that message is gone. For durable, reliable processing — pair SNS with SQS.

📡

SNS — Broadcasts

Push-based: delivers instantly to all subscribers
No storage: if subscriber misses the message, it's gone
Best for fire-and-forget notifications (email, HTTP webhooks)
Not ideal for workloads that need retries or buffering

🗄️

SQS — Buffers

Pull-based: consumers poll at their own pace
Stores messages for up to 14 days
Handles backpressure: consumers can slow down without losing messages
Built-in retry with visibility timeout and DLQ support

The Fan-Out Pattern with SNS + SQS Core

The SNS + SQS fan-out is the most important SNS architecture pattern. It combines SNS's broadcasting with SQS's durability:

One producer publishes a single event to an SNS topic
SNS fans out to multiple SQS queues simultaneously
Each SQS queue is consumed by an independent service or worker
Each consumer processes at its own pace, retries independently, scales independently

Production Fan-Out Architecture Diagram In-Depth

SNS + SQS Fan-Out — Producer → SNS → Multiple SQS Queues → Independent Consumers

Why Fan-Out Is So Powerful Core

🔀

Decoupling

The Order Service (producer) has zero knowledge of Inventory, Shipping, or Analytics. They are completely independent. Remove any one of them — the producer keeps working unchanged.

⚖️

Independent Scaling

The Inventory worker can scale to 10 instances while Shipping uses 2 and Analytics uses 1. Each scales based on its own queue depth — completely independent of the others.

🔄

Retry Isolation

If the Shipping worker fails for 10 minutes, messages accumulate in the Shipping SQS queue. Inventory and Analytics are completely unaffected. When Shipping recovers, it drains its queue.

🛡️

Durability via SQS

Even if SNS delivers and the worker is down, messages are safely held in SQS for up to 14 days. Nothing is lost. SNS alone would drop the message — SQS is the durability layer.

Without Fan-Out vs With Fan-Out Core

Concern	Direct Service Calls	SNS + SQS Fan-Out
Adding a new consumer	Modify producer + redeploy	Subscribe new SQS queue, zero producer change
Consumer is slow	Producer waits / times out	Queue buffers messages, consumer catches up
Consumer crashes	Messages lost	Messages stay in SQS queue, retried automatically
Consumer scaling	Must coordinate with producer	Each service scales via its own queue depth
One consumer fails	Can cascade to other consumers	Other consumers completely unaffected
Audit / replay	Hard — real-time only	Messages retained in queue for inspection or replay

When to Use SNS Alone vs SNS + SQS In-Depth

Scenario	Use SNS Alone	Use SNS + SQS
Email / SMS alerts	Yes — fire and forget is fine	Not needed
Lambda real-time processing	Yes — Lambda handles retries itself	SQS adds buffering if needed
Multiple microservices, each processing independently	Risky — no durability	Yes — each service gets its own queue
Consumer may be slow / unavailable	Messages dropped	Yes — SQS buffers the backlog
Audit trail needed	No — SNS doesn't retain messages	Yes — SQS retains for up to 14 days

🎓 Exam Insight

The SNS + SQS fan-out pattern is one of the most frequently tested AWS architecture patterns. The trigger will usually be: "multiple services must each receive and independently process the same event", "a consumer can be unavailable without losing messages", or "services should scale independently". The answer is always SNS topic → multiple SQS queues → independent consumers.

👉 Key Takeaway

SNS + SQS fan-out is the gold standard for reliable, scalable, multi-consumer event processing — SNS broadcasts, SQS buffers, and each consumer is fully independent

Chapter Five

SNS vs SQS vs EventBridge

The Common Confusion Introductory

SNS, SQS, and EventBridge are all messaging services — but they solve different problems. Many developers (and exam questions) confuse them because they all involve sending and receiving messages between services. The key is understanding what each one was designed for.

👉 These three services are not competitors — they are complementary layers. Production architectures routinely use all three together.

One-Line Mental Models Introductory

📡

SNS

"I need to broadcast one event to many consumers at the same time."

Push-based fan-out. One publish → many parallel deliveries.

🗂️

SQS

"I need to queue work so a consumer can process it reliably at its own pace."

Pull-based buffer. One message → one consumer. Durable storage.

🔀

EventBridge

"I need to route events based on content, with advanced filtering and scheduling."

Event router with rules, cross-account delivery, and SaaS integration.

Full Comparison Table Core

Feature	SNS	SQS	EventBridge
Pattern	Publish / Subscribe	Message Queue	Event Bus / Router
Delivery model	Push — SNS pushes to subscribers	Pull — consumers poll the queue	Push — EventBridge pushes to targets
Consumers per message	Many — all subscribers receive a copy	One — a single consumer receives each message	Many — multiple rules can match and route
Message retention	No — delivers immediately or fails	Yes — up to 14 days	No — event bus is transient
Filtering	Subscription filter policies (on message attributes)	No filtering — consumer receives all messages	Rich content-based filtering on event body
Ordering	Standard: best-effort · FIFO: strict	Standard: best-effort · FIFO: strict	No ordering guarantee
throughput	Near-unlimited (Standard)	Near-unlimited (Standard)	10,000 events/sec default (soft limit)
Retry / DLQ	Retry per subscriber · DLQ supported	Built-in retry with visibility timeout + DLQ	Retry with exponential backoff · DLQ supported
SaaS / cross-account	No	No	Yes — Salesforce, Zendesk, GitHub, cross-account buses
Scheduling	No	No	Yes — cron and rate-based scheduled rules
Best for	Broadcasting events to multiple systems simultaneously	Reliable, buffered work queue for a single consumer	Event routing, filtering, scheduling, SaaS integration

When to Use Each Core

📡

Choose SNS when…

One event must reach multiple consumers at once
You need simple broadcast semantics
Combining with SQS queues for fan-out
Sending CloudWatch alarm emails or SMS alerts
Triggering multiple Lambda functions from one event

🗂️

Choose SQS when…

Work must be processed exactly once by one consumer
Consumer may be slow, unavailable, or need retries
You need message buffering and backpressure handling
Task queues: image processing, order fulfilment, batch jobs
You need messages retained for up to 14 days

🔀

Choose EventBridge when…

You need content-based routing — route by event fields
Integrating with SaaS providers (Salesforce, GitHub, Stripe)
Cross-account or cross-region event delivery
Scheduled tasks (cron jobs, periodic triggers)
Complex event filtering without custom code

How They Work Together In-Depth

In production architectures, these three services are often used in the same pipeline:

SNS + SQS + EventBridge — Working Together in One Architecture

Common Confusion Areas Core

Confusion	Clarification
SNS vs SQS — which is the queue?	SQS is the queue. SNS has no queue — it delivers immediately or not at all. SNS is the broadcaster, SQS is the buffer.
SNS vs EventBridge — both fan out, whats the difference?	SNS does simple fan-out to multiple subscribers. EventBridge adds content-based routing, SaaS integration, scheduling, and cross-account buses. Use EventBridge when you need routing logic; use SNS when you need broadcast.
Can SNS and EventBridge both trigger Lambda?	Yes. For simple pub/sub use SNS. For complex routing rules, SaaS events, or scheduled triggers use EventBridge.
Do I need SNS if I have EventBridge?	Often yes. EventBridge targets a single rule destination per match. SNS is better when you need guaranteed simultaneous fan-out to many subscribers from one event.
Who retains messages — SNS or SQS?	SQS retains messages (up to 14 days). SNS does not retain — if delivery fails and retries are exhausted, the message is gone unless you configured a DLQ.

🎓 Exam Insight

One event → multiple systems in parallel → SNS fan-out (+ SQS for durability)
Work queue, one processor per task, retry needed → SQS
Route events from SaaS / across accounts / by content fields → EventBridge
Scheduled recurring job → EventBridge scheduled rule → Lambda
Message must survive consumer downtime → SQS (not SNS alone)

👉 Key Takeaway

SNS broadcasts, SQS buffers, EventBridge routes — they are not alternatives but layers of an event-driven architecture that work best together

Chapter Six

Real-World Use Cases

Where SNS Appears in Real Systems Introductory

SNS is not an exotic service — it shows up in almost every production AWS architecture. These are the patterns you will encounter most often:

Use Case 1 — Order Notification Pipeline Core

🛒

Scenario

An e-commerce platform needs to notify multiple systems the moment a customer places an order — confirmation email, inventory update, shipping preparation, and fraud detection all at once.

✅

Architecture

Order Service publishes OrderPlaced to SNS topic
SNS → SQS (Inventory) → Inventory worker updates stock
SNS → SQS (Shipping) → Shipping worker creates fulfilment job
SNS → Lambda → Fraud score calculated in real-time
SNS → Email → Confirmation sent to customer

Use Case 2 — CloudWatch Alarms → Ops Team Core

🚨

Scenario

Infrastructure monitoring: when a CloudWatch alarm fires (high CPU, low disk, error rate spike), multiple teams and automated systems need to react simultaneously.

🔧

Architecture

CloudWatch Alarm → SNS topic ops-alerts
SNS → Email → on-call engineer paged
SNS → Lambda → Auto-remediation script runs
SNS → SQS → Audit log queue for compliance
SNS → HTTP → PagerDuty / Slack webhook

Use Case 3 — Microservice Event Propagation Core

🏗️

Scenario

A user management service handles sign-up, profile updates, and account deletions. Downstream services (marketing, billing, analytics) each need to react to these events independently.

✅

Architecture

User Service publishes events to user-events SNS topic
Subscription filter: event-type = "signup" → Marketing SQS
Subscription filter: event-type = "deleted" → Billing Lambda
No filter → Analytics SQS receives all events
New downstream service? Just subscribe — zero changes to User Service

Use Case 4 — Serverless Event Pipeline In-Depth

Serverless Pipeline — S3 Upload → SNS → Lambda + SQS Processing

Use Case 5 — CI/CD Pipeline Notifications Core

🔨

CodePipeline → SNS

Pipeline state changes (SUCCESS, FAILED, STOPPED) publish to an SNS topic automatically — no custom code needed.

📧

SNS → Email

Dev team receives a deployment success or failure email immediately after each pipeline run.

SNS → Lambda

On failure: Lambda posts to Slack, creates a Jira ticket, or triggers a rollback — all driven by the same SNS event.

Use Case 6 — Security Alert Broadcasting Core

🔐

Scenario

GuardDuty detects suspicious activity (e.g., root account login from unusual IP). This security event must reach multiple systems simultaneously for rapid response.

🛡️

Architecture

GuardDuty → EventBridge rule → SNS topic security-alerts
SNS → SMS → Security team paged immediately
SNS → Lambda → Automatically disable the IAM user
SNS → SQS → Incident response queue for ticketing system
SNS → Email → CISO notification

👉 Key Takeaway

SNS appears in every category of AWS architecture — from e-commerce and DevOps to security and serverless pipelines — always solving the same core problem: broadcasting one event to many consumers simultaneously

Chapter Seven

Security & Reliability

Access Control — Who Can Publish and Subscribe Core

🔑

IAM Policies

Control which IAM users, roles, and services can call sns:Publish, sns:Subscribe, and sns:CreateTopic. Applied to the caller (publisher/subscriber).

Attach to EC2 instance roles, Lambda execution roles
Least-privilege: only allow sns:Publish on specific topic ARN
Deny publish from untrusted accounts

📋

Topic Policies (Resource Policies)

Attached directly to the SNS topic — controls who can access the topic from outside. Essential for cross-account publishing.

Allow other AWS accounts to publish to your topic
Allow specific AWS services (S3, CloudWatch) to publish
Deny all except specific principals

IAM vs Topic Policy — Which Governs What Core

Scenario	Use IAM Policy	Use Topic Policy
IAM user/role in same account publishes	Yes — attach to role	Not required (optional)
Another AWS account publishes to your topic	Not sufficient alone	Yes — must allow in topic policy
AWS service (S3, CloudWatch) publishes	Not required	Yes — trust the service principal
Restrict which topics a role can publish to	Yes — specify ARN in IAM	Not the right tool

Cross-Account Publishing — Complete Example In-Depth

Scenario: Account A (producer) needs to publish to an SNS topic owned by Account B. IAM policy alone is insufficient — you need both.

1️⃣

Account B — Topic Policy (owner)

{
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::ACCOUNT-A:root"
    },
    "Action": "sns:Publish",
    "Resource": "arn:aws:sns:us-east-1:
                 ACCOUNT-B:MyTopic"
  }]
}

2️⃣

Account A — IAM Role Policy (producer)

{
  "Statement": [{
    "Effect": "Allow",
    "Action": "sns:Publish",
    "Resource": "arn:aws:sns:us-east-1:
                 ACCOUNT-B:MyTopic"
  }]
}

👉 KMS encryption adds a step: if the topic uses SSE with a custom CMK, Account B's KMS key policy must also grant Account A kms:Decrypt and kms:GenerateDataKey — otherwise publish will fail with an access denied error on the KMS key, not SNS.

Encryption Core

🔒

Encryption at Rest (SSE)

SNS supports Server-Side Encryption using AWS KMS. Messages are encrypted when stored in SNS (briefly, during delivery processing).

Enable on topic creation or update
Uses AWS managed key (aws/sns) or your own CMK
Required for compliance (PCI DSS, HIPAA workloads)

🌐

Encryption in Transit

All communication with SNS endpoints is over HTTPS/TLS by default. You can enforce HTTPS-only access via a topic policy condition.

Add condition aws:SecureTransport: true in topic policy
Denies any HTTP (unencrypted) publish attempts
Best practice for all production topics

VPC Endpoint for SNS — Private Subnet Publishing In-Depth

By default, SNS API calls route over the public internet (even with TLS). EC2 instances in private subnets without a NAT Gateway cannot reach SNS. The solution is a VPC Interface Endpoint (PrivateLink).

🔒

Benefits

Traffic stays entirely within the AWS network — never touches the internet
No Internet Gateway or NAT Gateway required
Lower latency — no internet hop
Endpoint policy can restrict which topics can be published to from the VPC

🛠️

Setup Steps

Create interface VPC endpoint: service com.amazonaws.{region}.sns
Enable DNS resolution on the endpoint (uses existing SNS SDK URLs)
Attach security group allowing outbound HTTPS (443) from compute
Optionally add endpoint policy to restrict sns:Publish to specific topic ARNs
Cost: ~$0.01/hr per AZ + data processing

🎓 Exam Insight

Scenario: "EC2 instances in a private subnet need to publish to SNS. The company requires traffic to stay within AWS — no internet exposure." Answer: Create a VPC Interface Endpoint for SNS. This is the same PrivateLink pattern used for S3 Gateway endpoints and SSM endpoints.

Delivery Retries and Dead-Letter Queues Core

SNS retries failed deliveries automatically — but the behavior depends on the subscriber type:

Subscriber Type	Retry Behaviour	DLQ Support
SQS	3 retries with backoff (very reliable — SQS is durable)	Yes
Lambda	3 retries with backoff	Yes
HTTP / HTTPS	Up to 23 retries over ~23 days with exponential backoff	Yes
Email	Best-effort — limited retries, no DLQ	No
SMS	Best-effort — limited retries based on carrier	No

👉 Dead-Letter Queues (DLQ) on SNS subscriptions capture messages that could not be delivered after all retries. Always configure a DLQ on SQS and Lambda subscriptions in production so no event is silently dropped.

CloudWatch Metrics — What to Monitor in Production Core

SNS publishes these metrics to CloudWatch automatically. Set alarms on NumberOfNotificationsFailed as your primary health signal:

Metric	What It Measures	Recommended Action
NumberOfNotificationsDelivered	Messages successfully delivered to subscribers	Baseline — watch for unexpected drops
NumberOfNotificationsFailed	Delivery failures after all retries exhausted	Alarm if > 0 sustained for 5 min
NumberOfNotificationsFilteredOut	Messages blocked by subscription filter policies	Monitor for unexpected filtering spikes
NumberOfMessagesPublished	Total messages published to the topic	Baseline for capacity planning
PublishSize	Size of published messages (bytes)	Alarm if frequently near 256 KB limit

🔔

Recommended Alarm

Metric: NumberOfNotificationsFailed
Statistic: Sum
Period: 5 minutes
Threshold: > 0
Action: SNS → email ops team

Transient single failures are normal. Alarm on sustained failures only.

📋

Enable Delivery Status Logging

Activate in SNS topic settings per subscriber protocol
HTTP/S — logs request/response body
Lambda — logs invocation results
SQS — logs delivery attempts and failures
Logs go to CloudWatch Logs — enable in topic configuration

SNS is NOT Long-Term Storage — Design Accordingly In-Depth

⚠️

What SNS Does NOT Do

Does not persist messages after delivery (unlike SQS)
Does not allow consumers to replay past messages
Does not guarantee delivery to unavailable subscribers (without SQS)
Does not support message visibility or polling

✅

Design Patterns to Compensate

Pair with SQS for durable buffering of every event
Configure DLQ on subscriptions to catch delivery failures
Use Kinesis Firehose subscriber to archive all events to S3
Enable CloudWatch metrics on SNS to monitor delivery failures

Key Security Best Practices Core

Best Practice	Why It Matters
Enable SSE (KMS encryption) on topics with sensitive data	Protects messages at rest — required for regulated industries
Enforce HTTPS-only via topic policy (`aws:SecureTransport`)	Prevents plaintext message interception in transit
Use least-privilege IAM for publishers	Limits blast radius if a service is compromised
Configure DLQ on all SQS and Lambda subscriptions	Prevents silent message loss on delivery failure
Use topic policies for cross-account access (not IAM alone)	IAM alone is insufficient for cross-account publish
Monitor `NumberOfNotificationsFailed` in CloudWatch	Alerts you to delivery failures before they become data-loss events

🎓 Exam Insight

Cross-account SNS publish → requires a topic policy allowing the external account, not just IAM
Messages silently dropped? → configure DLQ on the subscription
Compliance / encryption at rest → enable SSE with KMS on the topic
Consumer down, messages lost from SNS? → add SQS queue between SNS and the consumer

Reference

Pricing & Cost Optimization

SNS Pricing Components Core

Component	Price	Notes
API requests	$0.50 / 1M requests	Publish, Subscribe, Unsubscribe all count
Data transfer out (to internet)	Varies (~$0.09/GB)	SQS/Lambda delivery within AWS = free
SMS (USA)	~$0.00645 / message	Transactional tier; promotional is cheaper
Email / Email-JSON	$2.00 / 100,000 notifications	Direct SNS email; use SES for high volume
FIFO topics	Same as Standard	No price premium for FIFO

Monthly Cost Examples Introductory

Workload	Messages/Day	Approx. Monthly Cost
Small app notifications	10,000	~$0.15
Medium e-commerce (3 subscribers)	1,000,000	~$45 (3M deliveries)
Large IoT telemetry (2 subscribers)	50,000,000	~$1,500
SMS alerts (US, 10K/day)	10,000 SMS	~$1,900 SMS + $15 API

Cost Optimization Core

📦

Batch Publishes

Use PublishBatch API (up to 10 messages per call). Reduces API requests — and cost — by 90% for high-volume publishers.

🔍

Use Filter Policies

Fewer deliveries = fewer Lambda invocations and SQS receives. Filter evaluation is free — only matching deliveries cost money.

🌍

Minimize Cross-Region

Publish in same region as subscribers. Cross-region data transfer adds egress charges on top of SNS API costs.

Amazon SNS · Complete

SNS is a managed pub/sub service — one publisher, many subscribers, push-based fan-out
Core building blocks — Topic, Publisher, Subscriber, Message (256 KB), Filter Policies with JSON attribute matching
FIFO topics — strict ordering, 300–3,000 msg/sec, SQS FIFO subscribers only, no filter policies
SNS + SQS fan-out is the gold-standard pattern — SNS broadcasts, SQS adds durability and retry
SNS vs SQS vs EventBridge — broadcast vs buffer vs route; they complement each other
Use cases — order pipelines, CloudWatch alarms, microservice events, CI/CD, security alerts
Reliability — retries per subscriber type, DLQ, CloudWatch metrics (NumberOfNotificationsFailed), delivery logging
Security — IAM + topic policies, cross-account requires both, SSE (KMS), VPC Endpoint for private subnets
Cost — $0.50/1M API requests; batch publishes + filter policies = key optimizations

What is Amazon SNS

Tightly Coupled (Bad)

Loosely Coupled with SNS (Good)

Radio Broadcast

Newsletter

Push Notification

Decoupling

Scalable Communication

Event-Driven Architecture

Core Messaging Concepts

Topic

Publisher

Subscriber

Message

What counts toward 256 KB

Character encoding

If you exceed 256 KB

One Publish Call

Parallel Delivery

Independent Processing

Throughput

Hard Restrictions

Without Filters

With Filter Policies

Match by string value

Numeric comparison

AND logic (multi-key)

Prefix & exists checks

How SNS Works in AWS Architecture

SQS Queue

Lambda Function

HTTP / HTTPS Endpoint

Email / Email-JSON

SMS

Kinesis Firehose

Email Subscription Limits

SMS Best Practices

Without SNS — Direct Calls

With SNS — Event Bus

SNS + SQS Fan-Out Architecture

SNS — Broadcasts

SQS — Buffers

Decoupling

Independent Scaling

Retry Isolation

Durability via SQS

SNS vs SQS vs EventBridge

SNS

SQS

EventBridge

Choose SNS when…

Choose SQS when…

Choose EventBridge when…

Real-World Use Cases

Scenario

Architecture

Scenario

Architecture

Scenario

Architecture

CodePipeline → SNS

SNS → Email

SNS → Lambda

Scenario

Architecture

Security & Reliability

IAM Policies

Topic Policies (Resource Policies)

Account B — Topic Policy (owner)

Account A — IAM Role Policy (producer)

Encryption at Rest (SSE)

Encryption in Transit

Benefits

Setup Steps

Recommended Alarm

Enable Delivery Status Logging

What SNS Does NOT Do

Design Patterns to Compensate

Pricing & Cost Optimization

Batch Publishes