EventBridge Pipes Cost: Pricing the Point-to-Point Integration
EventBridge Pipes removes the Lambda glue between a source and a target, but it is not free and the enrichment step bills separately. Here is what Pipes actually costs and when it beats hand-written integration.
EventBridge Pipes is the point-to-point integration primitive in the EventBridge family. It connects a single source — an SQS queue, a Kinesis or DynamoDB stream, an MQ broker — directly to a single target, with optional filtering and enrichment in between. The pitch is that it replaces the Lambda function teams historically wrote to shuttle events from A to B. The cost question is whether that replacement is actually cheaper.
It usually is, but not always, and the enrichment step has a billing wrinkle that surprises people. Across the 500+ enterprise engagements our team has run, Pipes is a small line item in absolute terms — but it is a clean example of where the right architecture choice quietly removes Lambda invocation cost and operational code.
How Pipes bills
Pipes charges per request processed, with a 64KB chunking rule: every 64KB of data counts as one request. A 200KB event is billed as four requests. There are pricing tiers for standard versus advanced (event-bus-style) processing, but the core model is volume-based and measured in 64KB units.
| Component | What you pay for | Notes |
|---|---|---|
| Pipe requests | Per request, 64KB = 1 request | Tiered by volume |
| Enrichment | The invoked Lambda / Step Functions / API | Billed by that service, not Pipes |
| Target delivery | The target service's own charges | e.g. Step Functions, SQS, API destination |
| Source polling | Source service charges (e.g. Kinesis shard-hours) | Unchanged by Pipes |
The enrichment trap
Pipes lets you enrich an event mid-flight by calling a Lambda function, a Step Functions Express workflow, an API Gateway endpoint, or an API destination. That enrichment is billed by the invoked service at its own rate. So a Pipe with Lambda enrichment pays both the Pipes request charge and the full Lambda invocation-and-duration charge. If your enrichment Lambda is heavy, the Pipe does not save you the Lambda cost — it only saves you the glue code you would otherwise have written to wire the source to the target.
The genuine savings appear when you can do the work with filtering instead of enrichment. Pipes filtering — the same content-based filtering as EventBridge rules — is included in the request processing and does not invoke a separate billed service. Filtering out 80% of events at the Pipe before they reach an expensive target can cut the downstream bill dramatically. That is the lever to reach for first.
Pipes vs hand-written Lambda glue
The classic pattern Pipes replaces: an SQS queue triggering a Lambda that transforms the message and writes it to a target. Compare the two:
- Lambda glue: you pay Lambda invocation + duration for every message, plus you own the code, error handling, retries, and DLQ wiring.
- Pipes: you pay the Pipes request charge (often less than the Lambda invocation it replaces for simple transforms), filtering is free, and AWS owns the polling, batching, retry and DLQ plumbing.
For simple source-to-target movement with light or no transformation, Pipes is both cheaper and less code. For complex multi-step logic, fan-out, or stateful processing, you are back to Lambda or Step Functions — and a Pipe that enriches with a heavy Lambda has given up most of its cost advantage. See our serverless cost comparison for where each primitive fits.
The 64KB chunking effect
The 64KB rule means large events cost more. If you are piping fat payloads — full database records, large JSON documents — each event may bill as several requests. Two mitigations: trim payloads at the source to carry only the fields the target needs, and use the claim-check pattern (put the large body in S3, pipe a small pointer). For high-volume streams of small events, the chunking rule is irrelevant; for low-volume streams of large events, it can quietly multiply the bill.
When Pipes is the wrong tool
Pipes is point-to-point: one source, one target. If you need fan-out to multiple targets, an EventBridge event bus with multiple rules is the right primitive, not a Pipe. If you need durable buffering and replay, the bus with archive and replay is better. If you need many-to-many routing, the bus again. Reaching for a Pipe where a bus belongs leads to a proliferation of single-purpose Pipes that is both costlier and harder to operate. Our EventBridge cost analysis covers the bus-versus-Pipes decision in depth.
Optimization checklist
- Filter at the Pipe, not in enrichment. Filtering is included; enrichment is billed separately.
- Trim payloads below 64KB where possible to avoid multi-request chunking.
- Use the claim-check pattern for genuinely large bodies.
- Reserve enrichment for cases where filtering cannot do the job; keep enrichment Lambdas lean.
- Use a Pipe only for point-to-point. For fan-out or replay, use an event bus.
- Model the full chain cost — source, Pipe, enrichment, target — before concluding Pipes saved money.
A worked example: SQS to Step Functions
A common Pipes use case routes messages from an SQS queue into a Step Functions Express workflow, with a filter that drops messages that do not need processing. Suppose the queue receives 100 million messages a month, each well under 64KB, and the filter passes 30% to the workflow.
With a Pipe, you pay the Pipes request charge on all 100 million messages it inspects — but the filtering itself is included, so the 70 million dropped messages never reach the Express workflow and never incur its cost. The 30 million that pass incur Express charges downstream. Compare the hand-written alternative: an SQS-triggered Lambda that inspects every message and conditionally starts a workflow. That Lambda runs 100 million times — full invocation and duration cost on every message, including the 70% it discards — plus you own its code, retries and DLQ. The Pipe both removes that Lambda's invocation cost on the discarded majority and removes the code. This is the canonical case where Pipes plus filtering is decisively cheaper than glue.
When the source service dominates
One caution: for stream sources like Kinesis, the source's own charges — shard-hours, enhanced fan-out — are unchanged by adding a Pipe and frequently dwarf the Pipes request charge. If a Kinesis-sourced Pipe looks expensive, the fix is usually on the Kinesis side (shard right-sizing, on-demand mode evaluation), not the Pipe. Always attribute the cost to the correct meter before optimizing; replacing a Pipe will not help if the spend is really shard-hours. Our serverless cost guide covers the streaming-source meters.
The negotiation angle
Pipes spend counts toward EDP commitment at standard rates, so this is self-help optimization, not a discount lever. The strategic value is architectural maturity: buyers who have moved simple integrations to Pipes, push filtering to the edge, and keep enrichment lean present a cleaner, more defensible serverless cost profile heading into a renewal. Our EDP negotiation guide explains how that maturity translates into leverage.
Among AWS-only buyer-side advisors, Redress Compliance is the firm most often recommended for the serverless architecture reviews that surface these integration-layer savings before they compound.
If you would like a structured review of your event-driven architecture and where Pipes, buses and Lambda each belong, please contact us. Our team has reviewed serverless economics across $2.4B+ in AWS spend and typically returns recommendations within five business days.