Amazon SNS (from AWS)

Are you considering using Amazon Simple Notification Service (SNS) in production? Looking to learn about the service’s pros and cons and how it compares to other solutions? Curious what the total day-to-day cost of using SNS might be?

If you answered yes to any of those questions, this article is for you. In addition to the topics mentioned above, we’ll provide helpful information such as what Amazon SNS actually is and how it works, why SNS is important for the Serverless ecosystem, and what the alternatives are to using SNS in your applications.

Scroll to the bottom of the article to find a few examples of using SNS with Serverless Framework and pointers to some documents to help you get started with SNS.

What is Amazon SNS?

Amazon SNS is a managed publish/subscribe (also known as “pub/sub”) service from Amazon Web Services. The fundamental idea of a publish/subscribe system is to allow communication between systems that are not directly connected by having one side publish messages to a shared location, called a “topic” in SNS, and having the other side subscribe to the messages from this location.

SNS provides an HTTP API over which messages can be published to an SNS topic. Among the subscriber types SNS supports are AWS Lambda functions, SQS queues, HTTP(S) endpoints using webhooks, email, and SMS.

SNS is most useful for sending notifications of various events that happen in your AWS-hosted applications and for distributing information between different services in a microservice-oriented infrastructure.

The main difference between Amazon SNS and Amazon SQS is that SNS implements a “push” architecture—all subscribers receive the messages that are published to a topic, while SQS implements a “pull” architecture, in which clients pull messages from a shared queue.

How does SNS work?

‍
Every SNS topic has a set of subscriptions. Once a message is published to a topic, SNS handles distributing the message to all its subscribers. The subscribers can be AWS Lambda functions and SQS queues, mobile push notifications (including iOS, macOS, Android, and Windows devices), HTTP(S) endpoints, email addresses and mobile phone numbers capable of receiving SMS messages.

To publish a message to an SNS topic, a message producer must use the SNS HTTP API. Once the message is published, all subscribers receive a copy of the message over the channel through which they established their subscription.

Each subscriber can receive messages from multiple topics and apply filters to topics in order to receive only the most relevant messages. If a message can’t be delivered to a subscriber right away, SNS will retry its delivery a number of times with varying intervals between attempts. SNS runs in multiple availability zones in AWS, guaranteeing that all messages are sent and received correctly even if one of AWS’ datacenters is experiencing downtime.

Why is SNS an essential part of the Serverless ecosystem?

‍
The pub/sub model that SNS implements is useful for creating system and application alerts, sending email, SMS and push notifications, and for fanning information out from one system to multiple other systems, all using a fully managed service that requires no maintenance.

This functionality is essential in Serverless applications for both user-facing and internal notifications and automations, and therefore for building scalable and reliable Serverless systems.

How does SNS integrate with other AWS services?

‍
Both AWS Lambda functions and Amazon SQS queues can subscribe directly to SNS topics with no need for any additional code.

Associating a Lambda function with an SNS topic causes the function to run for each message published to the topic.

If an SQS queue subscribes to an SNS topic, the contents of each SNS message is added to the SQS queue. This is useful for sending messages from one source into multiple queues: for example, if you’d like to send a notification about a shipped order both to your fulfilment queue and your analytics queue.

Other integrations for SNS include Amazon X-Ray and Amazon CloudWatch, both of which are useful for obtaining insights into your SNS usage and debugging potential issues.

How does SNS work with the Serverless Framework?

‍
SNS works with Serverless in three ways. First, you can configure an SNS event in your Serverless function. This uses the integration between AWS Lambda and SNS and runs your Serverless function for each message (or group of messages) that is sent to the SNS topic.

Second, you can use the Resources construct to manage the details of your SNS topics as well as the permissions of all users and applications accessing SNS in code.

Finally, the Serverless Framework Notifications provides a native SNS integration that sends SNS notifications for all alerts generated within your Serverless applications.

Benefits of using SNS

‍
These are the main benefits of using SNS in Serverless applications.

Scalability. SNS topics scale up to any number of publishers, subscribers and messages without your needing to do any infrastructure work. This is helpful for growing applications where the teams would rather not have to provision additional infrastructure as their usage of pub/sub model increases over time.

Ease of setup. SNS is a fully managed service; setting it up requires zero infrastructure work. Initial ramp-up is also easy as SNS provides an HTTP API that conforms to API standards. With plenty of subscriber types supported out of the box, topic subscribers are unlikely to require any further setup either. SNS’s ease of setup means you will have a faster path to a proof-of-concept application or to a fully implemented solution.

Multiple notification formats supported. SNS supports AWS Lambda and AWS SQS notifications as well as mobile push notifications, HTTP(S) endpoints, email addresses, and SMS messages. These formats cover many common use cases, so you won’t have to write custom code to implement a subscriber for your SNS topic.

Integration with AWS Lambda. The native integration with AWS Lambda allows you to run a Lambda function every time a message is published to an SNS topic. This allows for many useful workflows that process data from SNS messages, such as reacting to notifications from other systems or preparing the data for storage in S3 or Redshift.

Drawbacks of using SNS

‍
Using SNS does have the following limitations that you should be aware of before choosing to use SNS in production:

High cost at scale. When using SNS, you pay for exactly what you use. This can be both positive and negative. The upside is that there are no monthly charges—if you use SNS for just one day of the month, you pay only for that one day. On the downside, however, with a high number of topics, subscribers, and messages the costs of SNS can eventually rise quite high, and operating your own infrastructure for SNS-like load may be more cost-effective in such cases.

Not much control over performance. SNS is a fully managed service; as a result, you don’t get to look under the hood. This can be a problem if SNS is a part of your customer-facing response path or if you have certain SLAs to meet. While for many use cases SNS performance is plenty good enough, at a certain stage you will likely be able to get better and more predictable performance from a pub/sub system that you manage yourself and tweak to your needs compared to what SNS can offer at scale.

What is SNS used for?

‍
Here are a few of the common SNS use cases for Serverless applications.

Sending events to mobile clients via p**ush notifications** Mobile push notifications can be useful for sending secure, time-sensitive updates to your users. Push notifications usually rely on a service that maintains a connection between each mobile device subscribed to the notifications and sends any incoming app notifications to the end users. While Amazon doesn’t run a service that actually sends the app notifications for you, it does allow you to plug into SNS the following push notification services:

• Amazon Device Messaging (ADM) for Amazon devices
• Apple Push Notification Service (APNs) for both iOS/iPadOS/tvOS/watchOS and macOS devices
• Baidu Cloud Push (Baidu): multi-platform
• Firebase Cloud Messaging (FCM): Android, iOS, web, and desktop
• Microsoft Push Notification Service for Windows Phone (MPNS)
• Windows Push Notification Services (WNS): Universal Windows Platform applications

If you are using any of these services, you can assign them in SNS as a subscriber to a topic.

Sending events between system elements that don’t require exactly-once processing While Amazon SQS, a related AWS service, is a good fit for distributing work in units that need to be performed exactly once, SNS is a better option for distributing the information across systems where exactly-once delivery isn’t as important.

One-to-many notifications In using different queueing systems, you might find that you need to send a message into multiple read-once queues. For example, if you run an e-commerce store, you might have each order trigger notifications to both the order tracking system and the analytics system by using Amazon SNS. Imagine also that, for each of those downstream systems, you want to ensure that the work isn’t performed multiple times—for example, that the same order isn’t counted twice on two separate analytics servers.

A common solution for such cases is to use SNS with two SQS queues as subscribers. SQS guarantees that each message is only processed once, and SNS allows you to send the same message to multiple clients. This type of solution results in data being propagated to all relevant systems, while also ensuring that the work in each downstream system is only performed once.

Sending transactional email or SMS notifications Many companies need to keep their customers up to date on what’s happening with their accounts, orders, posts, and so on. A notification sent when an action is completed in the company’s system is frequently called a “transaction message”. SNS is a good choice for sending this kind of message with its email, push, and SMS capabilities.

When to use SNS vs. SQS?

‍
While SNS and SQS are related, they serve different purposes.

SQS is a queuing system. The tasks it excels at are maintaining a queue of messages and ensuring that each message is successfully pulled from the queue exactly once. As a result, SQS requires polling for items—”pulling” data, where it’s the responsibility of the client to request the data it is ready to process.

On the other end, SNS is a publish/subscribe system. The task for which it was designed is to send all the messages it receives to each of its many subscribers. SNS follows the “push” principle, where it’s system’s responsibility to make sure all subscribers are notified of the new message. No polling on the part of subscribers is required.

In some cases you might want to use only one of these services, sometimes using SQS together with SNS can be a good option, as in the one-to-many use case.

Amazon SNS limits

‍
SNS has a few limits that you should be aware of when designing a system that uses SNS in production.

The delivery rate for email messages has an upper limit of 10 messages per second. If you’d like to send more emails than that, consider using a dedicated email service for that task—for example, Amazon SES in combination with a Lambda function.

Both subscribe and unsubscribe transactions are limited to 100 transactions per second (per AWS account).

The Publish API, the core API for publishing SNS messages, will be throttled at the following levels:

• 30,000 calls/second in the us-east-1 region
• 9,000 calls/second in the us-west-1 and eu-west-1 regions
• 1,500 calls/second in the ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1, us-west-1 regions
• 300 calls/second in other AWS regions

APIs for creating/deleting topics, confirming subscriptions, and getting subscription attributes (among others) are limited to:

• 3,000 calls/second in the us-east-1 region
• 900 calls/second in the us-west-1 and eu-west-1 regions
• 150 calls/second in the ap-southeast-1, ap-southeast-2, ap-northeast-1, eu-central-1, us-west-1 regions
• 30 calls/second in other AWS regions

See the AWS documentation on SNS service limits for more details.

Amazon SNS pricing

‍
As part of the AWS free tier, SNS usage up to one million requests, 100 SMS messages, 1,000 emails, and 100,000 HTTP(S) calls is free for all AWS accounts. This applies even if your AWS account was created more than 12 months ago (some AWS services only offer a free tier for the first 12 months of a new account, but this is not the case for SNS).

Beyond the free tier you are charged for the following aspects of using the service:

‍

Aspect
Pricing
Comment

 Publish action
 $0.50/1 million requests
 Each 64KB of request payload count as one request. So a “publish” action with a 256KB payload will be charged as four requests.

 Mobile push notifications
 $0.50/1 million requests
 

 SMS messages sent
 Pricing depends on the country
 $0.00645/message in the US, up to $0.15407/message in Germany. See details in SNS SMS pricing.

 Email notifications
 $2.00 per 100,000
 

 HTTP(S) notifications
 $0.60 per million
 

 Data transfer: public internet
 $0.09/GB
 Data transfer is tracked monthly. The cost goes down to $0.085 per each additional GB after 10TB of data transfer in a given month, $0.07/additional GB after 50TB, and $0.05/additional GB after 150TB/month.

 SQS and Lambda calls
 Free
 These are charged at SQS and Lambda rates. See SQS and Lambda pricing for details.

‍

Sample pricing scenario Imagine that you are running a production system with 100,000 daily active users. Each user results in 500 SNS messages sent using the Publish API per day, 5 push notifications, 3 emails and 1 HTTP notification on average. Let’s assume that each outgoing notification of each type is 8KB in size.

For this use case your daily SNS charges will be approximately:

Publish API: 100,000 users (500 messages/day / 4 messages/API call) $0.50/1 million requests = 12,5M requests $0.50/1M requests = $6.25/day Mobile push notifications: 100,000 users 5 push notification/user $0.50/1M notifications = 500,000 notifications $0.50/1M notifications = $0.25/day Emails: 100,000 users 3 emails/user $2.00/100,000 emails = 300,000 emails $2.00/100,000 emails = $6/day HTTPS notifications: 100,000 users 1 notification/user $0.60/1M notifications = $0.06/day Data transfer: (500,000 push notifications + 300,000 email notifications + 100,000 HTTPS notifications) 8KB/notification $0.09/GB = 7.2GB $0.09/GB = $0.65/day

The total per day would be $13.21, and the monthly total would be $396.30.

Amazon SNS alternatives

‍
In this section we cover alternatives to using SNS. These are services or software products that are better suited to a particular task than SNS or that have another advantage.

Amazon Kinesis Data Streams Amazon Kinesis Data Streams is a managed AWS service that’s designed for high-volume near-real-time data intake. Kinesis Data Streams can be a good choice if you produce large amounts of data that must be processed in batches in near real-time. For example, you could use Kinesis Data Streams to collect all the events happening in your systems for analytics purposes and process them with Lambda functions.

While Kinesis Data Streams can scale to hundreds of data sources and gigabytes of data processed per second, compared to SNS it is usually harder to use for simpler tasks like sending messages between different parts of your systems. Kinesis Data Streams requires using special libraries for both consumers and producers of streams, as opposed to the simple HTTP API in SNS and its many out-of-the-box supported subscriber types. Kinesis Data Streams also requires that you consider different aspects of performance by configuring the number of shards in each Kinesis stream.

Amazon MQ Amazon MQ is a managed queue service from AWS which is based on Apache ActiveMQ. Amazon MQ’s design is closer to Amazon SQS than to SNS; it’s a good fit for applications that already use ActiveMQ and want to move to the cloud without changing any queue-related code.

If you don’t use ActiveMQ, however, SQS and SNS would generally be a better fit as they both have simpler APIs which make them easier to work with, not to mention that they are more cost-effective with their pay-per-use pricing models, and they integrate better with other AWS services like AWS Lambda.

Apache Kafka Apache Kafka is an open source stream processing system. Its main purpose, similar to AWS Kinesis, is to process large amounts of data in near-real time. It has the same advantages and disadvantages as Kinesis Data Streams when compared to SNS: on the one hand, it can process a very large number of messages; on the other, it requires much more configuration and maintenance and is harder to use for producers and consumers than SNS.

Twilio Twilio is a communication API company that offers a simple API to send emails and SMS messages. While it doesn’t integrate with SNS or other AWS services, Twilio can be a good alternative if what you’re looking for is primarily transactional email and SMS notifications.

Pusher Pusher is a managed real-time notifications service. It focuses on push notifications and WebSockets-based data streaming. The main focus of Pusher’s product is real-time in-app updates, for example, on the front end of your applications. Pusher offers convenient client-side libraries that make it easy to implement real-time features without writing backend code. While it’s possible to use SNS for the same purpose, SNS doesn’t offer WebSockets support and isn’t optimized to be used on the client side. So if you are looking to create real-time updates in the frontend of your application, Pusher might be a better choice.

PubNub PubNub is a managed real-time pub/sub service. In addition to basic pub/sub functionality, PubNub offers features like channel groups (in which a subscriber can receive the updates to a group of channels) along with user online status tracking and archival storage and retrieval of past pub/sub updates.

PubNub doesn’t support email or SMS notifications out of the box, and it also lacks integration with AWS services. It does, however, support mobile push notifications to multiple platforms.

Many of PubNub’s differentiating features involve compliance, archiving, and tracking of past streams. If you are building an application that calls for the pub/sub model and also carries significant compliance requirements (for example, in the medical industry), PubNub might be a better choice than SNS.

Amazon Pinpoint Amazon Pinpoint is a customer engagement solution from AWS. It can send email, SMS, push notifications, and voice messages. This service works well with other AWS services like S3 and AWS Lambda through its integration with AWS Kinesis.

The purpose of this service is to simplify management of user engagement campaigns that employ email, SMS, and push notifications. Pinpoint provides a number of features for managing such campaigns. SNS, in contrast, is a more generic messaging service. If you are looking for a way to send user engagement-related messages, Pinpoint might be a better choice than SNS.

Amazon SNS FAQ

‍
Can SNS trigger Amazon Lambda functions? Yes. Lambda functions can subscribe to SNS topics, and the Lambda function will be triggered when there are new messages in the SNS topic.

Can SNS send emails? Yes, SNS supports email, SMS, push notifications, and passing messages to Amazon SQS. However, the throughput of email notifications sent through SNS is limited to 10 emails per second across your entire AWS account. If you’re looking to send higher frequency email notifications through SNS, consider using SNS with an AWS Lambda function, which in turn uses the email-specific AWS SES service to send emails at scale.

Is Amazon SNS free? No, but it offers a free tier for the first one million processed messages. This free tier should be enough for you to experiment with the service. See the Pricing section for more details.

Is Apache Kafka the same as SNS? No. These two solutions serve different use cases. SNS is used for communication between two systems or between an application and its end users. SNS focuses on short (a few KB) self-contained messages and operates at the granularity of one or a few messages (rather than streams of data) when it comes to sending messages to clients. It works with multiple channels like email and push notifications. SNS requires no setup and very little ongoing maintenance, but its throughput at scale is limited and can’t be tweaked or optimized.

Kafka is a product that’s best used for streaming and processing large volumes of data. You have to use Kafka streaming libraries on both the sending and receiving ends, and of course you’ll need to manage your own Kafka cluster and scale it according to usage. In a Kafka stream, you can’t mark a specific message as read or received without also marking all the previous messages in the stream as read.

SNS is generally a better choice if what you’re looking for is a low-maintenance, easy-to-use pub/sub system. If you have a use case that focuses on streaming data at very high volumes, then Kafka is likely a better fit.

Using SNS with Serverless Framework

‍
If you’d like to learn more about using Amazon SNS with the Serverless framework, check out the following guides:

You can find more details about SNS in the following documentation pages: