SYSTEM Cited by 3 sources

Amazon EventBridge

Amazon EventBridge is AWS's managed serverless event bus: producers put events onto a named bus, rules match events by content pattern and dispatch to configured targets (Lambda / SQS / SNS / Step Functions / cross-account event bus / API destinations / etc). The core differentiator vs raw SNS pub/sub is content-based routing rules + a first-class schema registry — consumers subscribe by event shape, not by topic name.

Role for this wiki

EventBridge is the canonical AWS shared-bus substrate for event-driven architectures at organisation scale. It replaces the ad-hoc SNS / SQS pair-per-integration pattern with a single logical bus + rule-based fanout, and adds schema discovery / a schema registry for governance that SNS topics don't provide.

Model

• Event bus — logical namespace receiving events. Default bus per account for AWS service events; custom buses for application events.
• Event — JSON document; mandatory envelope fields (source, detail-type, time, account, region, id) + customer detail payload.
• Rule — content pattern matcher (field path + filter expression) → one or more targets. Multiple rules can match the same event (fanout); multiple targets per rule (parallel delivery).
• Target — any EventBridge-supported destination: Lambda, SQS, SNS, Step Functions, another event bus (cross-account supported via resource policies), HTTPS API destinations, Kinesis, Firehose, etc.
• Schema registry + discovery — EventBridge can auto-discover event shapes from traffic and persist them in a registry; versioned as events evolve; does not perform native validation (see below).

The missing validation capability

"EventBridge provides developers with tools to implement validation using external solutions or custom application code, it currently does not include native schema validation capabilities." — Amazon Key team, 2026-02-04

This is a load-bearing gap for organisations with strict validation requirements: events are stored + routed even if malformed, and invalid events propagate to every matching consumer. Customers who need pre- publish validation have two options:

1. Centralized validation service — extra network hop + its own scaling problem + latency penalty.
2. Client-side validation via a shared library bound to a schema repository (patterns/client-side-schema-validation) — immediate developer feedback, no runtime hop. The Amazon Key team chose this, building a custom schema repository distinct from EventBridge's own schema registry specifically because the registry lacks enforcement.

Single-bus multi-account pattern

AWS ships an official reference pattern — one centrally-owned event bus, cross-account resource policies admitting per-team accounts — consumed by Amazon Key as the organisational substrate for patterns/single-bus-multi-account: service teams own their application stacks; a DevOps team owns the bus + rules + targets + integrations; logical separation inside the single bus is expressed via rules, not via account boundaries.

What EventBridge doesn't do (that customers commonly build on top)

• Native schema validation (described above — pre-publish enforcement).
• Build-time code bindings at the developer ergonomics level — the registry's generated code is a starting point; production deployments typically wrap this in a client library with event-type-safe constructors + publishing + subscribing abstractions.
• Subscriber-side IaC scaffolding — dedicated subscriber event bus + cross-account IAM + monitoring + alerting. Solved in Amazon Key by a CDK subscriber constructs library.

Seen in

• sources/2026-02-04-aws-amazon-key-eventbridge-event-driven-architecture — Amazon Key migrated from tightly-coupled monolithic service interactions (and from ad-hoc SNS/SQS pairs) to EventBridge-centric event-driven architecture. Built three custom components on top (schema repository + client library + CDK subscriber constructs) to close EventBridge's validation + ergonomics + subscriber-IaC gaps. Reported 2,000 events/s, 99.99% success rate, 80ms p90 ingestion→invocation latency, 14M subscriber calls in the reporting window.
• sources/2026-04-01-aws-automate-safety-monitoring-with-computer-vision-and-generative-ai — EventBridge plays three distinct scheduled + triggered roles in the CV-safety pipeline: (1) cadence trigger for the GT Job creation Step Functions workflow that creates SageMaker Ground Truth labelling jobs; (2) model-approval event fires a Lambda that opens a code review updating the SageMaker endpoint's S3 URI (cleanly decoupling science + application deployment); (3) scheduled rule drives per-minute risk-resolution checks + SLA-exhaustion escalation on the risk-aggregation path (patterns/alarm-aggregation-per-entity).
• sources/2026-04-08-aws-build-a-multi-tenant-configuration-system-with-tagged-storage-patterns — EventBridge is the change-event substrate for event-driven config refresh. Parameter Store writes natively emit EventBridge events; a rule matching /config-service/* path prefix fires a Lambda that pushes fresh values to live ECS Config Service instances over gRPC — eliminating the TTL-vs-staleness dilemma for shared configuration. Canonical instance of the "source emits change event → invalidator Lambda → push to live caches" shape without polling or restart.

Related

• systems/aws-sns, systems/aws-sqs — the lower-level pub/sub primitives EventBridge supersedes as the shared-bus abstraction for organisation-scale event-driven architectures; still used as EventBridge targets downstream.
• systems/aws-lambda — canonical EventBridge target; Lambda invocations from rules are the default compute integration.
• systems/aws-cdk — IaC substrate for reusable subscriber constructs.
• concepts/event-driven-architecture — the architectural pattern EventBridge substrates.
• concepts/schema-registry — the registry concept both EventBridge's built-in and the customer-built repositories implement.
• patterns/single-bus-multi-account — AWS-endorsed org-scale deployment topology.
• patterns/client-side-schema-validation — the gap-closing pattern applied on top.