How To Use Amazon SNS to Decouple Components In Cloud Architectures

Decoupling components in your cloud architecture is important to minimize the scope of changes and reduce dependencies between them. By using Amazon SNS, you can easily create topic-based publish/subscribe messaging that allows for the decoupling of components. This means that components can communicate with each other without knowing about the existence of other components. Additionally, Amazon SNS also supports fan-out messaging, which allows for messages to be sent to multiple endpoints simultaneously.

What is Amazon SNS

Amazon Simple Notification Service (SNS) is a fully managed pub/sub messaging service by Amazon Web Services. It allows you to decouple components in cloud architectures, enabling asynchronous communication. With SNS, applications can send messages to multiple subscribers through various protocols like email, SMS, HTTP/S, and more. The greatest benefit is that publishers and subscribers are unaware of each other, meaning there are no dependencies between them.

The SNS service supports topic-based publish-subscribe messaging and fanout messaging to multiple subscribers simultaneously, letting you add or remove subscribers freely. It has fantastic integrations with other AWS services, and also lets you send mobile push notifications and do message filtering.

Key Components of Amazon SNS

These are the key elements of SNS:

• Publishers: These are the components that send messages. They can be your own software components, or AWS services such as CloudWatch Alarms. Any component with the correct IAM permissions can publish a message to a topic, which will be received by all subscribers.

• Subscribers: Subscribers are components that register themselves to receive messages that are sent to a topic. They can be any system that uses a supported protocol, including email addresses, HTTP/HTTPS endpoints (these would be your software components), mobile devices (for push notifications), or even other AWS services such as AWS Lambda. When a component subscribes, an SNS endpoint is created for it. Subscribers don't need to poll a topic for messages, they just subscribe, and when a message is published, they'll receive it. Any component with the correct IAM permissions can subscribe to a topic.

• Topics: Topics are the channels through which messages flow in SNS. They act as a logical point of contact between publishers and subscribers. Topics don't store messages, except for retry logics. Any publisher or subscriber only interacts with the topic, not with any other publishers or subscribers.

• Messages: This is what's being sent. Publishers send messages to topics, and all subscribers that are subscribed to that topic when the topic receives the message will receive a copy of that message.

• Protocols: They are how subscribers will receive messages. SNS supports several different protocols: HTTP, HTTPS, email and mobile push notifications. This gives you flexibility in what (or more specifically how) you can subscribe to SNS.

Types of Amazon SNS Topics: Standard and FIFO

There are two types of topics that you can create in SNS: Standard topics and FIFO topics. Standard topics are the best for general use cases, where ordering of messages is done on a best-effort basis, and are cheaper. FIFO topics, on the other hand, guarantee that messages will be delivered in the exact order that they were received by SNS, but have a lower maximum throughput and a higher price.

Comparing Standard and FIFO Topics

Here's a comparison on Standard and FIFO Topics:

• Throughput: Standard topics support a nearly unlimited number of messages per second. FIFO topics support 300 messages per second or 10 MB per second (whichever is hit first).

• Message Ordering: In Standard topics ordering of messages is done with best-effort, but not guaranteed. With FIFO topics ordering is guaranteed.

• Message Delivery: Messages are delivered at-least once in Standard topics, and they can be duplicated. In FIFO topics, messages are delivered exactly once.

• Types of Subscriptions: Standard topics support Amazon SQS, Amazon Kinesis Data Firehose, AWS Lambda, HTTP, HTTPS, SMS, Email and mobile push notifications as subscribers. FIFO topics only support Amazon SQS queues (both Standard and FIFO queues).

• Limits: You can create 100,000 standard topics with 12.5M subscriptions per topic per account, and 1,000 FIFO topics with 100 subscriptions per topic per account.

• Encryption: Both types of topics support encryption at rest and in transit.

• Use cases: For most use cases of SNS, such as communicating multiple components or alerting, you should use Standard topics. FIFO topics can be used only for fan-out to SQS queues.

Understanding the Role of Amazon SNS in Cloud Architectures

Amazon SNS enables you to implement the Publish/Subscribe architecture pattern via a managed service. This leads to decoupled components communicating asynchronously, which enables better scalability and fault tolerance.

As SNS integrates seamlessly with other AWS services, such as SQS and Lambda, implementing event-driven architectures becomes much easier (designing them is still difficult though). Furthermore, its support for email, SMS and mobile push notifications lets it act as a communication tool that goes beyond just software components.

How does Amazon SNS contribute to decoupling components?

Amazon SNS enables loose coupling between components by allowing them to send and receive messages without knowing each other's details. Publishers publish messages to topics, and subscribers receive notifications based on their subscriptions. Publishers never interact directly with subscribers, and subscribers can be added or removed freely without needing to modify any of the publishers. This lets the components scale independently, and improves maintainability.

Advantages of Decoupling Components with Amazon SNS

Decoupling components with Amazon SNS provides several advantages for cloud architectures. It enhances flexibility and agility by allowing components to evolve independently, leading to faster development and deployment cycles. With decoupling, components can be easily replaced or added without impacting the entire system. Amazon SNS also helps in reducing dependencies, making it easier to test and maintain individual components. Additionally, by decoupling components, failures in one component are isolated from others, thereby enhancing the resilience of the system. These advantages make Amazon SNS an invaluable tool for building scalable and resilient cloud architectures.

Amazon SNS Explained With An Example

Let's consider the following use case: Incident response. We need to detect when an incident is happening, send an email to the person that responds to these incidents, and run some code that mitigates the incident. We're going to have 3 components:

• Alarm: Detects when an incident is happening.

• Notifier: Sends an email to the person in charge.

• Mitigator: Executes automated actions that will (hopefully) mitigate the impact of the incident.

These could be 3 separate components in our code. Alarm could invoke Notifier and Mitigator directly, but then it would be coupled to them. Instead, we can have Alarm publish a message to an SNS topic, where Notifier and Mitigator are subscribed. Then, Alarm doesn't need to know who is subscribed to the SNS topic, it's only concerned with publishing the message to the SNS topic. We're free to add more subscribers, without needing to modify Alarm's code.

This is actually how alerts are implemented for incidents in AWS, such as Disaster Recovery incidents. CloudWatch Alarms replaces the Alarm component, and we can configure an SNS Topic where it will publish a message. Notifier can be replaced by subscribing an email address directly to the SNS topic. Mitigator can be implemented with a Lambda function.

Amazon SNS Use Cases

Saying that SNS decouples publishers and subscribers doesn't say much about when you might want to do that. Here are a few use cases for SNS.

Sending Notifications for Alarms

When a CloudWatch metric reaches a certain threshold, you can configure it to trigger an Alarm. You can set up an SNS topic to have it trigger an automated response, send a notification to different people, and/or other actions. This is a great way to monitor system health and respond promptly to incidents.

Sending SMS Messages with SNS

SNS lets you alerts subscribers via text messaging. You can subscribe mobile phone numbers to an SNS topic, and it will send messages as SMS messages. You can send SMS messages to mobile phone numbers in more than 200 countries, including China. This can be useful for alerting users about certain events in your system. It's not an ideal solution to send one SMS message to one person, since that would require you create an SNS topic dedicated to that person. SNS's role would be to send the same message to a group of people, and its main advantage is that it can use email and SMS.

Triggering Lambda Functions with Amazon SNS

By configuring a Lambda function as a subscriber to an SNS topic, you can automatically invoke the function whenever a new message is published to the topic. This feature is especially useful when building microservices, event-driven applications, or serverless applications in general. It also allows for the automation of responses to infrastructure events, triggered via CloudWatch Alarms.

Fan-out Events in Event-Driven Architectures

Fan-out is a design pattern that simply means sending one single message to multiple components. In event-driven architectures, events flow through the system, and sometimes several actions need to be triggered by the same event. In those cases, the event is fanned out to all the components that need to respond to it, such that each of those components receives a copy of the event. With SNS, you can implement this easily by subscribing all responding components to the same SNS topic. It sounds obvious and trivial, but design-wise it's a big deal in event-driven architectures.

Send Cross-Account SNS Messages

Components and AWS services can subscribe to SNS topics in other AWS accounts. For your own accounts, this lets you send cross-account alerts, such as a Lambda function in the production account responding to a security incident detected by a component running in the security account. For customer accounts (for example when selling a service through the AWS Marketplace), you can also subscribe them to your own SNS topics.

Step By Step Guide to Configure Amazon SNS

This post wouldn't be complete without a step-by-step example of SNS. Here are the steps to set up an SNS topic, subscribe to it, and send a test message:

Step 1: Create the SNS Topic

1. Open the Amazon SNS console

2. In the panel on the left, click Topics

3. Click Create topic

4. For Type, select Standard (it isn't the default)

5. For Name, enter a name for the topic, such as "SimpleAWSTopic"

6. Click Create topic

Step 2: Subscribe an email address

1. Go to the topic you just created

2. Scroll down, and in the Subscriptions tab, click Create subscription

3. For Protocol, select Email

4. Under Endpoint, enter your email address (this isn't data that I have access to)

5. Click Create subscription

6. You will receive a confirmation email. Open it and click the confirm subscription link to confirm the subscription.

Step 3: Publish a Test Message

1. Go back to the topic you just created

2. Click the Publish message button on the top right corner

3. Under Subject, enter a subject for your message, such as "Testing Simple AWS message"

4. Under Message body, enter the body of the message

5. Click Publish message

6. Check your inbox. You should have received an email.

Amazon SNS Pricing

SNS has a free tier that's always-free. Beyond that, you're billed only for usage, based on messages published and delivered. You aren't billed for SNS topics or subscriptions. Here's the pricing page.

This is the pricing for Amazon SNS Standard topics:

• $0.50 per 1 million publish operations (which can publish 1 message, or batch-publish several messages). The first 1 million per month are free.

• $0.50 per 1 million mobile push messages. The first 1 million per month are free.

• $2.00 per 100,000 email notifications. The first 1,000 per month are free.

• $0.60 per million HTTPS notifications. The first 100,000 per month are free.

• Messages to Lambda and SQS are free.

• $0.19 per million notifications to Amazon Kinesis Data Firehose.

For FIFO topics the pricing is a bit simpler, since the only valid subscribers are Amazon SQS queues:

• $0.30 per 1 million publish operations

• $0.017 per GB of payload published

• $0.01 per 1M subscription messages

• $0.001 per GB of payload sent.

Pricing Example of Amazon SNS

Let's imagine we're building an event-driven architecture, where a long-running process publishes a message to an SNS topic, and there are 2 Lambda functions, 1 SQS message queue, and 2 other long-running processes subscribed to it. We'll be using an SNS Standard topic. Let's assume our process publishes an average of 100,000 events per day. 100,000 messages/day * 30 days/month = 3,000,000 events per month. By the way, remember the free tier.

• (3,000,000 - 1,000,000) * $0.50/1,000,000 = $1 for publish operations

• Messages to Lambda and SQS are free

• (2 3,000,000 - 100,000) $0.60/1,000,000 = $3.54 for HTTPS notifications (for the two long-running processes)

• Total cost = $1 + $3.54 = $4.54

Security in Amazon SNS

In-transit encryption is done via HTTPS, as with all calls to AWS services. At-rest encryption is achieved via KMS (not that SNS stores messages for a significant amount of time).

Furthermore, you can use access control policies to manage who can publish messages or subscribe to an SNS topic. AWS IAM is used to grant permissions to apply changes to SNS topics (creating, deleting, modifying the access control policies, etc).

Logging and monitoring is done via Amazon CloudWatch and CloudWatch Logs.

Frequently Asked Questions

AWS SNS vs AWS SQS - What's the difference?

Amazon SNS and Amazon SQS are messaging services by AWS, but they have different purposes. SNS is a pub/sub messaging service that focuses on message distribution to multiple endpoints, while SQS is a message queueing service that prioritizes reliable and scalable message queuing between components. SNS allows push notifications to subscribers, and SQS works via consumers polling for messages. Depending on architecture requirements, either or both can be used. Actually, using both is quite common, with an SNS topic delivering messages to several SQS queues.

How is AWS SQS different for decoupling components?

Unlike Amazon SNS, AWS SQS offers a queuing mechanism that enables asynchronous and reliable message processing. Components can send messages to an SQS queue, which can be retrieved and processed at their own pace. This means components don't need to be active simultaneously, allowing for better fault tolerance. SQS also provides features like message retries and dead-letter queues for reliable message delivery. However, SQS does not support delivering the same message to multiple components. A good option is to use an SNS topic to deliver the message to multiple SQS queues.

When does billing of my Amazon SNS use begin and end?

You're only billed for messages published and sent, not for SNS topics or for active SNS subscriptions. You can create as many SNS topics as you want, subscribe as many endpoints as you want, and if you don't send messages to that topic, you won't be billed. Remember there's a free tier, which means a certain level of usage is always free.

Are there any limitations or drawbacks to using AWS SNS?

While AWS SNS is a reliable and scalable service for decoupling components in cloud architectures, it does have some limitations, mainly on message size and throughput when using FIFO topics. Standard topics don't have those limits, but it can get rather expensive if you make heavy use of it for endpoints other than Lambda functions and SQS queues (which are free). Additionally, while it can send emails and SMS messages, it's intended to send the same message to all subscribers, with no customization options.

How does Amazon SNS ensure message delivery and reliability?

SNS employs retries and exponential backoff to ensure messages are successfully delivered. Additionally, SNS supports dead-letter queues with SQS for undeliverable messages. Multiple availability zones are used to provide high availability and reliability. Fine-grained control over message delivery is achieved through message filtering and topic policies.

What's the difference between Amazon SNS and SES?

Amazon SNS (Simple Notification Service) and SES (Simple Email Service) have different purposes. SNS is used for sending the same message to multiple recipients, supporting various protocols including but not limited to email. On the other hand, SES focuses solely on email delivery, offering features like templates, bounce handling, and spam filtering. They both support JSON in emails.