Service spotlight: Amazon EventBridge beyond Lambda glue

Most teams meet EventBridge as “the thing that triggers a Lambda on a cron schedule” and stop there. That’s a legitimate use, but it undersells the service — EventBridge is an event bus, and the pattern-matching/routing layer underneath it is worth understanding on its own, separate from the scheduler feature that happens to share the console.

What it actually is

An event bus is a named channel that receives JSON events and evaluates them against a set of rules. Each rule has an event pattern — a partial JSON match against the event’s fields — and a list of targets (Lambda, SQS, Step Functions, Kinesis, another event bus, over 20 AWS services directly). When an event matches, EventBridge fans it out to every matching rule’s targets, in parallel, with built-in retry and an optional dead-letter queue per target. You publish an event once; the bus decides who cares.

Every account gets a default bus that also receives events natively from ~200 AWS services (an S3 upload, an ECS task state change, a CodePipeline stage transition) with zero integration code — that’s the part people miss. You can also create custom buses for your own application events, and partner buses for SaaS integrations (Datadog, PagerDuty, Zendesk) that push events directly into your account.

Where it beats point-to-point wiring

The alternative to EventBridge is usually “Lambda A calls Lambda B directly” or “publish to an SNS topic with N subscriptions.” Both work, but they couple the publisher to knowing who’s listening. EventBridge inverts that: the publisher emits one event describing what happened, and consumers declare what they care about via pattern matching, without the publisher’s code ever changing when a fourth consumer shows up. Adding “also send a Slack notification when an order ships” is a new rule, not a code change to the order service.

Schema discovery is the other underused feature: point EventBridge at a bus and it infers a schema registry from the events flowing through it, including versioning as the shape evolves, and can generate strongly-typed bindings (Java, Python, TypeScript) for consumers. For anything beyond a handful of hand-maintained event types, that beats a wiki page describing “here’s what fields this event has, trust me.”

Archive and replay

Every bus can have an archive attached — EventBridge stores a copy of matching events (with a retention period you set, including indefinite) and can replay them into the bus later, re-triggering the same rules. That’s the feature that turns “we had a bug in the order-confirmation-email Lambda for six hours” from a data-backfill script into a console button: fix the Lambda, replay the archived window, done. It’s also genuinely useful for testing — replay production events into a rule pointed at a dev target instead of hand-crafting test payloads.

The rule-limit gotcha

Each event pattern rule can have at most 5 targets, and a bus can have up to 300 rules by default (a soft limit, raisable). Teams that treat EventBridge as a single giant bus with dozens of broad-matching rules and long target lists eventually hit both limits and end up debugging which of 15 similar-looking rules actually matched a given event — the console’s “test pattern” tool helps, but the real fix is scoping rules narrowly by detail-type and source from the start rather than one catch-all rule per consumer with a growing target list.

Pricing

Custom events published to a custom bus are billed per million events; events matched from AWS service integrations on the default bus are free — only your own published events cost anything. Archive storage is billed separately by GB, and replays re-invoke targets, so replaying a large archived window against a Lambda target bills exactly like the original traffic did. It’s cheap at normal volumes, but a botched pattern that accidentally matches everything (an empty or overly broad source filter) and fans out to an expensive target is the way people get a surprise line item, same as any fan-out system.

A practical tip

Give every custom event a detail-type and source from day one, even for a single-consumer event — retrofitting rule scoping after five teams are publishing to the same bus with inconsistent field names is far more painful than establishing the convention up front. If you’re publishing from multiple services, agree on a naming scheme (source: "orders.checkout", detail-type: "OrderPlaced") before the first event ships, not after.