AWS EventBridge replaces multi-account buses with a single shared bus
On September 24, 2026, AWS announced an enhanced custom event bus in Amazon EventBridge: one centralized bus shared across every account in an AWS organization, with ordering guarantees, a Subscriber resource, and a new ingress/egress pricing model. For a multi-account platform still juggling cross-account rules, the workaround is officially over.
September 24, 2026. AWS announced an enhanced custom event bus in Amazon EventBridge, available the same day in 14 regions. September 24, 2026. The new bus ships with a default quota of 10,000 Subscribers per bus, expandable on request. For years, AWS best practice has pushed a multi-account structure in which every team lives in its own account. Why it matters: for the first time, an organization can run a single event bus shared across all of its accounts, with no cross-account rules and no bus-to-bus routing.
The multi-bus workaround everyone inherits
An organization adopting EventBridge almost always starts with a single custom event bus in one account. As long as one team owns the architecture, it works. Once adoption spreads, the recommended account-per-team structure turns eventing into a puzzle.
Routing an event between two accounts means creating multiple buses wired together through cross-account rules or bus-to-bus configurations. That workaround reintroduces exactly the operational complexity serverless was supposed to remove. Platform teams lose sight of who subscribes to what, cross-account and bus-to-bus routing charges pile up, and teams that need event ordering are forced to build elaborate workarounds or switch technologies entirely.
One shared bus via AWS RAM
The enhanced custom event bus changes the model. It is a centralized bus shared across all accounts in an AWS organization through AWS Resource Access Manager (RAM). A platform team deploys one bus, makes it the central event backbone, and eliminates the need to configure cross-account permissions or bus-to-bus routing.
Application teams publish and subscribe on the same bus without waiting for infrastructure provisioning. Publishers send events without knowing which teams consume them, and subscribers create their own Subscriptions independently. The platform team keeps visibility into every flow and fine-grained control over who can publish and consume.
The default quota of 10,000 Subscribers per bus — expandable on request — reduces the fragmentation that occurs when subscriber limits force a split across multiple buses.
Ordering, without the queue in the middle
The enhanced bus also solves the event ordering problem that pushed many teams to wedge Amazon SQS between the bus and Lambda for reliable processing. The mechanism relies on an EventGroupId: a publisher includes it in its events, and EventBridge delivers events that share the same identifier in sequence to subscribers that opted into ordering.
One bus supports both modes at once. Events for a given flow stay in the correct order for the consumers that need it, while other subscribers receive the same events with no ordering constraint. To make delivery reliable, the bus adds synchronous invocation for Lambda targets: synchronous mode confirms successful processing before acknowledging the event, eliminating the classic intermediate SQS queue pattern.
The Subscriber: one resource instead of three
The enhanced bus introduces a Subscriber resource that combines event filtering, target configuration, retry policies, and dead-letter queues into a single manageable unit. Today, reaching the same outcome with EventBridge means configuring separate rules, targets, and retry settings scattered across several resources.
The Subscriber collapses that model: each consumer defines, in one resource, which events it wants, where to deliver them, and how to handle failures. For a platform team, that means fewer resources to audit and a failure policy that is finally legible.
A pricing model that changes the math
The enhanced bus adopts an ingress/egress throughput pricing model. Publishers pay for events ingested, and subscribers pay for events delivered. This replaces the per-event model in which cross-account and bus-to-bus routing charges compounded across multi-bus architectures.
It is also a cost-allocation story: on a shared bus, knowing who pays for what becomes structural rather than the result of hand-tallying routing rules.
What does not change
Existing custom event buses keep working exactly as they do today, with no migration required. They now appear in the console as Custom event bus – classic. The enhanced custom event bus is a new resource to adopt at each organization’s own pace: it simply appears as Custom event bus.
Availability spans US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain), and Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo). The bus is created through the AWS console, the AWS CLI, or the EventBridge API.
Classic versus enhanced, side by side
| Criteria | Custom event bus – classic | Enhanced custom event bus |
|---|---|---|
| Scope | One account, cross-account rules beyond it | Whole organization, via AWS RAM |
| Ordering | Not natively guaranteed | EventGroupId + synchronous invocation |
| Consumer | Separate rules, targets, and retry | A single Subscriber |
| Pricing | Per-event, compounding routing fees | Ingress (publishers) / egress (subscribers) |
| Quota | Limited per account | 10,000 Subscribers per bus |
The table captures a simple trade-off. The classic bus remains the tool for a single account; the enhanced bus becomes the backbone of an organization. Neither cancels the other: they coexist in the console, and nothing forces you to migrate what exists.
Migrating without breaking anything
Moving to the enhanced bus happens through progressive adoption, not a big bang. The platform team first creates the shared bus, shares it via AWS RAM with the organization, then wires new flows into it. The old classic buses keep running while teams convert their rules into Subscriptions.
The watch item is pricing. Moving from a per-event model to an ingress/egress model changes how you budget: the platform team must allocate costs between publishers and subscribers, which the new model happens to make far more legible. It is a governance project as much as an architectural one.
Verdict
If you run a multi-account AWS organization with several buses wired through cross-account rules, move new flows to the enhanced bus: you drop bus-to-bus routing and its compounding charges, and you regain central visibility into who consumes what. If you are single-account and single-team, the classic bus remains perfectly adequate — do not migrate for the sake of migrating. If ordering is your pain point, the EventGroupId and synchronous invocation pair is a cleaner replacement for an intermediate SQS queue, provided your consumers can accept synchronous mode. The enhanced bus is not a cosmetic change: it is AWS’s answer to years of multi-bus workarounds, and the sign that enterprise eventing now has an official path.