What is Amazon SNS?
Amazon Simple Notification Service (SNS) is a highly scalable, fully managed messaging service that enables application-to-application (A2A) and application-to-person (A2P) communication. It operates on a publish/subscribe model, where a single message can be "fanned out" to a large number of subscribers simultaneously. This decouples the systems that produce events from the systems that consume them, increasing the overall scalability and resilience of an architecture.
Core Concepts
SNS is built around three primary components:
-
Publisher (Producer): An entity that generates messages (also called events or notifications) and sends them to an SNS topic. This could be an application, an AWS service (like CloudWatch or S3), or an administrator.
-
Topic: A logical access point and communication channel. A topic is the central hub where all messages are sent. Publishers send messages to a topic, and SNS then delivers those messages to all subscribed endpoints.
-
Subscription: An endpoint that is subscribed to a topic. When a message is published to the topic, SNS automatically delivers a copy of that message to every subscription. Each subscription has a specific protocol (e.g., SQS, Lambda, HTTPS).
The Fanout Pattern Explained
The "fanout" pattern is the most common use case for SNS and is fundamental to its design. It works as follows:
-
A single message is published to an SNS topic.
-
SNS immediately "fans out" and pushes a copy of that message to multiple subscribers in parallel.
-
Each subscriber processes the message independently.
This pattern is incredibly powerful for decoupling microservices. For example, when an e-commerce order is placed, a single OrderCreated
event can be published to an SNS topic. This one event can then trigger:
-
An AWS Lambda function to process the payment.
-
An Amazon SQS queue for the shipping department to prepare the package.
-
An HTTPS endpoint to update a third-party analytics service.
-
An email notification to the customer.
SNS Topic Types: Standard vs. FIFO
SNS offers two types of topics to suit different application needs.
Standard Topics (Default)
-
Ordering: Provides best-effort ordering. The order in which messages are delivered is not guaranteed to be the same as the order in which they were published.
-
Delivery: Provides at-least-once delivery. A message will be delivered at least once, but occasionally, a duplicate copy of a message might be delivered.
-
Throughput: Offers nearly unlimited throughput.
-
Use Case: Best for high-throughput applications where message order and exact-once delivery are not critical, such as logging, real-time analytics, and fanout to non-critical systems.
FIFO (First-In-First-Out) Topics
-
Ordering: Provides strict, first-in-first-out ordering. Messages are delivered to subscribers in the exact order they were published. This is achieved using a Message Group ID.
-
Delivery: Provides exactly-once delivery. Duplicates are never introduced.
-
Throughput: High throughput, but lower than standard topics.
-
Subscribers: Primarily designed to work with Amazon SQS FIFO queues.
-
Use Case: Essential for applications where message order is business-critical, such as financial transactions, inventory management, or maintaining data consistency across distributed systems.
Key Features
-
Diverse Subscribers (Endpoints): SNS can deliver messages to a wide array of targets:
-
Amazon SQS: The most common pattern for durable, asynchronous processing.
-
AWS Lambda: For serverless, event-driven compute.
-
HTTP/S Endpoints: To integrate with webhooks and custom APIs.
-
Email / Email-JSON: For human-readable notifications.
-
SMS Text Messages: For application-to-person alerts.
-
Mobile Push Notifications: For iOS, Android, and other mobile platforms.
-
Amazon Kinesis Data Firehose: To stream messages to data lakes and warehouses.
-
-
Message Filtering: Subscribers can define a filter policy (a JSON object) to specify which messages they want to receive. When a message is published with attributes, SNS compares those attributes to the filter policy of each subscriber. If there's a match, the message is delivered; otherwise, it's discarded for that subscriber. This avoids unnecessary processing and cost.
-
Message Durability: SNS is designed for durability. Messages are stored across multiple Availability Zones (AZs). If a subscriber endpoint is unavailable, SNS will perform retries with a backoff policy to ensure the message is delivered. For critical applications, subscribing an SQS queue to an SNS topic provides maximum durability, as SQS can retain the message until it is successfully processed.
Security
-
Encryption:
-
In-Transit: Messages are encrypted using TLS.
-
At-Rest: SNS supports server-side encryption (SSE) using AWS Key Management Service (KMS) keys. You can use an AWS-managed key or your own customer-managed key (CMK) for an extra layer of security.
-
-
Access Control:
-
IAM Policies: Use identity-based policies to control which users or roles can perform SNS actions (e.g.,
sns:Publish
). -
Resource-Based Policies (Topic Policies): Attach policies directly to an SNS topic to define which AWS accounts, services, or users can publish to or subscribe to that specific topic. This is essential for cross-account access.
-
Common Use Cases
-
Microservice Decoupling: The primary use case. Allow services to communicate asynchronously without being aware of each other.
-
Parallel Processing: Fan out a task to multiple worker systems simultaneously to reduce processing time.
-
Real-time Alerts & Monitoring: Send immediate notifications based on CloudWatch alarms, system health events, or application errors.
-
Mobile & Web Push Notifications: Engage users by sending timely alerts and updates directly to their devices.
-
Data Replication: Replicate data across different systems or AWS regions. For example, publish an event when data is written to a database, and have subscribers in other regions consume that event to update their own copies.