EventBridge custom event bus: one bus for the whole org

The EventBridge custom event bus was re-launched on 24 September 2026 as a different product with the same name, and the change that will decide whether you adopt it is not ordering or deduplication — it is billing. AWS moved the enhanced custom event bus off per-event charging and onto ingress and egress throughput, so publishers pay for what they put in and subscribers pay for what they take out.

Everything else follows from one architectural decision: a single bus, shared across every account in your AWS Organization through Resource Access Manager, instead of a bus per team stitched together with cross-account rules and bus-to-bus routing. The classic bus is untouched and now appears in the console as Custom event bus – classic. The new one is a separate resource you adopt at your own pace, available as of September 2026 in fourteen Regions including Mumbai.

What is new, in one table

Capability	Custom event bus – classic	Enhanced custom event bus
Cross-account fan-out	Cross-account rules or bus-to-bus routing	One bus shared via AWS RAM
Consumers per bus	300 rules per bus by default	10,000 subscribers per bus by default
Ordering	No ordering guarantee	Per-EventGroupId ordered delivery
Duplicate retries	At-least-once delivery	Content-based deduplication over five minutes
Pricing	$1.00 per million custom events	$0.18 per GB ingress, $0.05 per GB egress

The quota line is the one that changes designs. A classic bus defaults to 300 rules, which is why large organisations end up splitting traffic across buses long before they want to. The enhanced bus defaults to 10,000 subscribers per bus, counting every account the bus is shared with, and the quota is adjustable.

The subscriber replaces a rule, a target, a retry policy and a DLQ

On a classic bus, one consumer is assembled from several resources: a rule with an event pattern, one or more targets, retry settings, a dead-letter queue. The enhanced bus collapses that into a single Subscriber resource that carries filtering, target configuration, retry policy and dead-letter destination together. Each consumer owns its own subscriber, in its own account, without asking the platform team to edit a shared rule.

Subscribers also take a variable start time, so a new consumer can begin from a past position on the bus rather than from now — replay to recover from an application bug, or to hydrate a service that did not exist last week. Retention is part of the bus rather than a second system: the first 24 hours are included in the price, and you can configure between 1 and 365 days, with anything beyond 24 hours charged at $0.08 per GB-month.

Retry behaviour is worth reading before you migrate a consumer. MaxRetryAttempts takes any value from 0 to 185 and defaults to 5, and MaxEventAgeInSeconds runs from 60 to 86,400 with a default of 300. Those defaults decide what lands in your dead-letter queue during a downstream outage, and the same reasoning applies here as to webhook retry patterns: the retry budget is a product decision, not a default to inherit.

EventGroupId gives you ordering without a second technology

Ordering is the capability that used to push teams off EventBridge entirely. Publishers can now include an EventGroupId in an event, and EventBridge delivers events sharing that value in sequence to subscribers that chose ordered delivery — while other subscribers on the same bus keep receiving them asynchronously. Driver location updates stay in order per driver; the analytics consumer reading the same stream does not pay for it.

The limit to design against is throughput per group. Ingestion per event group is capped at 1,500 per second, counted as the number of events plus their total size in kilobytes in any one-second window, and that limit is fixed. Bus-wide capacity is 500,000 events per second, also fixed. A coarse EventGroupId — one per tenant, say, rather than one per entity — hits the group ceiling long before the bus ceiling.

Ordered processing also brings synchronous invocation for targets such as Lambda, which confirms successful processing before the event is acknowledged. That removes the familiar pattern of putting an SQS queue between the bus and the function purely for reliability, which is one fewer resource per consumer in a serverless architecture.

What the new pricing actually costs

Events are rounded up to the nearest 1 KB of billable size, and the pricing page works a small example: one million 2 KB events delivered to two subscriptions is 2 GB of ingress and 4 GB of egress, so (2 x $0.18) + (4 x $0.05) = $0.56. The same million events on a classic bus cost $1.00 to ingest before any cross-bus delivery charge.

The larger worked example on the same page is more instructive, because it shows where the money goes at scale. For 1,000 events per second at 2 KB, two subscriptions, one JSONata transformation, deduplication on, seven-day retention and a 1% failure rate:

Dimension	Monthly cost
Ingress (5,184 GB)	$922
Egress to two subscribers	$518
Egress on retries	$16
Event evaluation	$778
Extended storage	$83
Total	$2,317

Event evaluation is a third of that bill. JSONata transformation, Avro and Protobuf deserialisation and content-based deduplication are each charged at $0.15 per million events evaluated, metered in 64 KB chunks, and charged only when configured. JSONPath extraction for target parameters is free. Turning deduplication on for every publisher because it sounds safer is a $778 decision in that example, so it belongs on the sources that genuinely cannot identify their own retries — if you already stamp an idempotency token, keep using it.

When consolidating onto one eventbridge custom event bus is the wrong move

Three cases argue against it. If your event volume is low and your consumers are few, per-event pricing at $1.00 per million is cheap and a classic bus with a dozen rules is less to learn. If your events are large, throughput pricing works against you: at 2 KB an event you pay $0.18 per GB across roughly 500,000 events, but the same GB is far fewer events once payloads grow. And if every consumer lives in one account, the sharing model — the main reason the enhanced bus exists — buys you nothing.

The migration is also not a switch. Existing buses keep working unchanged, so the realistic path is to stand up an enhanced bus for one domain, publish to both for a period, and move consumers across as subscribers. That is the pattern we use for AWS, GCP and Azure consulting work on live event backbones, because the cutover risk sits with the consumers, not the publisher.

Before any of that, do the arithmetic on your own numbers: average event size in KB, events per month, subscriber count, and which evaluation features you would switch on. Ingress plus egress plus evaluation is a different shape of bill from per-event, and for a fan-out-heavy architecture it is the egress multiplier — one charge per subscriber, per event — that decides whether consolidation saves money or simply moves it. If you are sizing that alongside the rest of your DevOps and cloud engineering spend, model the fan-out first.