EventBridge Architecture: Event Mesh, Pipes & Failure Routing
EventBridge is not a cron service — it is a content-aware event router that decouples publishers from consumers across service, account, and SaaS boundaries. This article covers custom vs partner event buses, content-based rule pattern matching, input transformers, EventBridge Pipes replacing traffic-cop Lambda functions, Schema Registry auto-discovery, Archive and Replay for disaster recovery, and the distinct DLQ semantics across Lambda, SQS, SNS, and EventBridge.
AWS Serverless Engineering: Lambda to Production
EventBridge Architecture: Event Mesh, Pipes & Failure Routing
Every AWS primitive is a tradeoff surface, not a feature toggle. Engineers who discover EventBridge through the AWS console often find it through the "Scheduled rules" section and conclude it is a more capable cron service. This is a fraction of what EventBridge does. EventBridge is a content-aware event router that can filter events by their field values, transform their payloads, route them across account boundaries, and — via Pipes — eliminate the Lambda functions whose entire purpose is "receive event from source, filter it, send to target." If your architecture has Lambda functions that do nothing except deserialize, filter, and re-serialize, EventBridge Pipes is the primitive that makes those functions unnecessary.
1. Event Buses — Default, Custom, and Partner
EventBridge organizes event routing through buses. Every AWS account has one default event bus (receives AWS service events) and can create custom buses (for domain events) and subscribe to partner buses (SaaS integrations).
1.1 Bus Types
1.2 Event Rules — Content-Based Routing
An event rule matches events from a bus based on their content and routes matching events to one or more targets.
Supported pattern operators:
| Operator | Example | Matches |
|---|---|---|
| Exact string | { status: ["CONFIRMED"] } |
status === "CONFIRMED" |
| Prefix | { source: [{ prefix: "com.myapp" }] } |
any source starting with com.myapp |
| Anything-but | { status: [{ "anything-but": ["CANCELLED"] }] } |
any status except CANCELLED |
| Exists | { errorCode: [{ exists: true }] } |
event has an errorCode field |
| Numeric range | { total: [{ numeric: [">=", 100, "<", 1000] }] } |
100 ≤ total < 1000 |
1.3 Input Transformers
Input transformers reshape the EventBridge event payload before it reaches the target:
2. EventBridge Pipes — Eliminating Traffic-Cop Lambda Functions
EventBridge Pipes provide a managed source → filter → enrichment → target pipeline without Lambda code.
2.1 The Traffic-Cop Lambda Anti-Pattern
2.2 Pipe Sources and Targets
| Sources | Targets |
|---|---|
| SQS | Lambda |
| Kinesis | SQS |
| DynamoDB Streams | SNS |
| Amazon MQ (ActiveMQ, RabbitMQ) | EventBridge event bus |
| Managed Kafka (MSK) | Step Functions |
| Self-managed Kafka | API Gateway (REST + HTTP) |
| API Destinations (external HTTP) |
3. Schema Registry — Type-Safe Event Contracts
EventBridge Schema Registry auto-discovers schemas from events flowing through the event bus and generates TypeScript, Python, or Java type bindings.
Schema Registry makes schema drift a compile error in strongly typed consumers. When you add a new required field to an event's schema, TypeScript consumers that reference the auto-generated binding fail to compile until they handle the new field. This is the correct enforcement mechanism for event-driven system evolution — significantly better than discovering schema drift at runtime.
4. Archive and Replay — Serverless Disaster Recovery
EventBridge Archive records every event that matches an archive rule to an S3-backed store. Archive and Replay enables replaying events from any time window — the serverless DR primitive for event-driven systems.
An event-driven system without archive-and-replay has no recovery path for consumer bugs that silently misprocessed events — if the original source (DynamoDB, RDS) no longer holds the data, the events and their intended effects are permanently lost. Archive is cheap (S3 pricing) and pays for itself the first time you need to replay.
5. DLQ Semantics Across Four Services
This is the most important operational distinction for multi-service architectures. Each service's DLQ captures failures at a different layer.
| Service | DLQ fires when | What is captured | Redrive mechanism |
|---|---|---|---|
| Lambda async | All Lambda invocation retries exhausted (async invocations only) | Full event payload | Manual re-invoke with DLQ payload |
| SQS | Message received maxReceiveCount times without deletion |
Full SQS message + metadata | StartMessageMoveTask API |
| SNS | All delivery attempts to a specific subscription exhausted | Full SNS message | Manual republish to topic |
| EventBridge | Rule target delivery fails after retries | Full event envelope | Manual PutEvents from DLQ payload |


Summary
| Concept | Rule |
|---|---|
| EventBridge buses | Default (AWS service events), Custom (domain events), Partner (SaaS) |
| Content-based rules | Match on source, detail-type, detail.* — prefix, exists, numeric range operators available |
| EventBridge Pipes | Replace traffic-cop Lambda for source→filter→transform→target pipelines with zero code |
| Schema Registry | Auto-discovers schemas; generates type bindings; makes schema drift a compile error |
| Archive and Replay | Serverless DR primitive — replay from any time window after consumer bug fixes |
| DLQ semantics | Service-specific — Lambda/SQS/SNS/EventBridge each require separate alarms and redrive runbooks |
What's Next
In Part 11: Serverless Security — IAM, VPC Networking & Secrets Governance, we turn to cross-cutting security concerns: why a shared IAM role across all Lambda functions is the serverless equivalent of running as root, how VPC Endpoints eliminate NAT Gateway data processing charges, and the break-even calculation that makes VPC Endpoints almost always cheaper than NAT for DynamoDB and S3 traffic.
This article was developed with AI-assisted deep search, specification cross-referencing, and technical research synthesis.