Cloud Parts

Amazon EventBridge

AWS’s serverless event bus, which routes JSON events from apps, AWS services and SaaS tools to targets by matching their content.

What it is
Event buses
Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary
Facts checked
5 October 2026

What it is

Producers call PutEvents with JSON events of up to 1 MB, each carrying a source, a detail-type and a detail payload. AWS services publish their own events (an EC2 instance stopping, an object landing in S3) to each account’s default bus, and SaaS partners can feed events in too. On the original bus, now called Custom Event Bus - Classic, rules hold event patterns that match on any field, with prefixes, numeric ranges and wildcards. Each matching rule sends the event to up to five targets, such as a Lambda function, an SQS queue, a Step Functions workflow or any HTTPS API, optionally reshaped on the way.

AWS has since added a second bus type, simply called the Custom Event Bus. It keeps every event for 1 to 365 days, and each consuming team attaches its own subscribers, each with filters and exactly one target. Because the events are retained, a subscriber can start from a point in the past, pause and resume without losing events, or receive events in order within an event group. The same service also includes Pipes, for point-to-point links from one source to one target, and Scheduler, for cron and one-off invocations, which AWS now recommends over the older scheduled rules (labelled legacy).

Why teams pick it

  • Content-based routing with no code: each consumer receives only the events it matches
  • AWS service events and SaaS partner events arrive without any glue
  • Archive and replay on the classic bus, or built-in retention and ordered delivery on the new Custom Event Bus
  • Pipes and Scheduler cover point-to-point integrations and timed jobs in the same service

Watch out for

  • Classic rules allow five targets each, and a bus allows 300 rules by default in most regions
  • PutEvents is throttled per region (10,000 requests per second in the largest regions by default, as low as 400 in others), so very high-volume streams belong in Kinesis or Kafka
  • The classic bus accepts JSON only and makes no ordering promise
  • An AWS-only API; events from outside AWS have to be pushed in

Alternatives

What all event buses have in common →

How it fits with other technologies

Send big orders on a classic bus to a fraud-check function · bash

aws events create-event-bus --name orders

aws events put-rule --name big-orders --event-bus-name orders --event-pattern \
  '{"source": ["acme.shop"], "detail-type": ["OrderPlaced"], "detail": {"total": [{"numeric": [">", 100]}]}}'

# the function also needs a resource policy that lets events.amazonaws.com invoke it
aws events put-targets --rule big-orders --event-bus-name orders \
  --targets 'Id=fraud-check,Arn=arn:aws:lambda:us-east-1:111122223333:function:fraud-check'

aws events put-events --entries \
  '[{"EventBusName": "orders", "Source": "acme.shop", "DetailType": "OrderPlaced", "Detail": "{\"orderId\": 42, \"total\": 250}"}]'

See it in a real stack

No architecture uses Amazon EventBridge yet. Drop it into the playground and wire it up yourself.Open playground →

Worth exploring

Article· August 2025lambda to eks pod migrationAWS re:Post community questionA short Q&A on what replaces Lambda’s built-in triggers, SQS polling and scaling when functions move to EKS pods. The useful answer points to KEDA (with Karpenter) for scaling pods on queue depth; the longer answer is an unreviewed AI-generated checklist from AWS’s own assistant, so treat it as a starting list, not guidance.
All resources →
Where it came from2016–2026

In January 2016 AWS shipped CloudWatch Events, a modest feature for writing rules that routed notifications of things happening in AWS to Lambda functions and other targets. Tim Bray, who worked on it, recalled that it lived inside CloudWatch because “it was hard to believe it deserved top-level service billing.” It soon had a huge number of users, and many of the things they did “weren’t really CloudWatch-y at all,” as event-driven design caught on.

On July 11, 2019 AWS relaunched it as Amazon EventBridge, a top-level service on the same API. The new part was partner event sources: SaaS companies such as Datadog, PagerDuty and Zendesk could publish straight into a customer’s account, with no webhook to host. The obvious name, “AWS Events”, was taken, because aws.amazon.com/events already hosted AWS’s conferences. The matching engine underneath, a library called Ruler that Bray wrote, was open-sourced as Event Ruler in 2022.

EventBridge then grew sideways, with archive and replay, Pipes and Scheduler. In September 2026 AWS relaunched custom buses with built-in retention, ordering and per-team subscribers, and renamed the original the Classic bus.

Why it’s built this way

Rules written as JSON that looks like the events
A pattern mirrors the shape of the events it matches, so there’s no query language to learn. Ruler compiles patterns into finite-state machines, which kept matching fast even when one team asked about posting a million rules.
Content-based routing on a shared bus
Producers send events without naming any receiver, and each consumer’s rule picks what it wants. Teams can add consumers, or change routing, without touching producers.
AWS services as publishers, for free
Every account’s default bus receives AWS’s own events, and AWS charges nothing to ingest its management events, so reacting to infrastructure changes needs no polling.
Keep the CloudWatch Events API
Building EventBridge on the existing API meant every CloudWatch Events rule kept working on day one.

Timeline

  1. 2016

    CloudWatch Events launches in January

  2. 2019

    Relaunched as EventBridge in July, with SaaS partner event sources

  3. 2020

    Event archive and replay

  4. 2022

    Pipes and Scheduler; the matching engine is open-sourced as Event Ruler

  5. 2026

    Payloads grow to 1 MB; new Custom Event Bus with retention and ordering

Sources14 · facts checked 5 October 2026

Improve this page on GitHub