Amazon EventBridge quietly became one of the busiest pieces of plumbing on AWS, and most teams still wire it up by trial and error. If you have ever watched a Lambda function silently fail to fire, or spent an afternoon debugging why an event pattern matched nothing, you already know why a clear setup guide matters. This tutorial walks through building a real event-driven pipeline on EventBridge from a cold account to a working, monitored system, using the current console, CLI, and pricing as of August 19, 2026.
By the end you will have a custom event bus, a schema-aware rule, a Lambda target, a Step Functions target, a scheduled task through EventBridge Scheduler, and a dead-letter queue catching anything that fails. We will also cover the newest addition to the service, EventBridge AI Workflow Studio, which shipped in mid-August 2026 as a visual layer for building AI-connected event workflows on top of the same rules engine you are about to learn by hand.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Amazon EventBridge Actually Does
EventBridge is AWS’s serverless event bus. It ingests JSON events from AWS services, your own applications, and roughly 40 SaaS partners — a producer list that keeps growing, with Timestream for InfluxDB starting to publish lifecycle events in July 2026, Secrets Manager adding automatic secret-update notifications at no additional cost that same month, and MWAA Serverless wiring in four new workflow and task-state events in June 2026 — then routes matching events to targets based on rules you define. The mental model is simple: producers publish events, EventBridge evaluates them against rule patterns, and matched events get pushed to targets like Lambda, Step Functions, SQS, or another event bus entirely, including across accounts and regions.
Unlike SQS, there is no polling. Unlike SNS, routing is based on the actual content of the event body, not just a static subscription. That content-based routing is what makes EventBridge the backbone for event-driven architecture on AWS rather than a simple notification pipe. Every AWS account gets a default event bus for free, and you can create up to 100 custom event buses per region for your own applications, according to AWS’s published EventBridge service quotas.
The service has five moving parts worth knowing before you touch the console: event buses, rules, targets, the schema registry, and two newer additions, EventBridge Pipes and EventBridge Scheduler. Each has its own quota and billing model, which is where most first-time bills come as a surprise — and those quotas are still moving: AWS quadrupled the maximum event payload from 256 KB to 1 MB in January 2026, so the size limits you may remember from older tutorials are already out of date. AWS’s pricing documentation listed four distinct event-bus types as of September 2026 — the original Classic bus alongside a new enhanced Custom event bus — and the tooling moved just as fast: AWS CLI 2.37.3 renamed the eventbridgev2 command namespace to eventsv2 that same month, according to Classmethod, so scripts written against the old command name will need a quick find-and-replace.
| Component | Purpose | Default Quota (2026) | Increaseable |
|---|---|---|---|
| Rules per event bus | Match events by pattern or schedule | 300 (100 in af-south-1, eu-south-1) | Yes, to thousands via Service Quotas |
| Targets per rule | Where matched events get delivered | 5 targets per rule | No |
| Event buses per region | Logical grouping of rules and traffic | 100 | Yes |
| Max event size | Payload limit per event | 1 MB (raised from 256 KB in Jan. 2026) | No |
| Invocation rate | Events per second per region | Up to hundreds of thousands/sec | Yes via Service Quotas |
Prerequisites
You do not need a large stack to follow along, but you do need a few things set up correctly before step one. Missing IAM permissions is the single most common reason people abandon EventBridge tutorials halfway through, so double-check this list.
- An AWS account with billing enabled (EventBridge has a free tier for default-bus AWS service events, but custom events are billed from the first event)
- AWS CLI installed and configured — this guide uses AWS CLI v2, verify your local install with
aws --version - An IAM user or role with
AmazonEventBridgeFullAccess,AWSLambda_FullAccess, andAWSStepFunctionsFullAccessfor the tutorial (scope this down for production) - Node.js 20.x or Python 3.13 installed locally if you want to write the sample Lambda function in either language
- A text editor and basic familiarity with JSON — event patterns are JSON, and syntax errors are the number one cause of “my rule never fires”
- Around 90 minutes of uninterrupted time; the AI Workflow Studio section at the end is optional and adds roughly 15 minutes
Before diving in, confirm your CLI is authenticated correctly:
aws sts get-caller-identity
aws --versionYou should see your account ID, user ARN, and an aws-cli/2.x.x version string. If this command fails, fix your credentials before continuing — every step below assumes a working CLI session.
Step 1: Create a Custom Event Bus
The default event bus already exists in every account and receives events from AWS services for free. For your own application events, though, you want a custom bus — and as of September 24, 2026, AWS shipped a meaningfully upgraded one: the enhanced Custom event bus, confirmed as of October 2026 to span 14 AWS Regions including Tokyo, Singapore, Sydney, and Mumbai, ships with 24-hour built-in retention out of the box (extendable up to a full year) and adds strict event ordering, a guarantee the original bus never offered. Keeping application traffic off the default bus makes debugging dramatically easier because you are not sifting through EC2 state changes and CloudTrail noise to find your own events.
aws events create-event-bus --name order-processing-bus
# Confirm it was created
aws events list-event-buses --name-prefix order-processingYou can also do this through the console: open the EventBridge service, select Event buses in the left navigation, click Create event bus, name it, and leave archiving off for now (we will enable it later). If you opt into the enhanced Custom event bus, it accepts CloudEvents and other JSON formats natively with no schema modification required, performs automatic content-based event deduplication, and pairs with a new Subscriber resource — also introduced in September 2026 — that delivers filtered events directly to more than 250 AWS services. Each region supports up to 100 event buses, so a bus-per-microservice pattern is realistic even for a mid-sized architecture.
Step 2: Design Your First Event Pattern
Every rule needs an event pattern, and this is where most setup guides skip the nuance. A pattern is a JSON structure that EventBridge matches against incoming events field by field. The two fields you will always specify are source and detail-type, then you filter deeper into the detail object for anything specific to your business logic.
Save this as order-created-pattern.json:
{
"source": ["myapp.orders"],
"detail-type": ["Order Created"],
"detail": {
"orderValue": [{ "numeric": [">", 100] }],
"status": ["pending", "processing"]
}
}This pattern only matches orders over $100 that are still pending or processing — everything else gets ignored, even though it is on the same bus. That numeric comparison operator is a common stumbling block; forgetting the array wrapper around {"numeric": [">", 100]} is one of the most frequent syntax errors developers hit when writing EventBridge patterns.
Step 3: Create the Rule and Attach a Lambda Target
With the pattern ready, create the rule on your custom bus and point it at a Lambda function. If you do not already have a function to test with, create a minimal one first.
# Create the rule
aws events put-rule \
--name high-value-order-rule \
--event-bus-name order-processing-bus \
--event-pattern file://order-created-pattern.json \
--state ENABLED
# Grant EventBridge permission to invoke your Lambda function
aws lambda add-permission \
--function-name ProcessHighValueOrder \
--statement-id AllowEventBridgeInvoke \
--action lambda:InvokeFunction \
--principal events.amazonaws.com \
--source-arn arn:aws:events:us-east-1:123456789012:rule/order-processing-bus/high-value-order-rule
# Attach the Lambda as a target
aws events put-targets \
--rule high-value-order-rule \
--event-bus-name order-processing-bus \
--targets "Id"="1","Arn"="arn:aws:lambda:us-east-1:123456789012:function:ProcessHighValueOrder"That add-permission call is the step almost everyone forgets, and it is the leading cause of “my rule matched but nothing happened.” EventBridge needs an explicit resource-based policy on the target granting events.amazonaws.com permission to invoke it — the rule itself firing successfully in CloudWatch metrics tells you nothing about whether the target actually received the event.
Step 4: Test the Rule End to End
Send a test event manually before wiring up real application traffic. This confirms the whole chain — bus, pattern, permission, target — works before you debug it under load.
aws events put-events --entries '[
{
"Source": "myapp.orders",
"DetailType": "Order Created",
"EventBusName": "order-processing-bus",
"Detail": "{\"orderValue\": 250, \"status\": \"pending\", \"orderId\": \"ord_9981\"}"
}
]'Then check your Lambda’s CloudWatch log group for a new invocation. If nothing shows up, work backward: check the rule’s FailedInvocations metric in CloudWatch first, then re-verify the Lambda resource policy, then re-check your event pattern syntax with the built-in pattern tester in the console (Rules → your rule → Sample events tab).
Step 5: Add a Dead-Letter Queue for Failed Deliveries
EventBridge retries failed target invocations for up to 24 hours by default, but eventually it gives up, and without a dead-letter queue those events vanish silently. This is the step most tutorials skip, and it is the one that saves you a 2 a.m. page when it matters.
aws sqs create-queue --queue-name eventbridge-dlq
DLQ_ARN=$(aws sqs get-queue-attributes \
--queue-url https://sqs.us-east-1.amazonaws.com/123456789012/eventbridge-dlq \
--attribute-names QueueArn --query "Attributes.QueueArn" --output text)
aws events put-targets \
--rule high-value-order-rule \
--event-bus-name order-processing-bus \
--targets "Id"="1","Arn"="arn:aws:lambda:us-east-1:123456789012:function:ProcessHighValueOrder","DeadLetterConfig"="{\"Arn\":\"$DLQ_ARN\"}","RetryPolicy"="{\"MaximumRetryAttempts\":3,\"MaximumEventAgeInSeconds\":3600}"Set a CloudWatch alarm on ApproximateNumberOfMessagesVisible for that queue. Anything landing in the DLQ means either your Lambda is erroring or your IAM permissions drifted, and you want to know within minutes, not when a customer complains.
Step 6: Route the Same Event to Step Functions
A single rule can fan out to up to five targets processed in parallel, which is where EventBridge earns its keep over a simple queue. Add a Step Functions state machine as a second target on the same rule to kick off a multi-step order fulfillment workflow whenever the Lambda notification target fires.
aws events put-targets \
--rule high-value-order-rule \
--event-bus-name order-processing-bus \
--targets \
"Id"="1","Arn"="arn:aws:lambda:us-east-1:123456789012:function:ProcessHighValueOrder" \
"Id"="2","Arn"="arn:aws:states:us-east-1:123456789012:stateMachine:OrderFulfillmentWorkflow","RoleArn"="arn:aws:iam::123456789012:role/EventBridgeToStepFunctionsRole"Note the RoleArn parameter — Step Functions targets need an IAM role rather than a resource-based policy, which trips up people used to the Lambda pattern from Step 3. That used to be an inconsistency you just had to memorize, but AWS expanded IAM execution-role support to all EventBridge target types in March 2025, so the same explicit-role model shown here now applies uniformly instead of varying target by target. The role needs states:StartExecution permission scoped to your state machine.
Step 7: Schedule Recurring Jobs With EventBridge Scheduler
EventBridge Scheduler is a separate, newer capability from rule-based scheduling (the old cron() and rate() expressions on rules still work, but Scheduler is the recommended path for anything new). It reached every AWS Region in July 2025, and AWS has kept expanding it since: May 2026 brought 619 new SDK API actions across 13 services for building and managing schedules programmatically, and in March 2026 the CreateSchedule quota was raised to 5,000 requests per second across 11 Regions. It is built to manage millions of individual schedules without you provisioning infrastructure, and it is billed and quota-managed independently from the core event bus, with a free tier that AWS’s October 2026 pricing guidance still lists at 14 million invocations per month before the $1.00-per-million-invocation rate kicks in.
aws scheduler create-schedule \
--name daily-order-report \
--schedule-expression "cron(0 9 * * ? *)" \
--flexible-time-window "Mode=OFF" \
--target '{
"Arn": "arn:aws:states:us-east-1:123456789012:stateMachine:GenerateDailyReport",
"RoleArn": "arn:aws:iam::123456789012:role/EventBridgeSchedulerRole"
}'This example runs a Step Functions state machine every day at 9 a.m. UTC. Scheduler supports one-off invocations too, using at() expressions instead of cron(), which is handy for delayed jobs like “send this reminder in 30 days” without building your own delay queue.
Step 8: Filter and Transform With EventBridge Pipes
EventBridge Pipes solves a different problem than rules: point-to-point integration between a source (typically SQS, Kinesis, or DynamoDB Streams) and a single target, with optional filtering and enrichment in between, without you writing glue Lambda code just to move data. Where rules are about fan-out from one event to many targets, Pipes is about a clean, filtered pipe from one source to one target.
aws pipes create-pipe \
--name sqs-to-lambda-enriched \
--role-arn arn:aws:iam::123456789012:role/PipesExecutionRole \
--source arn:aws:sqs:us-east-1:123456789012:incoming-orders \
--target arn:aws:lambda:us-east-1:123456789012:function:EnrichAndForward \
--source-parameters '{"FilterCriteria":{"Filters":[{"Pattern":"{\"body\":{\"priority\":[\"high\"]}}"}]}}'Pipes is billed at $0.40 per million requests after filtering, with no free tier, which is cheaper per-event than routing the same traffic through a full rule-and-target setup if all you need is a filtered pass-through.
Step 9: Register a Schema and Generate Code Bindings
Once you have more than one team publishing events onto a bus, undocumented event shapes become a real problem. The EventBridge schema registry solves this by capturing the structure of events automatically (schema discovery) or letting you register one manually, then generating strongly-typed code bindings for Java, Python, TypeScript, and Go.
aws schemas create-registry --registry-name order-events-registry
aws schemas create-schema \
--registry-name order-events-registry \
--schema-name OrderCreated \
--type OpenApi3 \
--content file://order-created-schema.jsonTurn on schema discovery on your custom bus in the console (Event buses → your bus → Start discovery) if you would rather have EventBridge infer schemas from real traffic instead of hand-writing them. Just remember to turn it off again once your schemas stabilize — discovery adds a small per-event processing cost while active.
Step 10: Enable Event Replay and Archiving
Archiving lets you retain a copy of every event that flows through a bus, and replay lets you resend them later — invaluable when you deploy a buggy consumer and need to reprocess a window of missed events instead of asking upstream systems to republish.
aws events create-archive \
--archive-name order-events-archive \
--event-source-arn arn:aws:events:us-east-1:123456789012:event-bus/order-processing-bus \
--retention-days 30
# Later, replay a window of archived events back onto the bus
aws events start-replay \
--replay-name reprocess-aug18-outage \
--event-source-arn arn:aws:events:us-east-1:123456789012:event-bus/order-processing-bus \
--event-start-time 2026-08-18T00:00:00Z \
--event-end-time 2026-08-18T06:00:00Z \
--destination '{"Arn":"arn:aws:events:us-east-1:123456789012:event-bus/order-processing-bus"}'Set retention based on how long you realistically need to recover from an incident — 30 days is a reasonable default for most teams, and archiving storage is billed separately from event ingestion.
Step 11: Cross-Account Event Routing
Larger organizations often centralize observability or security events into a single account. EventBridge supports this natively by letting another account’s bus act as a target, at a cost of $1.00 per million events delivered cross-account on the classic bus — though the September 2026 enhanced Custom event bus launch changed that calculus by adding native cross-account sharing through AWS Resource Access Manager and, alongside it, moving enhanced-bus billing away from per-event charging to a data-transfer-based pricing model, priced in AWS’s September 2026 example at $0.05 per GB for the initial delivery leg, so teams routing high-volume cross-account traffic should re-run their cost estimates under the new scheme.
aws events put-permission \
--event-bus-name order-processing-bus \
--action events:PutEvents \
--principal 999988887777 \
--statement-id AllowCentralAccount
aws events put-targets \
--rule high-value-order-rule \
--event-bus-name order-processing-bus \
--targets "Id"="3","Arn"="arn:aws:events:us-east-1:999988887777:event-bus/central-observability-bus"This pattern is common for security teams that want every account’s IAM and CloudTrail-derived events funneled into one central bus for correlation, without granting cross-account read access to every source account.
IAM and Security Best Practices for EventBridge
EventBridge sits at a privileged position in your architecture — it can read from and write to nearly every other AWS service — so the IAM policies you attach to it deserve more care than a quick FullAccess managed policy. Auditing got easier in May 2026, when AWS added PutEvents data-plane logging to CloudTrail, so you can finally see exactly who published which event onto a bus instead of inferring it from downstream side effects. The tutorial permissions above are intentionally broad to keep the walkthrough moving; before this touches production traffic, scope every role down to exactly what it needs.
Least-Privilege Policy for Event Publishers
Applications that only publish events to a bus never need permission to create rules, register schemas, or manage targets. Scope their role down to a single action on a single bus:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": "arn:aws:events:us-east-1:123456789012:event-bus/order-processing-bus"
}
]
}Attach this to the IAM role your application or Lambda function assumes when it publishes order events. It cannot create rules, delete the bus, or read from other buses — a compromised publisher credential is limited to writing events onto one specific bus, nothing more.
Least-Privilege Policy for Rule Management
Your deployment pipeline (CI/CD, CDK, or Terraform) needs a broader but still bounded policy to manage rules and targets without touching unrelated infrastructure:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"events:PutRule",
"events:PutTargets",
"events:DescribeRule",
"events:ListTargetsByRule",
"events:RemoveTargets",
"events:DeleteRule"
],
"Resource": "arn:aws:events:us-east-1:123456789012:rule/order-processing-bus/*"
}
]
}Note that this policy grants nothing on the Lambda or Step Functions side — the deployment role still needs a separate, explicit statement to call lambda:AddPermission or manage the IAM roles that Step Functions and Scheduler targets rely on. Keeping these as distinct statements makes IAM policy reviews far easier, since a reviewer can see exactly what surface each role touches.
For cross-account setups like the one in Step 11, always scope put-permission statements to a specific source account rather than a wildcard principal. An open "Principal": "*" on an event bus effectively makes it a public inbox for anyone who can guess the ARN, which is a mistake that shows up more often than it should in exposed-bucket-style security audits.
Monitoring and Observability for EventBridge
EventBridge publishes a set of CloudWatch metrics automatically, but the defaults are easy to overlook until something breaks in production. AWS extended that visibility to Scheduler too, adding CloudWatch resource-count metrics for schedules and schedule groups at no additional cost in February 2026, so you no longer have to build your own counters just to see how many schedules are active. Building dashboards and alarms around these metrics up front turns a silent failure into a page you can act on before customers notice.
| Metric | What It Tells You | Recommended Alarm |
|---|---|---|
| TriggeredRules | Count of rule matches per period | Alert on unexpected drop to near-zero |
| FailedInvocations | Target invocations that failed after retries | Alarm at any sustained non-zero value |
| ThrottledRules | Rules throttled due to quota limits | Alarm immediately — indicates quota exhaustion |
| MatchedEvents | Events that matched a rule’s pattern | Compare against IngestedEvents to catch pattern drift |
| DeadLetterInvocations | Events routed to a configured DLQ | Alarm at any value above zero |
For deeper tracing across a multi-target rule — say, the Lambda-plus-Step-Functions setup from Step 6 — enable AWS X-Ray on both targets. EventBridge propagates trace headers when X-Ray is active on the publishing side, which lets you follow a single order event from put-events all the way through fraud scoring and fulfillment in one trace map, instead of correlating timestamps across three separate CloudWatch log groups by hand.
A simple CloudWatch alarm for the DLQ backlog looks like this:
aws cloudwatch put-metric-alarm \
--alarm-name eventbridge-dlq-backlog \
--namespace AWS/SQS \
--metric-name ApproximateNumberOfMessagesVisible \
--dimensions Name=QueueName,Value=eventbridge-dlq \
--statistic Maximum \
--period 300 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 \
--alarm-actions arn:aws:sns:us-east-1:123456789012:ops-alertsA single message sitting in the DLQ for more than five minutes is worth waking someone up for on a payments or order pipeline — the volume is low enough that false positives are rare, and the cost of missing a stuck event is usually a lost transaction.
Step 12: Try EventBridge AI Workflow Studio
AWS shipped EventBridge AI Workflow Studio in mid-August 2026 as a visual layer on top of the same rules engine you just configured by hand. It adds a drag-and-drop builder for event-driven workflows using pre-built AI connectors, native integration with S3, SageMaker, DynamoDB, and Step Functions, and context-aware recommendations that suggest triggers, actions, and error handling based on your workflow goals and historical event data.
To try it, open the EventBridge console and look for the new AI Workflow Studio entry in the left navigation. Point it at the order-processing-bus you created in Step 1, and it will surface your existing rules and suggest a SageMaker-backed fraud-scoring step for the high-value order pattern you already built — a useful way to see how the visual layer maps back onto the CLI commands you just ran. It also ships with real-time monitoring, live workflow visualization, anomaly detection, and step-level logs, plus audit trails and compliance templates aimed at regulated teams that need to prove what an AI-driven workflow actually did.
EventBridge Pricing: What You Will Actually Pay
EventBridge pricing has more moving parts than most AWS services, split across the core bus, Pipes, and Scheduler. Events published by AWS services to the default event bus are always free to ingest, with no cap. Everything else is billed from the first event, so a “free tier” mental model does not fully apply here the way it does for Lambda or S3. To put a real number on it, AWS’s own September 2026 pricing example pegs a representative mid-sized EventBridge workload, ingestion, cross-account delivery, Pipes, and Scheduler usage combined, at roughly $2,317 a month, which is a useful sanity check before you assume your bill will stay in the pocket-change range.
| Billing Item | Rate | Free Tier |
|---|---|---|
| Custom events on an event bus | $1.00 per million events ingested | None |
| Cross-account event delivery | $1.00 per million events delivered | Same-account delivery is free |
| AWS service events (default bus) | $0 — always free | Unlimited |
| EventBridge Pipes | $0.40 per million requests (after filter) | None |
| EventBridge Scheduler | $1.00 per million invocations | First 14 million invocations/month free |
| Rule evaluation | $0 — free | Unlimited |
The practical takeaway: rule evaluation itself costs nothing, so you are free to write narrow, specific patterns without worrying about a per-evaluation charge. What you pay for is ingestion and cross-account delivery, which means consolidating event buses per team, rather than per microservice, can meaningfully cut your bill at scale.
EventBridge vs SNS vs SQS: When to Use Which
Teams new to event-driven design on AWS often default to SQS or SNS out of familiarity, then hit a wall once routing logic gets complicated. Here is the practical distinction that should drive your choice.
| Service | Best For | Routing Logic | Delivery Model |
|---|---|---|---|
| EventBridge | Content-based routing across many producers and consumers, SaaS integrations | JSON event patterns matched against event content | Push, up to 5 targets per rule, parallel |
| SNS | Simple pub/sub fan-out, alerts, broadcast notifications | Topic subscription only, no content filtering | Push to all subscribers |
| SQS | Durable async work queues, decoupled processing with backpressure | None — consumer decides what to do | Pull/poll, one consumer processes each message |
A common production pattern combines all three: EventBridge routes based on content, fans out to an SQS queue for durable buffered processing, and separately triggers an SNS topic for a human-facing Slack or email alert. None of the three replaces the others; they solve different layers of the same problem.
Common Pitfalls When Setting Up EventBridge
These are the mistakes that show up repeatedly in support forums and account for most “EventBridge isn’t working” reports. Check against this list before assuming the service itself is broken.
- Forgetting the Lambda resource policy. A rule can match perfectly and still deliver nothing if
events.amazonaws.comwas never grantedlambda:InvokeFunctionon the target function. - Using
detailTypeinstead ofdetail-type. The API field uses a hyphen; camelCase silently fails to match rather than throwing an error, so you get zero matches with no explanation. - Wrapping comparison operators incorrectly. Numeric and prefix matchers need to be inside an array, e.g.
{"numeric": [">", 100]}, not a bare object — a syntax mistake the console pattern validator catches but the CLI does not always flag clearly. - Publishing to the wrong event bus. Custom applications frequently publish to the default bus out of habit, then wonder why their custom-bus rules never fire.
- No dead-letter queue configured. Without one, events that exhaust retries just disappear, with only a CloudWatch metric as evidence anything went wrong.
- Assuming rule evaluation order. Multiple rules on the same bus with overlapping patterns all fire independently and in no guaranteed order — do not build logic that depends on rule sequencing.
- Skipping the IAM role for Step Functions and Scheduler targets. Unlike Lambda, these targets need an explicit
RoleArnpassed at target-creation time, not a resource-based policy.
Troubleshooting EventBridge Setup Issues
When something in your pipeline is not working, work through these checks roughly in order — they cover the overwhelming majority of real-world failures.
- Rule shows “matched” but target never runs: Check the target’s resource-based policy (Lambda) or the rule/target’s IAM role (Step Functions, Scheduler) first — this is the single most common cause.
- Pattern never matches anything: Use the built-in “Test pattern” feature in the console under your rule’s event pattern editor, paste a real sample event, and check for field name typos like
detailTypevsdetail-type. - Events land in the DLQ: Pull a message from the queue and inspect the error payload — it almost always contains the exact Lambda exception or permission error that caused the failure.
- Cross-account delivery silently fails: Confirm you ran
put-permissionon the source bus granting the destination accountevents:PutEvents, and that the target ARN in the destination account is exactly correct, including region. - High latency between event publish and target invocation: Check whether you are hitting the per-region invocation rate quota; request a Service Quotas increase if you are running sustained high-throughput traffic.
- Schema registry shows no discovered schemas: Discovery only captures events published after you enable it — historical events are not retroactively scanned.
- Scheduler shows “schedule created” but never runs: Verify the schedule’s
RoleArnhas permission to invoke the specific target ARN, and check thatFlexibleTimeWindowmode is not silently delaying execution longer than expected. - Pipes enrichment step returns malformed data: Confirm your enrichment Lambda returns a JSON array, even for a single record — Pipes expects an array output from enrichment functions and will error on a bare object.
Advanced Tips for Production EventBridge Deployments
Once the basic pipeline works, a few practices separate a fragile demo from something you can run in production without constant babysitting.
Separate buses by domain, not by team. A bus per bounded business domain (orders, inventory, payments) scales better than a bus per microservice, since it keeps related rules discoverable in one place and reduces the cross-account routing overhead when services move between teams.
Version your event schemas from day one. Add a version field to your detail object even before you have a second version, since retrofitting versioning onto live event contracts consumed by five downstream teams is far more painful than starting with it.
Use input transformers instead of forwarding entire payloads. If a Lambda target only needs three fields from a 50-field event, use InputTransformer on the target definition to shrink the payload EventBridge delivers, reducing both Lambda cold-start payload parsing time and blast radius if a downstream field changes shape.
Monitor FailedInvocations and ThrottledRules metrics as first-class alarms, not an afterthought — these two CloudWatch metrics catch permission drift and quota exhaustion before your DLQ fills up and someone notices manually.
Treat EventBridge AI Workflow Studio as a design tool, not a replacement for infrastructure-as-code. The visual builder is genuinely useful for prototyping a new workflow or onboarding a team member unfamiliar with your event contracts, but export the underlying rule and target definitions into your CloudFormation, CDK, or Terraform stack before it goes to production — do not let hand-built console workflows become untracked infrastructure.
Complete Working Project: Order Processing Pipeline
Putting the steps above together, here is the full architecture you have built by the end of this tutorial, expressed as the shell script you could hand to a teammate to reproduce the entire setup from scratch.
#!/bin/bash
set -e
REGION="us-east-1"
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
# 1. Custom bus
aws events create-event-bus --name order-processing-bus
# 2. Rule with event pattern
aws events put-rule \
--name high-value-order-rule \
--event-bus-name order-processing-bus \
--event-pattern file://order-created-pattern.json \
--state ENABLED
# 3. Lambda permission + target
aws lambda add-permission \
--function-name ProcessHighValueOrder \
--statement-id AllowEventBridgeInvoke \
--action lambda:InvokeFunction \
--principal events.amazonaws.com \
--source-arn arn:aws:events:$REGION:$ACCOUNT_ID:rule/order-processing-bus/high-value-order-rule
# 4. DLQ
aws sqs create-queue --queue-name eventbridge-dlq
# 5. Targets: Lambda + Step Functions with retry policy and DLQ
DLQ_ARN=$(aws sqs get-queue-attributes \
--queue-url https://sqs.$REGION.amazonaws.com/$ACCOUNT_ID/eventbridge-dlq \
--attribute-names QueueArn --query "Attributes.QueueArn" --output text)
aws events put-targets \
--rule high-value-order-rule \
--event-bus-name order-processing-bus \
--targets \
"Id"="1","Arn"="arn:aws:lambda:$REGION:$ACCOUNT_ID:function:ProcessHighValueOrder","DeadLetterConfig"="{\"Arn\":\"$DLQ_ARN\"}" \
"Id"="2","Arn"="arn:aws:states:$REGION:$ACCOUNT_ID:stateMachine:OrderFulfillmentWorkflow","RoleArn"="arn:aws:iam::$ACCOUNT_ID:role/EventBridgeToStepFunctionsRole"
# 6. Scheduled daily report
aws scheduler create-schedule \
--name daily-order-report \
--schedule-expression "cron(0 9 * * ? *)" \
--flexible-time-window "Mode=OFF" \
--target "{\"Arn\":\"arn:aws:states:$REGION:$ACCOUNT_ID:stateMachine:GenerateDailyReport\",\"RoleArn\":\"arn:aws:iam::$ACCOUNT_ID:role/EventBridgeSchedulerRole\"}"
# 7. Archive for replay
aws events create-archive \
--archive-name order-events-archive \
--event-source-arn arn:aws:events:$REGION:$ACCOUNT_ID:event-bus/order-processing-bus \
--retention-days 30
echo "Order processing pipeline deployed on bus: order-processing-bus"Run bash deploy-eventbridge-pipeline.sh and, assuming your Lambda function and Step Functions state machine already exist, you have a complete, production-shaped event-driven pipeline: content-based routing, dual targets, retry handling, a dead-letter safety net, a scheduled report, and 30 days of replay capability.
Expected Output
After running the test event from Step 4, you should see output similar to this in your Lambda’s CloudWatch log group:
START RequestId: 8f2a1c3e-...
Event received: {
"orderValue": 250,
"status": "pending",
"orderId": "ord_9981"
}
Order ord_9981 flagged as high-value, routing to fraud check
END RequestId: 8f2a1c3e-...
REPORT RequestId: 8f2a1c3e-... Duration: 42.18 ms Billed Duration: 43 msAnd in the EventBridge console under Rules → high-value-order-rule → Monitoring, the Invocations metric should show a matching count against TriggeredRules, with FailedInvocations staying at zero if everything is wired correctly.
Frequently Asked Questions
What is the difference between EventBridge rules and EventBridge Pipes?
Rules match events on a bus and fan out to up to five targets in parallel, ideal for content-based routing to multiple downstream consumers. Pipes builds a single filtered, enriched connection from one source (typically SQS, Kinesis, or DynamoDB Streams) to one target, without you writing custom glue Lambda code.
How much does Amazon EventBridge cost for a typical small application?
Custom events cost $1.00 per million ingested, rule evaluation is free, and AWS service events landing on the default bus never cost anything. A small application publishing a few hundred thousand custom events per month will typically land well under $1 for the core bus, though Pipes and Scheduler are billed separately if you use them.
Can I use EventBridge for cross-region event routing, not just cross-account?
Yes, a rule’s target can be an event bus ARN in a different region, and the same cross-account/cross-region delivery pricing of $1.00 per million events applies once the event leaves the source account and region.
Why does my event pattern match nothing even though the JSON looks correct?
The most common cause is a field name mismatch — the API field is detail-type with a hyphen, not detailType. The second most common cause is a comparison operator not wrapped in an array, such as writing {"numeric": ">100"} instead of the required {"numeric": [">", 100]}.
Do I need EventBridge Scheduler if I already use cron expressions on a rule?
Rule-based cron scheduling still works and is fine for a handful of simple recurring jobs. Scheduler is built for managing large volumes of schedules (AWS describes it as handling millions), supports one-time at() invocations natively, and is billed and quota-managed independently, which makes it the better choice for anything beyond a few basic jobs.
What happens to events that fail delivery to all targets?
EventBridge retries automatically for up to 24 hours by default. If you configured a dead-letter queue on the target, the event lands there after retries are exhausted; without one, the event is dropped and only visible retroactively through CloudWatch metrics.
Is EventBridge AI Workflow Studio required to use EventBridge?
No. AI Workflow Studio, released in August 2026, is an optional visual layer that sits on top of the same rules, targets, and event buses covered in this tutorial. Every workflow it builds maps back to standard EventBridge rules and targets that you could also create through the CLI.
Can a single event bus have rules pointing to targets in multiple AWS accounts and regions?
Yes. A rule can have up to five targets, and any of those targets can be an ARN in a different account or region, provided the destination has granted permission via put-permission and any necessary IAM roles are correctly scoped.
