EventBridge Pipes is a newer feature (2022) that complements the event bus model. While the event bus handles fan-out routing, Pipes handles point-to-point enrichment pipelines — connecting a single source to a single target with optional filtering and transformation in between.
The Pipe Model
A Pipe has four stages:
[Source] → [Filter] → [Enrichment] → [Target]
- Source: A polling source — SQS queue, Kinesis stream, DynamoDB stream, Kafka topic, or MQ broker.
- Filter: Optional — drop events that don't match a pattern (same syntax as EventBridge rules).
- Enrichment: Optional — call a Lambda function, Step Functions workflow, or API Gateway to add data to the event before it reaches the target.
- Target: Where the enriched event goes — Lambda, SQS, EventBridge bus, HTTP endpoint, etc.
When to Use Pipes vs. Event Bus
| Scenario | Use |
|---|---|
| One event, many consumers | Event Bus + Rules |
| One source, one target, with enrichment | Pipes |
| SQS → Lambda with field filtering | Pipes |
| React to DynamoDB stream changes | Pipes |
| SaaS event → multiple AWS services | Event Bus (Partner source) |
Example: You have a DynamoDB table of customer records. When a customer's status field changes to "churned", you want to call a Lambda that fetches their last 30 days of activity from an API, then send the enriched record to a "Churn Analysis" SQS queue.
Without Pipes, you'd need: DynamoDB Streams → Lambda (to filter and enrich) → SQS. With Pipes, this is a single configured resource with no glue Lambda required for the filtering step.