Amazon EventBridge
Amazon EventBridge is a serverless event bus service provided by Amazon Web Services that enables event-driven communication between applications, services, and SaaS providers. Introduced in 2019 as a successor to CloudWatch Events, EventBridge is not merely a message routing service; it is an event abstraction layer that decouples event producers from event consumers through a schema-aware routing topology. In the AWS ecosystem, EventBridge sits alongside Amazon SQS (queue-based decoupling), Amazon SNS (pub/sub fan-out), and Apache Kafka (log-based streaming), but it occupies a distinct architectural niche: it is optimized for event routing, not event queuing or event streaming.
The core abstraction of EventBridge is the event bus. An event bus is a named endpoint that receives events from multiple producers and routes them to multiple consumers based on rules. Each event is a JSON object with a defined schema, including fields such as 'source', 'detail-type', 'detail', and 'resources'. Producers send events to the bus; consumers do not poll or subscribe directly to producers. Instead, the bus applies rules — pattern-matching filters — to each event and forwards matching events to targets. The target can be an SQS queue, an SNS topic, a Lambda function, a Step Functions state machine, an API destination, or a wide range of third-party SaaS integrations.
Rules and Targets
An EventBridge rule is a declarative filter that evaluates each event against a pattern. The pattern is a JSON document that specifies the fields and values that must match for the event to be routed. For example, a rule might match all events where 'source' is 'aws.ec2' and 'detail-type' is 'EC2 Instance State-change Notification'. The pattern language supports exact matching, prefix matching, numeric range matching, and existence checks. Rules are evaluated in parallel, and a single event can match multiple rules, triggering multiple targets. This is a form of conditional fan-out: the event is broadcast to all targets whose rules match, but the broadcast is conditional on the event's content, not on a static subscription list.
The target abstraction is what makes EventBridge a systems design tool rather than merely a messaging tool. A target is not just a destination endpoint; it is a configured integration with retry logic, dead-letter queues, and input transformation. EventBridge can transform the event JSON before sending it to the target, mapping fields, adding constants, or extracting nested values. This means the producer's event schema does not need to match the consumer's expected input format. The bus acts as a schema adapter, decoupling not just timing and availability but data structure as well.
Schema Registry and Event Discovery
EventBridge includes a schema registry that automatically discovers and records the schemas of events sent to a bus. When a producer sends an event, EventBridge inspects the JSON structure and generates a schema definition, which is stored in the registry and versioned over time. Consumers can browse the registry to discover the events available on a bus, and code-generation tools can produce typed event classes from the schema definitions. This is a form of implicit interface documentation: the schema registry captures the contract between producers and consumers without requiring a separate specification document.
The schema registry addresses a real problem in event-driven architectures: event schema drift. In a system with many producers and many consumers, the event schema evolves over time. Fields are added, renamed, or deprecated. Consumers that depend on specific fields break when those fields change. The schema registry does not prevent drift, but it makes drift visible. Versioned schemas enable consumers to detect incompatible changes and to plan migrations. This is a significant improvement over ad-hoc JSON parsing, where schema changes are discovered through production failures.
Event-Driven Architecture
EventBridge is a practical implementation of the event-driven architecture pattern, in which systems communicate by producing and consuming events rather than by invoking each other directly. In an event-driven architecture, services are loosely coupled: a producer does not know which consumers exist, and a consumer does not know which producers sent the events it processes. The event bus is the central nervous system of the architecture, and its topology determines the system's coupling structure.
But event-driven architectures have their own failure modes. A misconfigured rule can silently drop events, producing data loss that is invisible until a downstream system reports missing data. A rule with an overly broad pattern can trigger a cascade of targets, amplifying a single event into a distributed storm of side effects. A consumer that fails to process an event can trigger retries that overload the producer, creating a feedback loop. The event bus is a decoupling mechanism, but it is also a failure amplification mechanism. The same topology that prevents direct coupling enables indirect coupling through event storms, retry loops, and poison events.
The deeper claim about EventBridge — and about event-driven architectures in general — is that the event bus is not a decoupling device but a coupling relocation device. It moves the coupling from the synchronous call graph to the asynchronous event graph, and the event graph is often harder to reason about, harder to debug, and harder to test. The event bus makes the system locally simpler and globally more complex. The question is not whether to use EventBridge but whether the complexity of the event graph is justified by the flexibility it provides. In many cases, the answer is no, and a simpler synchronous architecture would be more robust.