I haven’t yet used EventBridge in a proper application although I’ve read a lot of very positive reviews over the past few months and its feature set looks very impressive.
I have, however, used SNS for years and it’s probably one of my favourite AWS services. It’s really easy to get set up and almost always “just works”. So for me at least, EventBridge has a high standard to live up to (if only AWS would bring out a competing service to cannibalise Cognito! 😛).
Given the large crossover between EventBridge and SNS in terms of features, I wasn’t quite sure where SNS would fit in my toolbelt of services going forward. So I asked this question on Twitter yesterday:
“Question for AWS EventBridge advocates: are there any use cases where you would still use an SNS topic in a greenfield project?”
Several AWS experts chimed in with answers that I’ve summarised below. Consider SNS over EventBridge in these scenarios:
- High throughput requirements — SNS is better fit for fanning out to large number of consumers
- EventBridge has a limit of 5 targets per rule, SNS has a huge subscribers limit
- Higher latency in message delivery for EventBridge than SNS, though this difference may no longer be as significant
- Cross-account message delivery is simpler to configure with SNS
- SNS has built-in delivery subscriptions for SMS, email, mobile push and HTTP endpoints that EventBridge does not (yet) provide
So to conclude, I definitely won’t be completely ditching SNS. The large fan-out pattern in particular is a common use case for me. I do hope to try out EventBridge soon in the role of application domain event bus.