EventBridge is AWS’s serverless event bus that lets you connect your applications with AWS services and SaaS partners.
Let’s see EventBridge in action. Imagine you have an e-commerce application where a new order is placed. This order event needs to trigger several downstream processes: updating inventory, sending a confirmation email, and notifying a shipping service.
Here’s a simplified representation of an order creation event:
{
"version": "0",
"id": "a1b2c3d4-e5f6-7890-1234-567890abcdef",
"detail-type": "Order Created",
"source": "com.my-ecommerce-app.orders",
"account": "123456789012",
"time": "2023-10-27T10:00:00Z",
"region": "us-east-1",
"resources": [],
"detail": {
"orderId": "ORD-98765",
"customerId": "CUST-4567",
"items": [
{"productId": "PROD-101", "quantity": 2},
{"productId": "PROD-205", "quantity": 1}
],
"totalAmount": 150.75,
"orderTimestamp": "2023-10-27T09:59:58Z"
}
}
In EventBridge, you’d define a rule that matches events with detail-type: "Order Created" and source: "com.my-ecommerce-app.orders". This rule would then have multiple targets: an AWS Lambda function for inventory updates, an Amazon SNS topic for email notifications, and an Amazon SQS queue for the shipping service. When an order is created, your application publishes this event to EventBridge, and EventBridge automatically routes it to all configured targets.
The core problem EventBridge solves is decoupling. Traditionally, your order service would need direct integrations with the inventory service, the email service, and the shipping service. This creates tight coupling: if any of those downstream services change their API or availability, your order service is directly impacted. With EventBridge, your order service only needs to know how to publish an event to the bus. The responsibility of delivering that event to the correct consumers lies with EventBridge. This makes your system more resilient, scalable, and easier to evolve.
Internally, EventBridge operates as a managed event bus. When an event is sent to a bus (either the default bus or a custom one you create), EventBridge evaluates it against the rules you’ve defined. Each rule has a pattern that specifies which events it should match based on fields like source, detail-type, and specific values within the detail payload. If an event matches a rule’s pattern, EventBridge invokes the targets associated with that rule. Targets can be AWS services like Lambda, SNS, SQS, Kinesis, or even external HTTP endpoints via API Destinations.
The exact levers you control are primarily the event patterns in your rules and the configuration of your targets. For event patterns, you can use simple string matching, array matching, and even numeric/boolean comparisons. For example, you could create a rule that only triggers for orders over $100:
{
"source": ["com.my-ecommerce-app.orders"],
"detail-type": ["Order Created"],
"detail": {
"totalAmount": [{ "numeric": [">", 100] }]
}
}
For targets, you can configure retry policies, dead-letter queues (DLQs) for failed deliveries, and input transformation to modify the event payload before it’s sent to the target. This allows you to tailor the data delivered to each specific consumer.
EventBridge also allows you to define custom event buses, which is crucial for organizing events from different applications or teams. Instead of sending all events to the default bus, you can create a com.my-company.orders.bus or com.my-company.inventory.bus. This provides better isolation and control over event flow within your organization. You can even set up event buses to receive events from other AWS accounts or SaaS partners.
A key aspect of EventBridge is its ability to transform events. While your source application might publish a detailed order event, a specific downstream service might only need a subset of that information, or it might need it in a different format. EventBridge supports input transformations using JSONPath and a templating language. This means you can reshape the event payload before it reaches the target, so the target function or service receives exactly what it needs without having to parse and filter the raw event itself. For instance, if a shipping notification service only cares about the orderId and customerId, you can configure the target to only pass those fields.
The next step in mastering EventBridge is to explore schema registry and discovery, which helps you manage and validate your event structures.