In this series of posts, we have already talked about SQS and EventBridge, let’s now discuss SNS: Simple Notification Service.
SNS is often compared to EventBridge since they seem to provide many similar features.
Fundamentally however, while EventBridge is a general purpose Event Bus, SNS is a Pub/Sub messaging system.
The main difference here is that an event bus typically supports many different message types, while with pub/sub, you create dedicated topics for every message type. A producer will create messages and publish them to a specific topic. Consumers subscribe to topics and receive messages asynchronously.
The main similarity between SNS and EventBridge is that both systems can be used to implement one-to-many messaging patterns (fan-out).
SNS has been around since 2010 and has evolved quite a lot since then. It targets both A2A (Application to Application) and A2P (Application to Person) communication. We typically think of a pub/sub system as being for communication between systems but the A2P features of SNS allow you to send messages to people by email, SMS or mobile push notification.
SNS’ main advantage is in its speed of delivery. The message delivery is typically less than 100ms and it is push-based, so you do not have to poll for messages.
Where do you use SNS?
SNS could be used in a variety of cases. Let’s discuss a few examples:
- SNS is a valid alternative to EventBridge for communication between applications or microservices. You get the benefit of better latency guarantees, but will lose out on some of EventBridge’s additional features and flexibility. More on that below!
- If you have an event-based fan-out pattern requirement for your architecture, where a single message should be delivered to multiple consumers, SNS allows you to create multiple subscribers. Each subscriber could be an SQS queue, adding the benefit of durability.
- SNS is very commonly used for handling system alerts. Examples include CloudWatch Alarms, CodePipeline notifications and Config rule compliance changes. In these cases, the subscriber could be email-based, a custom Lambda handler, or AWS ChatBot, a service that will forward supported messages to Slack.
How do you use SNS?
There are three steps to using SNS when starting from scratch:
- Create a topic for a specific message type.
- Create a subscription. This could be an HTTP endpoint, A2P subscription like SMS or email, or any of the support AWS service integrations like Lambda, Kinesis Firehose. When using an HTTP endpoint or email subscription, the subscription needs to be confirmed before it can receive messages.
- Finally, publish one or more messages to the topic using the Publish or PublishBatch API.
For security, you can configure an Access Policy. This policy can allow users or systems to publish or subscribe to a topic. It can also be used to limit the type of protocols in a subscription (e.g., HTTPS only) and it can authorise SNS itself to send messages to a given SQS queue.
SNS Standout Features
When we covered EventBridge, we highlighted the advantage of pattern matching support for rules. SNS has a similar capability called Message Filtering. The important distinction is that SNS message filters are applied to message attributes but not message content. This means that you cannot filter on any property but instead, you must ensure that any filterable message metadata is included along with the message when you publish it.
Limits and Pricing
In terms of limits, SNS will scale to any imaginable use case, with 12.5 million subscriptions supported per topic and a limit of 100.000 topics (standard) and 1.000 FIFO topics per account! There is a cost advantage too, with the current $0.50 USD per 1 million SNS requests representing half the cost of EventBridge. There are additional costs for HTTP, email and SMS messages.
SNS integration with SQS
SNS is a close relative of SQS and they are often paired together in event-driven architectural patterns. SQS subscribers add durability and a ‘load-balancing’ effect for consumers since messages are retained in the queue, giving a chance for consumer nodes to come online or scale up. If you are using SQS FIFO queues (something we covered in the SQS article), you can now use SNS FIFO topics with them too, guaranteeing ordering while using SNS to fan out to multiple queues. Lastly, SNS also lets you set up an SQS dead letter queue (SQS) for undelivered messages too.
How does SNS compare to EventBridge?
- SNS requires you to create topics in advance. With EventBridge, you can publish messages without any up-front resources.
- SNS subscriptions are bound to a topic but EventBridge rules are only tied to a bus, which is a broader resource.
- With SNS, it’s normal for consumers to receive all messages in a topic. We did mention the ability to apply message filters, but that’s limited to metadata so it’s not as powerful as EventBridge pattern rules.
- EventBridge integrates with many more AWS services. SNS, on the other hand, can target SQS, Lambda, Kinesis Data Firehose, HTTPS endpoints, SMS, mobile push and email.
- SNS automatically retries failed deliveries and it can be configured to deliver failed retry attempts to a Dead Letter Queue (DLQ). EventBridge supports the same capabilities but, in addition, it offers customisable retry policies and the ability to persistently archive events. Archived events can also be replayed. Events archival and retry are a major features for complex systems that heavily rely on events. So if you need these features, you would be better off choosing EventBridge over SNS.
Our general rule of thumb for selecting services in this category is to first opt for EventBridge. If you need any of the A2P consumers, or the performance requirements of your application require you to push for two-digit millisecond latency, then SNS is a worthy replacement!In our AWS Bites podcast, we covered all of the main AWS event services in depth as well as a special episode where we cover the pros and cons of each. Check out the Event Services Playlist and let us know what you think in the comments section.