Why architecture matters here
EventBridge matters because it's the serverless event bus that enables decoupled, event-driven architectures on AWS -- the routing infrastructure for services reacting to events. Event-driven architecture (services reacting to events rather than directly calling each other) is a powerful pattern (decoupling -- services independent, reacting to events; scalability -- events processed asynchronously; flexibility -- new consumers added without changing producers), and it needs an event bus to route events (from producers to consumers, decoupled). EventBridge provides this as a serverless, managed service (no infrastructure to manage) with rich routing (content-based patterns), broad integration (AWS services, applications, SaaS as sources; many AWS services as targets), and useful capabilities (schema registry, transformation, archive/replay). For building event-driven architectures on AWS (a common and powerful approach), EventBridge is the central event-routing infrastructure, and understanding it (its routing, its capabilities, when to use it vs SNS/SQS) is understanding how to build decoupled, event-driven systems on AWS.
The content-based-routing insight is a key capability, and it's what makes EventBridge's routing powerful. Basic messaging (like SNS topics) routes based on the topic (a consumer subscribes to a topic, gets all its messages). EventBridge routes based on content: rules match event patterns (filters on the event's structure -- e.g., match events where the source is 'orders' and the detail-type is 'OrderPlaced' and the amount > 100) -- so a rule receives only the events matching its pattern (the relevant events, filtered by content). This content-based routing is powerful (fine-grained routing -- consumers get exactly the events they care about, filtered by the event content, not just by topic) -- enabling sophisticated event routing (different consumers for different event contents, from the same event stream). This is a key EventBridge strength (content-based filtering -- routing by the event's content, not just its type/topic) that basic pub/sub lacks, and it's why EventBridge is powerful for event routing (fine-grained, content-based). Understanding the content-based routing (rules matching event patterns on the event content) is understanding EventBridge's routing power.
And the decoupling-plus-broad-integration design is what makes EventBridge central to AWS event-driven architecture. Decoupling: producers publish events to the bus (without knowing the consumers -- just emitting events about what happened), and consumers subscribe via rules (without the producers knowing -- getting the events they care about) -- so producers and consumers are fully decoupled (independent -- a producer doesn't know or depend on its consumers; a consumer can be added/removed/changed without affecting the producer). This decoupling is the essence of event-driven architecture (services independent, communicating via events -- flexible, scalable, resilient). Broad integration: EventBridge integrates broadly -- event sources (many AWS services emit events to EventBridge natively -- so you can react to AWS service events; plus your applications and SaaS integrations as sources) and targets (many AWS services can be targets -- Lambda, SQS, Step Functions, and more -- so events can trigger a wide range of processing). This broad integration (AWS services, apps, SaaS as sources; many AWS services as targets) makes EventBridge a central hub (routing events across the AWS ecosystem and beyond). This -- decoupling (producers and consumers independent, communicating via events) and broad integration (a central hub across AWS and beyond) -- makes EventBridge central to AWS event-driven architecture, and understanding these (the decoupling it enables, the integration it provides) is understanding its role.
The architecture: every piece explained
Top row: the routing core. The event bus: the central router (events published to it, routed to targets) -- the default bus (for AWS service events), custom buses (for application events), and partner buses (for SaaS). Rules and patterns: rules route events -- each rule has an event pattern (a filter matching the event structure -- e.g., matching the source, detail-type, and content fields) and targets (where matching events go); a rule receives events matching its pattern (content-based routing). Targets: where matching events are delivered -- Lambda (invoke a function), SQS (queue), Step Functions (start a workflow), and many other AWS services -- the event consumers. Event sources: where events come from -- AWS services (emitting events natively -- e.g., EC2 state changes, S3 events), your applications (publishing custom events), and SaaS integrations (partner event sources) -- the event producers.
Middle row: the capabilities. Schema registry: discovering and managing event schemas (the event contracts -- the structure of events) -- so consumers know the event structure (and can generate code bindings), and events have discoverable, managed schemas. Content filtering: pattern-based routing (rules matching the event content -- so a rule receives only the events matching its content pattern) -- fine-grained, content-based routing. Input transformation: reshaping the event before delivering to the target (transforming the event structure -- extracting/reformatting fields -- to match the target's expected input) -- adapting events to targets. Archive and replay: archiving events (storing the event history) and replaying them (re-delivering archived events -- for recovery, testing, or reprocessing) -- event history and replay.
Bottom rows: comparison and patterns. vs SNS/SQS: EventBridge (content-based routing, broad integration, schema registry, transformation -- rich event routing) vs SNS (pub/sub topics -- simpler fan-out, higher throughput, lower latency) vs SQS (queues -- buffering, at-least-once, decoupling producer/consumer rates) -- different strengths (EventBridge for rich content-based routing and integration; SNS for high-throughput fan-out; SQS for buffering/queuing), chosen for the need. EDA patterns: event-driven architecture patterns -- choreography (services reacting to events, coordinating via events rather than a central orchestrator) and decoupling (producers and consumers independent) -- EventBridge enabling these EDA patterns. The ops strip: schema management (managing the event schemas -- the contracts; schema evolution -- changing schemas without breaking consumers), DLQ (dead-letter queues for failed event deliveries -- so undeliverable events aren't lost, but captured for investigation), and monitoring (monitoring the event routing -- rule matches, delivery success/failure, latency -- for reliability).
End-to-end flow
Trace an event-driven flow through EventBridge. An order service places an order and publishes an 'OrderPlaced' event to EventBridge (the producer -- emitting the event, without knowing the consumers). EventBridge routes it via rules: a rule matching 'OrderPlaced' events (the event pattern -- source 'orders', detail-type 'OrderPlaced') routes to a fulfillment Lambda (a target); another rule (matching 'OrderPlaced' events with amount > 1000 -- content-based filtering) routes to a fraud-check Step Function (a different target, for high-value orders); another routes to an analytics SQS queue. So the single 'OrderPlaced' event is routed to multiple consumers (fulfillment, fraud-check for high-value, analytics) based on the rules (content-based -- the fraud-check only for high-value orders) -- the producers and consumers decoupled (the order service emits the event without knowing these consumers; the consumers subscribe via rules). The event-driven flow (the order event routed to the interested consumers, decoupled, content-filtered) is enabled by EventBridge -- the central event bus routing the event.
The content-filtering and transformation vignettes show the capabilities. A content-filtering case: the fraud-check should only run for high-value orders (amount > 1000). The rule's event pattern includes the content filter (matching events where the amount > 1000) -- so the fraud-check target receives only the high-value orders (the content-based filtering routing only the relevant events) -- fine-grained routing (the fraud-check getting exactly the events it cares about, filtered by content). A transformation case: a target (a legacy consumer) expects the event in a specific structure (different from the raw 'OrderPlaced' event). EventBridge's input transformation reshapes the event (extracting and reformatting the fields to the target's expected structure) before delivering -- so the target receives the event in its expected format (the transformation adapting the event) -- without the producer needing to know the target's format (the decoupling maintained, the transformation bridging).
The comparison and archive/replay vignettes complete it. A comparison case: the team chooses EventBridge for the rich content-based routing (the fine-grained, content-filtered routing to different consumers -- fulfillment, fraud-check, analytics) and AWS integration; for a simple high-throughput fan-out (broadcasting a message to many subscribers), they'd use SNS (simpler, higher throughput); for buffering work (queuing tasks for workers to process at their rate), they'd use SQS -- matching the messaging service to the need (EventBridge for rich routing, SNS for fan-out, SQS for queuing). An archive/replay case: the team archives the events (storing the event history) -- so when they add a new consumer (a new analytics processor), they can replay the archived events (reprocessing the historical events through the new consumer) -- or recover from a processing failure (replaying the events that failed) -- the archive/replay enabling reprocessing and recovery. The consolidated discipline the team documents: use EventBridge as the central event bus for event-driven architecture (routing events from producers to consumers, decoupled), leverage content-based routing (rules matching event patterns on content -- fine-grained routing to the interested consumers), use the capabilities (schema registry for contracts, transformation for adapting events, archive/replay for reprocessing/recovery), choose EventBridge vs SNS/SQS by need (EventBridge for rich content-based routing, SNS for fan-out, SQS for queuing), manage schemas (contracts, evolution), use DLQs (for failed deliveries), and monitor the routing -- because EventBridge is the serverless event bus enabling decoupled, event-driven architectures on AWS, with powerful content-based routing and broad integration, central to serverless EDA.