Cloud Parts

Event buses

A router that sends each event to whoever has a rule for it.

2 technologies on this page ↓
Live model
What you’re watchingEvents from three sources arrive at one bus. Rules read each event’s type and send it only to matching targets: an alarm goes to two places, a payment to one.

How it works

Services and SaaS apps emit events to one central bus. Rules match events on their fields (source, type, even values inside the payload) and deliver them to targets such as functions, queues, workflows or other accounts. It’s pub/sub with content-based routing and filtering built in, so each consumer receives only the events it asked for.

Think of it as

A mailroom that reads each envelope and drops it in the right pigeonholes, following rules each department filed.

Reach for it when

  • Many event types from many sources, with routing that changes often
  • Reacting to cloud and SaaS events: a file landed, a payment settled
  • Cross-team or cross-account integration without point-to-point wiring

Think twice when

  • Very high-throughput telemetry; per-event pricing and latency favor a stream
  • Strict ordering across all events; most buses don’t promise order, and EventBridge’s new Custom Event Bus orders only within an event group

A real example

Payments, orders and field alarms all publish to one bus. A rule sends alarm events with severity=critical to the on-call pager and to email, while order events start the fulfilment workflow.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
EventBridge; EventBridge Scheduler for timed invocations
Google Cloud
Eventarc
Azure
Event Grid
Open source & others
Knative Eventing, Argo Events

In code · json

// EventBridge rule: match critical alarms from field devices
{
  "source": ["field.devices"],
  "detail-type": ["alarm"],
  "detail": { "severity": ["critical"] }
}
// Targets: the pager function and the email topic

Often confused with

Pub/subWorkflow orchestrationServerless functions (FaaS)
Where it came from2002–2026

The event bus descends from the integration middleware of the 1990s and 2000s. As companies tried to connect dozens of applications, the enterprise service bus (ESB) became the fashion; the first published use of the term is credited to Gartner’s Roy Schulte, in 2002. An ESB was a central hub that routed, transformed and mediated messages between systems. It cut point-to-point wiring, but it could become a single point of failure and needed heavy configuration.

The 2003 book Enterprise Integration Patterns named the building blocks, including the Message Bus and the Content-Based Router, which routes “each message to the correct recipient based on message content.” Cloud event buses kept the routing and dropped the heavy middle. AWS shipped CloudWatch Events in 2016 to route AWS’s own resource events to functions with rules, Microsoft previewed Azure Event Grid in 2017, and AWS relaunched its service as EventBridge in 2019 so SaaS companies could publish into customers’ buses.

Two trends are shaping it now: CloudEvents, a CNCF specification for describing events the same way everywhere, and buses that keep events, such as EventBridge’s Custom Event Bus of 2026, with retention, replay and ordering, which bring event buses closer to streams.

Why it’s built this way

Route on content, not on addresses
Producers emit events without naming a receiver, and rules match on fields such as source, type or values in the payload. Each consumer gets only what it asked for, and routing changes don’t touch producers.
A managed router, not a central integration server
ESBs became single points of failure that needed heavy configuration. Cloud buses are run by the provider, scale per event and leave business logic in producers and consumers.
The platform publishes its own events
Cloud providers put their resource events (a file uploaded, an instance stopped) on the bus, so reacting to infrastructure needs no polling. Event Grid launched with Blob Storage and resource group events.
A shared event envelope
Every publisher describing events differently made each integration custom. CloudEvents defines common metadata so tools and buses can handle any event the same way.

Timeline

  1. 2002

    The term “enterprise service bus” appears in print, credited to Gartner’s Roy Schulte

  2. 2003

    Enterprise Integration Patterns names the Message Bus and Content-Based Router

  3. 2016

    AWS CloudWatch Events routes AWS resource events with rules

  4. 2017

    Microsoft previews Azure Event Grid

  5. 2019

    Amazon EventBridge launches; CloudEvents 1.0 is released

  6. 2024

    CloudEvents graduates in the CNCF

  7. 2026

    EventBridge’s new Custom Event Bus adds retention, replay and ordering

Sources10

Improve this page on GitHub