You already know SQS (queues) and SNS (notifications). Now we’ll look at EventBridge, a more modern and powerful event service that takes messaging ideas a step further. It’s the backbone of many event-driven architectures in AWS.

EventBridge is an event bus: a kind of “central highway” through which events from your entire application and AWS services travel. Services publish events to the bus, and EventBridge automatically routes them to the appropriate destinations according to rules.

Analogy: EventBridge is like the mail sorting system in a large office. Letters (events) arrive from many senders. A sorter (the rules) reads each letter and sends it to the correct department based on its content. No one has to deliver by hand: the system routes everything automatically according to predefined rules.

The heart of EventBridge is the rules. A rule says: “when an event matches this pattern, send it to this destination.” EventBridge examines each event and, if it matches a rule’s pattern, routes it to its destination.

The interesting thing is that rules filter by the content of the event. An event is basically a JSON with data, and the rule can look at that data:

A rule could say: “send to manual review the OrderCreated events with amount greater than 1000.” EventBridge filters and routes automatically, without you writing any routing code.

It’s the natural question: SNS also broadcasts messages to multiple destinations. Why EventBridge? The key differences:

In summary: SNS is simple and super-fast for broadcasting; EventBridge is more sophisticated, with advanced content filtering and native integration with dozens of AWS services and external applications.

Practical rule: use SNS when you just need to broadcast a message to several destinations simply and quickly. Use EventBridge when you need to route events intelligently based on their content, or integrate events from AWS services and SaaS applications.

EventBridge has a superpower: many AWS services emit events to EventBridge automatically. This lets you react to things happening inside AWS without programming anything special:

• “When an EC2 instance changes state” → trigger a Lambda.
• “When an object is uploaded to S3” → route to a destination.
• “When a service task finishes” → notify a system.

Real-world example: you want to receive an alert in Slack every time someone starts a large (expensive) EC2 instance. You create a rule in EventBridge: “when an event indicates a large instance has been launched, send it to a Lambda that notifies Slack.” You don’t have to program any monitoring system: EventBridge already receives those AWS events, you just define the rule.

EventBridge also allows you to schedule events in time (what used to be called “CloudWatch Events”). You can trigger an action on a schedule, like a recurring task:

It’s the serverless way of doing the classic server “cron”: tasks that run on a schedule, without needing a server running and watching the clock.

• EventBridge is an event bus: a “central highway” where services publish events and EventBridge routes them to their destinations according to rules.
• Rules filter by the content of the event (“if amount > 1000 → manual review”) and route automatically, with no routing code.
• Compared to SNS: EventBridge offers advanced content filtering and native integration with many AWS services and SaaS apps. Use SNS for simple, fast broadcasting; EventBridge for smart routing and integrations.
• Superpower: many AWS services emit events to EventBridge, letting you react to what happens inside AWS without programming monitoring.
• With schedules, EventBridge runs scheduled tasks (the serverless “cron”).

In the last subchapter of this chapter, we’ll bring all these pieces together (SQS, SNS, EventBridge) into the major patterns they enable: pub/sub, decoupling, and saga.