How do Pipes differ from EventBridge rules?

EventBridge rules react to events on an event bus — events must first be published to the bus. Pipes provide point-to-point integration between a source and a target without an event bus in the middle. Pipes support sources that rules cannot (SQS queues, Kinesis streams, DynamoDB Streams, Kafka topics, MQ brokers) and include built-in batching, filtering, and enrichment stages. Use rules for fan-out (one event, many targets) and Pipes for point-to-point integration with stream/queue sources.

What is the enrichment stage used for?

The enrichment stage lets you call a Lambda function, Step Functions state machine, API Gateway endpoint, or API destination to augment the event before it reaches the target. Common uses include looking up additional data from a database, transforming the event format, performing validation, or calling an external API. The enrichment response replaces or augments the event payload. If you do not need enrichment, you can skip this stage entirely — the pipe will pass the (optionally filtered and transformed) source event directly to the target.

EventBridge Pipes Config Builder

ServerlessAWS

Build EventBridge Pipes source, filter, enrichment, and target configurations.

Last verified: May 2026

EventBridge Pipes Configuration

Build EventBridge Pipes source-filter-enrichment-target configs for event-driven architectures.

Required Fields

NameRoleArnSourceTarget

{
  "Name": "sqs-to-stepfunctions-pipe",
  "Description": "Process SQS messages through enrichment and route to Step Functions",
  "RoleArn": "arn:aws:iam::123456789012:role/PipesExecutionRole",
  "DesiredState": "RUNNING",
  "Source": "arn:aws:sqs:us-east-1:123456789012:order-events-queue",
  "SourceParameters": {
    "SqsQueueParameters": {
      "BatchSize": 10,
      "MaximumBatchingWindowInSeconds": 30
    },
    "FilterCriteria": {
      "Filters": [
        {
          "Pattern": "{\"body\": {\"eventType\": [\"ORDER_PLACED\", \"ORDER_UPDATED\"]}}"
        }
      ]
    }
  },
  "Enrichment": "arn:aws:lambda:us-east-1:123456789012:function:enrich-order-data",
  "EnrichmentParameters": {
    "InputTemplate": "{\"orderId\": <$.body.orderId>, \"customerId\": <$.body.customerId>}"
  },
  "Target": "arn:aws:states:us-east-1:123456789012:stateMachine:process-order",
  "TargetParameters": {
    "StepFunctionStateMachineParameters": {
      "InvocationType": "FIRE_AND_FORGET"
    },
    "InputTemplate": "{\"orderId\": <$.orderId>, \"enrichedData\": <$.enrichmentResult>}"
  },
  "LogConfiguration": {
    "CloudwatchLogsLogDestination": {
      "LogGroupArn": "arn:aws:logs:us-east-1:123456789012:log-group:/aws/pipes/sqs-to-sfn"
    },
    "Level": "ERROR"
  },
  "Tags": {
    "Environment": "production",
    "Team": "order-processing"
  }
}

Generated Output

Output will appear here...

About This Tool

Amazon EventBridge Pipes connects event sources to targets with optional filtering, enrichment, and transformation — all without writing custom integration code. A pipe has four stages: source (SQS, Kinesis, DynamoDB Streams, Kafka, or MQ), filter (EventBridge pattern matching to select events), enrichment (optional Lambda, Step Functions, or API Gateway call to augment events), and target (over 15 AWS services). The Pipes Config Builder helps you configure each stage with proper source parameters, filter patterns, enrichment settings, and target input transformations.

Real-World Scenario

Your team's order pipeline currently has: SQS → Lambda (transforms message + filters by region + calls Step Functions) → Step Functions. Lambda is 200 lines, runs millions of times/month, and has cold-start latency on first invocations. The builder helps replace it with an EventBridge Pipe: SQS source → filter on `detail.region == "us-east"` → input transform reshaping the payload → Step Functions target. The Lambda is decommissioned. Cost drops ~60%, latency improves (no Lambda cold starts), and 200 lines of code retire.

When to Use This Tool

•Connecting DynamoDB Streams to Step Functions with filtering to process only INSERT events for specific partition key patterns
•Building a pipe from SQS to Lambda with enrichment that looks up customer data before invoking the target
•Configuring Kinesis-to-EventBridge pipes with batch size, starting position, and dead-letter queue settings

Pro Tips

TIP

EventBridge Pipes eliminate ~80% of the 'Lambda function that just transforms events between services' code. Instead of writing a Lambda to read from SQS, transform, and call Step Functions, define a Pipe with input transformation. Less code, faster, cheaper.

TIP

Filter early in the pipe stages. Filtering at the source level (Pipes filter stage) drops events before they consume enrichment Lambda invocations — much cheaper than filtering in the enrichment function and discarding events.

TIP

DynamoDB Streams + Pipes + Step Functions is the modern pattern for event-driven workflows. Old way: DDB Stream → Lambda (parses event, transforms, invokes Step Functions). New way: DDB Stream → Pipe (filter + transform) → Step Functions. Less code to maintain, fewer failure modes.

How It Works Under the Hood

The builder constructs EventBridge Pipes definitions with the four stages: source (SQS, Kinesis, DDB Streams, Kafka, MQ, with batching/starting position config), filter (EventBridge pattern matching), enrichment (optional Lambda/Step Functions/API Gateway/API destination), and target (any of 15+ AWS services with input transformation). Output is generated as aws pipes create-pipe commands and Terraform aws_pipes_pipe resources.

Frequently Asked Questions

How do Pipes differ from EventBridge rules?: EventBridge rules react to events on an event bus — events must first be published to the bus. Pipes provide point-to-point integration between a source and a target without an event bus in the middle. Pipes support sources that rules cannot (SQS queues, Kinesis streams, DynamoDB Streams, Kafka topics, MQ brokers) and include built-in batching, filtering, and enrichment stages. Use rules for fan-out (one event, many targets) and Pipes for point-to-point integration with stream/queue sources.
What is the enrichment stage used for?: The enrichment stage lets you call a Lambda function, Step Functions state machine, API Gateway endpoint, or API destination to augment the event before it reaches the target. Common uses include looking up additional data from a database, transforming the event format, performing validation, or calling an external API. The enrichment response replaces or augments the event payload. If you do not need enrichment, you can skip this stage entirely — the pipe will pass the (optionally filtered and transformed) source event directly to the target.

Related Learning Guides

SQS vs SNS vs EventBridge25 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.