Back to: AWS-Basics-Advanced

🌐 Amazon SNS (Simple Notification Service) – Complete Tutorial with Real-World Example

In modern cloud architectures, services should not talk to each other directly. Instead, they should communicate using events.
This is exactly where Amazon SNS (Simple Notification Service) shines.

Let’s understand SNS from basics to real-world routing with SQS 🚀

---

📌 What is Amazon SNS?

Amazon Simple Notification Service (SNS) is a fully managed pub/sub (publish–subscribe) messaging service.

👉 It allows a producer to publish a message once, and SNS fan-outs that message to multiple subscribers.

Simple definition:

SNS helps you send messages to many systems at the same time without tight coupling.

---

🧠 Core Concepts of SNS

1️⃣ SNS Topic

A Topic is a logical access point where messages are published.

• Producers publish messages to a topic

• Subscribers receive messages from the topic

📌 Think of a topic like a radio channel — anyone tuned in hears the broadcast.

---

2️⃣ Types of SNS Topics

SNS supports two types of topics:

🔹 1. Standard Topic

• At-least-once delivery

• Messages may arrive out of order

• High throughput

• Supports:

  • SQS (Standard)

  • Lambda

  • HTTP/HTTPS

  • Email, SMS

✅ Best for notifications, alerts, fan-out events

---

🔹 2. FIFO Topic

• Exactly-once delivery

• Message ordering guaranteed

• Lower throughput compared to Standard

• Can publish only to FIFO SQS queues

✅ Best for financial, order, payment workflows

---

📌 What is a Subscription?

A subscription connects a topic to an endpoint.

Examples of endpoints:

• SQS queue

• Lambda function

• HTTP/HTTPS endpoint

• Email / SMS

📌 SNS pushes messages to subscribers automatically.

---

🧠 SNS Message Flow (High Level)

---

📌 Real-World Use Cases of SNS

SNS is widely used for:

• 🔔 Application alerts & notifications

• 🧾 Order & payment event processing

• 🔄 Microservices communication

• 📊 Fan-out architectures

• 🚨 CloudWatch alarms

• 📩 Decoupling services

---

🎯 Real-World Scenario: ORDER & PAYMENT Events

Problem Statement

You have:

• One application publishing events

• Two SQS FIFO queues:

  • Order Queue

  • Payment Queue

Requirement:

• If event is ORDER → send to Order SQS

• If event is PAYMENT → send to Payment SQS

---

🏗 Architecture Design

---

🛠 Step 1: Create SNS FIFO Topic

1. Go to SNS → Topics

2. Click Create topic

3. Type: FIFO

4. Topic name:

   order-payment-topic.fifo


5. Enable:

   • Content-based deduplication (optional)

---

🛠 Step 2: Create SQS FIFO Queues

Create two queues:

🔹 Order Queue

🔹 Payment Queue

---

🛠 Step 3: Subscribe SQS to SNS Topic

🔹 Subscribe Order Queue

• Protocol: Amazon SQS

• Endpoint: order-queue.fifo

Filter policy:

---

🔹 Subscribe Payment Queue

• Protocol: Amazon SQS

• Endpoint: payment-queue.fifo

Filter policy:

📌 SNS filtering works ONLY on message attributes, not message body.

---

🚨 Important Rule (Very Important!)

❌ SNS does NOT filter using message body
✅ SNS filters using Message Attributes

---

🛠 Step 4: Publish Message with eventType Attribute

Example: ORDER Message

Message Body

Message Attribute

➡️ Message goes to Order Queue only

---

Example: PAYMENT Message

Message Body

Message Attribute

➡️ Message goes to Payment Queue only

---

🔐 Required: SQS Queue Policy

Each SQS queue must allow SNS to send messages.

Example:

📌 AWS console usually auto-adds this when subscribing.

---

🧠 Why This Design Is Powerful

• ✅ Loose coupling

• ✅ Easy scalability

• ✅ Clean event routing

• ✅ Supports retries & DLQs

• ✅ Production-ready pattern

---

🔚 Summary

---

🎓 Final Trainer Tip

SNS decides routing using message attributes, not JSON body
This single line saves hours of debugging 😄