How Does EventBridge Pricing Work?

A dollar per million events sounds like the kind of number you never have to think about again, and for a single event bus with a handful of rules, it usually is. Then a team wires up Pipes to skip a Lambda hop, adds a Scheduler job that fires every minute instead of every hour, or starts forwarding events to an account nobody remembers approving cross-account access for, and EventBridge stops being the free-feeling glue between services and starts being a line item with its own explanation.

Why does EventBridge have so many separate prices?

EventBridge isn't one meter behind one console tab. It's the entry point to a handful of related services — event buses, Pipes, Scheduler, Archive, Schema Registry — and each one bills independently, at a different rate, for a different unit of work:

Two rules cut across most of that table. Same-account delivery is free — publishing an event and having a rule route it to a target in the same account costs nothing beyond the initial publish. And payloads are metered in fixed-size chunks, so a message larger than the chunk size is billed as more than one unit even though your code sent it as one event.

Why is my bill bigger than "a dollar a million" suggests?

Three mechanics turn a small, predictable-looking event volume into a larger, less predictable bill.

Payload chunking. Every 64KB chunk of an event's payload counts as one billable event on a custom event bus, and the same chunking applies to EventBridge Pipes requests. A 200KB payload — a full order object with line items, or a Step Functions execution result forwarded as an event — is billed as four events, not one, on every publish. If your producers serialize whole database rows or nested JSON blobs into event detail fields instead of a reference ID, the chunking multiplier is doing more work than the headline per-million rate suggests.

Cross-account delivery. Same-account delivery is free, but the moment a rule forwards an event to a bus in a different AWS account — a common pattern for a central security or logging account, or a multi-tenant setup where each customer gets their own account — that delivery is billed again, separately from the publish that triggered it. A single event published once and fanned out to five cross-account rules is billed for the publish plus five more chargeable deliveries.

Pipes and Scheduler are separate meters, not free extensions of the bus. Pipes charges $0.40 per million requests that make it past the filter step, on top of whatever the source and target already cost. Scheduler gives 14 million invocations a month free, then bills $1.00 per million after that — a schedule that fires every minute (43,800 times a month) looks trivial, but a few dozen of those per account, each running "just in case" long after the workload it watched is gone, adds up the free tier away.

How do I find what's actually driving the number?

Start in Cost Explorer, filtered to EventBridge and grouped by Usage Type — that split separates event-bus charges from Pipes, Scheduler, and API destination charges, which are easy to miss if you're only looking at the top-line EventBridge total.

To see publish and delivery volume per bus without waiting for the bill to close:

aws cloudwatch get-metric-statistics \
  --namespace AWS/Events \
  --metric-name Invocations \
  --dimensions Name=EventBusName,Value=order-events \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 \
  --statistics Sum \
  --region us-east-1 \
  --output table

Run the same call with FailedInvocations and DeadLetterInvocations to catch a target that's failing repeatedly — a failed invocation is still billed, and depending on the target's retry policy, EventBridge will keep retrying and billing for it until the retry window or attempt limit is reached.

To see every rule and scheduled expression racking up invocations, list rules by bus and check how often each one actually fires:

aws scheduler list-schedules \
  --query 'Schedules[].[Name,ScheduleExpression,State]' \
  --output table

A schedule expression of rate(1 minute) sitting in ENABLED state next to a DISABLED one it was supposed to replace is the single most common Scheduler cost surprise — nobody deletes the old one, so both run.

How do I bring the bill down without breaking event flow?

Reference large payloads instead of embedding them. Publish an event carrying an S3 object key or a database ID, and have the target fetch the full record itself. This is the direct fix for chunking overage, and it usually also makes the event schema more stable, since the target isn't tightly coupled to the producer's full data shape.

Minimize cross-account fan-out to what's actually needed. If three of five cross-account targets are audit copies nobody has queried in months, that's three chargeable deliveries per event for logs sitting unread. Route genuinely shared audit data through S3 or a centralized log destination instead of an EventBridge rule per consumer account.

Consolidate overlapping Scheduler jobs. A job that polls every minute to check a condition that changes a few times a day is paying per-minute pricing for hourly (or daily) information. Widening the interval from rate(1 minute) to rate(15 minutes) cuts that schedule's invocation count by 93% with no change to what it actually accomplishes.

Use content filtering on rules instead of filtering in the target. A rule's event pattern is evaluated for free as part of routing — sending every event to a Lambda function and having the function decide whether to act pays for invocations the rule pattern could have filtered out before they ever left the bus.

Set a short archive retention window, or skip Archive for buses you don't replay. Archive bills processing and storage independently of the bus itself, and an archive with no retention limit keeps every event's payload indefinitely at $0.023/GB-month — cheap per event, not cheap after a year of high-volume traffic.

What else should I check while I'm in here?

EventBridge rarely runs alone — it's usually the routing layer between other services that meter the same way. If a rule delivers into an SQS queue for a consumer to process asynchronously, the delivery itself may be free, but the message still runs through SQS's own per-request meter once it lands — see why SQS costs more than you budgeted for what that second meter looks like once a bus fans out to several queues.

The same stacking shows up with notifications: a Scheduler job or an EventBridge rule that publishes to an SNS topic to alert a team pays SNS's own publish-and-delivery charge on top of whatever triggered the event in the first place, and a topic with several subscribers multiplies that second charge per subscriber. See what SNS actually costs to send for how that fan-out adds up.

More broadly, a per-request event router that sits quietly behind a dozen other services is exactly the shape a lot of an AWS bill takes once you look past compute and storage — the rest of what an AWS account bills for without anyone noticing works through where else that pattern shows up, service by service.

How do I catch this before it becomes a real number?

EventBridge spend rarely spikes on its own — it climbs when a new cross-account integration ships, when a Scheduler job's interval gets tightened to debug something and never gets widened back, or when a producer starts embedding a larger payload after a schema change nobody flagged as a cost decision. None of that looks like an incident at the time.

Connect your AWS account read-only, and Parsivex's daily anomaly checks compare every service's spend — EventBridge included — against its own trailing baseline, so a genuine jump surfaces the next morning instead of buried in a monthly total. For how those daily checks and severity thresholds work, see cost anomaly alerts, or read how scans work for what a connected account scan reads across the rest of your bill.