For those confused, I suggest you go read the official doc: https://aws.amazon.com/eventbridge/faqs/ https://aws.amazon.com/eventbridge/faqs/ . Let me quote the

For those confused, I suggest you go read the official doc: https://aws.amazon.com/eventbridge/faqs/ https://aws.amazon.com/eventbridge/faqs/ . Let me quote the important bits: > EventBridge was formerly called Amazon CloudWatch Events. It includes new features that enable you to receive events from SaaS partners and your own applications. Existing CloudWatch Events users can access their existing default bus, rules, and events in the new EventBridge console and in the CloudWatch Events console. EventBridge uses the same CloudWatch Events API, so all of your existing CloudWatch Events API usage remains the same. So EventBridge is CloudWatch Events. The difference is that now you can publish your own events and specify your own routing rules for them. As well as supporting 3rd party events from certain SaaS partners. It is limited to 400 events per second, 5 targets per rule, and 100 rule per account. Consuming events is throttled at 750 per second. Events take about half a second to reach targets. Some of these limits can be increased by asking for higher limits. AWS published events, so existing CloudWatch Events don't count towards these and are unlimited. What about SNS? > Amazon SNS is recommended when you want to build an application that reacts to high throughput or low latency messages published by other applications or microservices (as Amazon SNS provides nearly unlimited throughput), or for applications that need very high fan-out (thousands or millions of endpoints) > At launch, Amazon EventBridge is has limited throughput (see Service Limits) which can be increased upon request > Amazon EventBridge is the only event-based service that integrates directly with third-party SaaS partners > Amazon EventBridge uses a defined JSON-based structure for events, and allows you to create rules that are applied across the entire event body to select events to forward to a target Also, the targets are not exactly same yet. For example, only SNS can publish to Mobile SMS, Email, or HTTP/S endpoints for now. And SNS allows any type of payloads, while EventBridge forces you into JSON. Finally, the reason this specifies serverless is because of the dynamic content based routing using configurable rules. This means you don't need to manage your own routing. So say you want to pair it with Lambda, you don't waste Lambdas starting then realizing the event isn't relevant for them, you can just setup rules for that. So it provides a serverless routing mechanism that auto-scales and is decoupled from producer and consumer. That's pretty cool! Hope that helps!