Amazon EventBridge versus Amazon SNS: What's the difference?

Michael WittigUpdated 27 Nov 2020

Amazon EventBridge (formerly CloudWatch Events) and Amazon SNS provide a way to send events to multiple subscribers. From a high-level perspective, both services are similar. This leads to the question: But how are they different? What advantages do the services have? Should you choose SNS or EventBridge?

EventBridge versus SNS

From time to time, I scroll through major service announcements by AWS. One thing I noticed: EventBridge received four new major features (content filtering, schema registry, DLQs, replay & archival) this year already. SNS received one new feature (FIFO topics) in 2020 so far. On top of that, a nasty SNS bug forced me to look for alternatives. In this post, I present you the options and help you to choose the service for your use case.

SNS Standard

First of all, Amazon SNS comes in two flavors. SNS Standard (which was the only option until October 2020) and SNS FIFO. This section covers SNS Standard. The next section will talk about SNS FIFO.

SNS is a fully managed, publish/subscribe system. You send a message to a topic, and all subscribers to that topic will receive a copy of the message.

SNS

Subscribers are always push-based. For example:

  • SNS invokes an HTTP endpoint
  • SNS invokes a Lambda function
  • SNS sends a message to SQS
  • SNS sends an email/SMS/mobile push

It is not possible to pull messages as with Google’s PubSub.

A message can be any string that is not larger than 256 KB. If you want to filter messages, you have to add message attributes because SNS can not inspect the payload of messages.

It is important to note that messages might be delivered out of order and might be delivered more than once (at least once).

Operating SNS requires that you monitor the NumberOfMessagesPublished metric to be lower than the soft limit. The default soft limit is different for individual regions (in the range of 300 - 30,000). The hard limit is not disclosed.

SNS can be used to implement massive message fanout. A single topic can have millions of subscribers. Keep in mind that if a topic has zero subscribers, the message is sent into a black hole and disappears.

SNS pricing is based on the number of messages published and the number of messaged delivered. You pay $0.50 per 1 million requests. If your request is larger than 64 KB, you pay for each 64KB chunk of your request. No matter how small your request is, you always pay for one request. The maximum size of 256 KB will result in 4 requests on your bill. Depending on the subscriber type, you pay for deliveries as well. For example, an HTTP subscriber is charged $0.60 for 1 million messages while Lambda and SQS subscribers are free (Lambda and SQS charges apply).

SNS’s typical latency is under 30 ms. AWS recommends using SNS for applications that react to high throughput or low latency messages.

SNS FIFO

SNS FIFO topics provide strict ordering of messages. SNS FIFO also provides a way to ensure that a message is not created twice if a producer retries in case of failures. Therefore, exactly once delivery is possible.

But there are downsides:

  • FIFO topics can only handle 300 messages per second or 3000 messages if you send messages in batches of ten but no more than 10 MB per second.
  • The only possible subscriber type for a FIFO topic is an SQS FIFO queue.
  • FIFO topics are more expensive. You pay per message and for the size of the payload.

EventBridge

Amazon EventBridge (formerly CloudWatch Events) is a fully managed, publish/subscribe system. The publisher sends a JSON event to an event bus. If you want to receive events, you create a rule. If the published event matches with a rule, the event is routed to up to five targets. More than 15 target types are supported (including SQS, SNS, Lambda). EventBridge guarantees are similar to SNS Standard: zero operational effort but no order guarantee and at least once delivery of messages.

EventBridge can be used to implement modest message fanout. A rule can trigger up to 5 targets. By default, you can create 300 rules per event bus (a soft limit that can be increased; the hard limit is not disclosed). Keep in mind that if an event does not match with a rule, it disappears unnoticed. You can optionally archive all events delivered to an event bus. Archived events can be replayed at any time.

EventBridge uses soft limits to throttle message producers. The default limits depend on the region. For example, in eu-west-1, the default limit is 10,000 msg/sec. There is no metric to monitor this resource constraint. The hard limit is not disclosed. Keep in mind that invocations are also throttled according to soft limits. Monitor the Invocations metric.

Typical latency is about half a second. (from the FAQS: “Note that this can vary”)

You pay $1.00 per 1 million events published. The same 64KB chunk logic as with SNS applies.

Want to learn more about the latest features of EventBridge? Watch the following video to larn about the latest features.

CloudFormation code: eventbridge-demo.zip

Summary

Use the following comparison table to support your decision.

Amazon SNS StandardAmazon SNS FIFOAmazon EventBridge (formerly CloudWatch Events)
Scalingnot disclosed (default soft limit depends on region; e.g., 9000 msg/sec in eu-west-1)3000 msg/sec (batch write) or 10 MB per secondnot disclosed (default soft limit depends on region; e.g., 10,000 msg/sec in eu-west-1)
Max. message size256 KB256 KB256 KB
Persistencenonoarchiving is possible
ReplicationMulti-AZMulti-AZMulti-AZ
Order guaranteenoyesno
Delivery guaranteeat least onceexactly-once possibleat least once
Pricingper messageper messageper message
ProtocolsAWS Rest APIAWS Rest APIAWS Rest API
AWS IntegrationsLambda, SQS, webhookSQS FIFOLambda, SQS, SNS, and many more
LicenseAWS onlyAWS onlyAWS only
Encryption at restyesyesyes
Encryption in transityesyesyes

Michael Wittig

Michael Wittig

I’ve been building on AWS since 2012 together with my brother Andreas. We are sharing our insights into all things AWS on cloudonaut and have written the book AWS in Action. Besides that, we’re currently working on bucketAV, HyperEnv for GitHub Actions, and marbot.

Here are the contact options for feedback and questions.