AWS - SNS

Amazon SNS is a fully managed publish/subscribe messaging service that enables applications, microservices, and users to communicate asynchronously — meaning messages are pushed to all interested subscribers instantly.

In short:

SNS = Publish once, deliver to many subscribers (fan-out)

It decouples services and allows parallel message delivery to multiple endpoints.

---

SNS Key Features

Feature	Description
Pub/Sub messaging	One publisher sends a message to many subscribers simultaneously.
Multiple protocols	Subscribers can be Email, SMS, HTTP/S endpoints, AWS Lambda, or SQS queues.
Fan-out pattern	A single event triggers multiple downstream processes.
High availability	Fully managed, scalable, and reliable (multi-AZ).
Security	IAM + topic policies + encryption with AWS KMS.

---

SNS vs. EventBridge

This is a common AWS interview and design question — let’s break it down clearly:

Feature	Amazon SNS	Amazon EventBridge
Type	Pub/Sub messaging service	Event bus for event-driven architecture
Message Model	Publisher → Topic → Subscribers	Event producer → Event bus → Rules → Targets
Routing Logic	All subscribers get the same message (fan-out)	Rules filter and route events based on content
Supported Targets	Lambda, SQS, HTTP/S, SMS, Email, Mobile	20+ AWS services + SaaS apps (Zendesk, Datadog, etc.)
Filtering	Basic (per-subscription filter policies)	Advanced content-based filtering using JSON pattern
Event Format	Custom message (you define the payload)	Standardized JSON “event envelope”
Delivery	Push-based to all subscribers	Routed to specific targets based on rule conditions
Best For	Alerts, notifications, fan-out processing	Complex event-driven integration across AWS and SaaS
Cost	Cheaper	Slightly higher (charged per event and rule)

In short:

• Use SNS when → you need simple notifications or fan-out (one-to-many).

• Use EventBridge when → you need intelligent routing, filtering, or event-driven workflows.

---

Example Architecture — SNS with Multiple Subscribers

Let’s design a multi-subscriber architecture using SNS:

Scenario: EC2 Monitoring & Alert System

When EC2 CPU utilization > 80%, CloudWatch sends an alert → SNS → multiple subscribers take different actions.

---

Flow:

1. CloudWatch Alarm detects EC2 CPU spike

2. Alarm publishes message to SNS topic → arn:aws:sns:us-east-1:123456789012:EC2-Alert-Topic

3. SNS fans out the message to multiple subscribers:

   • Email subscriber: Notifies sysadmin

   • Lambda function: Automatically scales up EC2 instance count

   • SQS queue: Stores message for audit/log processing

   • SMS subscriber: Sends urgent text alert to on-call engineer

---

Components

Component	Purpose
CloudWatch Alarm	Detects threshold breach and triggers SNS topic
SNS Topic: EC2-Alert-Topic	Central notification hub
Lambda Subscriber	Executes auto-remediation logic (e.g., scale up EC2)
SQS Queue	Stores events for downstream analytics/audit
Email Subscriber	Notifies support engineers
SMS Subscriber	Sends urgent mobile alerts

---

Message Example (JSON Payload)

{
  "AlarmName": "HighCPUUtilization",
  "InstanceId": "i-0abc12345def6789",
  "MetricName": "CPUUtilization",
  "Threshold": 80,
  "CurrentValue": 92.3,
  "Region": "us-east-1",
  "Time": "2025-10-21T14:10:00Z"
}

---

Architecture Diagram (described for PPT/draw.io)

          +----------------------+
          | CloudWatch Alarm     |
          |  (EC2 CPU > 80%)     |
          +----------+-----------+
                     |
                     v
             +---------------+
             |  SNS Topic     |
             | EC2-Alert-Topic|
             +-------+--------+
                     |
     -----------------------------------------
     |            |             |            |
     v            v             v            v
 +---------+  +---------+   +----------+  +----------+
 | Email   |  | Lambda  |   |   SQS    |  |   SMS    |
 | Notify  |  | AutoScale|   | Logging  |  | On-Call  |
 +---------+  +---------+   +----------+  +----------+

---

Cost & Reliability

Feature	SNS
Pricing	~$0.50 per million publishes
Retries	Yes, with exponential backoff for Lambda/HTTP
Durability	Messages stored redundantly across multiple AZs
Monitoring	Integrated with CloudWatch metrics and logs

---

When to Combine SNS + Event Bridge

In modern AWS event-driven setups, they’re often used together:

Example:
EventBridge captures all EC2 events → applies filtering rules → sends to SNS topic → SNS fans out to Lambda + SQS + email.

So you can use EventBridge for filtering/routing and SNS for multi-channel notification delivery.