Top 5 reasons to use EventBridge instead of SNS
SNS and SQS have been the goto options for AWS developers when it comes to service integration. However, since its (much needed!) rebranding, EventBridge (formerly CloudWatch Events) has become a popular alternative.
If you’re still on the fence, then allow me to give you 5 reasons why you should consider using EventBridge instead of SNS.
1. More targets, lots more targets
SNS supports a handful of different targets, including SQS and Lambda.
EventBridge on the other hand, supports a total of 20 target types at the time of writing! The list includes the likes of SNS, SQS, Kinesis, ECS, Lambda as well as EventBridge on another AWS account.
This extensive reach helps us remove a lot of unnecessary glue code. For example, to start a Step Functions state machine, we would have needed a lambda function between SNS and Step Functions. With EventBridge, we can connect the rule to the state machine directly.
The ability to deliver events to another AWS account also extends its reach massively. Allowing you to trigger ECS tasks running in another AWS account. Or to allow the CISO and the security teams to monitor and react to everything happening inside a company’s AWS accounts.
However, one thing to keep in mind here is that you’re limited to 5 targets per EventBridge rule. Where as SNS has a mammoth limit of 12,500,000 subscriptions per topic!
2. AWS events & Third-party events
In addition to custom application events, EventBridge can also capture events of what’s happening in your AWS region, such as when an EC2 instance’s state has changed.
It can also capture API calls that have been recorded by CloudTrail, which provides a significant coverage of available AWS services.
Furthermore, you can also capture events from third-party partners such as PagerDuty and Datadog. This allows you to capture and react to events happening in a third-party system — user logged in to Auth0, alert is triggered in PagerDuty, etc. — all without having to deal with the complexities involved with ingesting these events.
Again, it’s worth taking the time to understand the service limits. EventBridge has a default, soft limit of 2400 ops/second for PutEvents in the larger AWS regions.
If you haven’t checked it out yet, have a look at AWS Service Quotas to see what your current service limits are. It’s worth noting that it’s possible to raise this limit to hundreds of thousands of ops/second if your workload demands it.
3. Content-based filtering
SNS allows you to filter messages via filter policies. However, this support is limited as you can’t filter messages by their content. You can only filter by messages attributes and are limited to just 10 attributes per message. If you require content-based filtering then they have to be done in code.
EventBridge on the other hand, gives you a way to pattern match against the event content. And in addition, it also supports advanced filtering rules such as:
- numeric comparison
- prefix matching
- IP address matching
- existence matching
- anything-but matching
Check out this blog post on content-based filtering for more details on these advanced rules.
Being able to do content-based filtering means it’s possible to have a single event bus for all publishers. Whereas with SNS you often have to have multiple topics to ensure subscribers only receive the events they need. Having a single, centralized event bus is much simpler to manage, especially when you have the ability to register and discover event schemas (see below).
4. Schema discovery
A common challenge with event-driven architecture is identifying and versioning event schemas. EventBridge deals with this challenge with its Schema Registry.
It provides the schema for all AWS events out-of-the-box.
You can also enable schema discovery on both the default event bus as well as any custom event buses you have created.
Once enabled, EventBridge would sample ingested events and auto-generate the schema definitions.
From here, you can generate language bindings (for Java, Python and TypeScript) and browse these schemas in VS Code using the AWS Toolkit.
5. Input transformation
Another powerful feature of EventBridge is that it allows you to transform the event before passing it as input to the target(s).
This too, helps remove custom glue code that only serves the purpose of transforming the payload. Which is often necessary when you need to forward events from a publisher you don’t control, to a target (e.g. a SQS queue) that you also have no control over!
Summary
In summary, you should consider adding EventBridge to your stack instead of sticking with the tried-and-tested SNS because:
- It supports a lot more targets, meaning you can integrate between a wider variety of services
- Its cross-account delivery capability further amplifies its reach. It’s easy to distribute events to Kinesis, Step Functions, and many other services running in another AWS account
- It supports native AWS events as well as third-party partner events.
- It supports content-based filtering.
- It supports input transformation.
- It has built-in schema discovery capabilities.
Of course, EventBridge is not the right solution for every application integration problem out there. But I’d love to see it adopted more broadly and remove a lot of custom glue code that we have had to write to plug feature gaps in SNS. As Jeff Atwood once wrote, the best code is no code at all.
