One EventBridge Bus for Your Entire AWS Organization
EventBridge's new enhanced custom bus shares one bus org-wide via RAM and adds real ordering, a unified Subscriber resource, and ingress/egress pricing.
For years the recommended AWS multi-account setup came with a fine-print tax: event routing. Best practices say every team gets its own account, so every team got its own EventBridge bus, and pretty soon your architecture diagram had more bus-to-bus relationships than some of your services have API dependencies. Cross-account rules here, chained buses there, and a platform team whose visibility into event flow consisted of CloudTrail forensics and tribal knowledge. Ask anyone in that setup a simple question — "who actually consumes OrderPlaced?" — and watch them open six tabs.
AWS finally treated this as the product problem it is. Last week they announced the enhanced custom event bus for Amazon EventBridge: one bus, shared across every AWS account in your organization, with ordering guarantees, a single unified Subscriber resource, and a new pricing model that stops punishing you for doing multi-account the "right" way. Here's the tour, minus the marketing gloss.
What's actually new
Four things, and they compound:
- Organization-wide sharing. Create one bus and share it through AWS Resource Access Manager — no hand-wired cross-account permissions, no bus-to-bus relay hops. Publishers publish without knowing who consumes; subscribers subscribe on their own.
- Real event ordering. Publishers tag events with an
EventGroupId, and EventBridge delivers events sharing that ID in sequence — but only to Subscribers that opted into ordered delivery. Everyone else on the same bus stays happily asynchronous. Ordering also brings synchronous invocation for targets like Lambda, which confirms processing before acknowledging the event. That's the death of the queue-shim pattern where you wedge SQS between the bus and Lambda purely as a reliability crutch. - The Subscriber resource. Filtering, target configuration, retry policies, and dead-letter destinations — one resource instead of rules/targets/retry settings smeared across three. Subscribers also get variable start times, so a new consumer can replay history to hydrate itself, or recover from its own bugs without the publisher's help.
- Content-based deduplication. Flip it on at the publisher and EventBridge hashes the meaningful parts of the payload, collapsing retries that arrive within five minutes into exactly-once delivery instead of the usual at-least-once. There are niceties too: JSONata to reshape events per-subscriber, and Avro/Protobuf payloads get deserialized to JSON so filters can match on fields your producers never flattened themselves.
The default quota is 10,000 Subscribers per bus (raiseable), which should outlast most org charts.
Setup: three decisions in the console
The announcement walks through the console, and it's mercifully short:
- EventBridge console → Create custom event bus. Pick Custom event bus — the option labeled New. The older style now shows as Custom event bus – classic, and classic buses keep working unchanged, so nothing existing is held hostage.
- Turn on sharing. Enable event bus sharing and select Allow sharing only within your organization. The principal can be an AWS account ID, an organization, an organizational unit, or an IAM role or user. Behind the scenes it's AWS RAM doing the resource sharing — which is exactly why nobody has to hand-maintain cross-account trust policies anymore.
- Let teams self-serve. Each consuming team creates its own Subscription against the shared bus independently — no waiting on the platform team to provision rules for them. The platform team keeps fine-grained control over who can publish and consume.
The announcement is console-first, but the same resource is create-able via the EventBridge CLI and APIs — I'd codify it in infrastructure-as-code from day one. A bus every team shares is exactly the thing you don't want drifting between consoles.
Tips worth more than the setup guide
Order selectively, or pay for it.
EventGroupId is per-entity — the driver ID in the announcement's logistics example, or your order ID. Only subscribers that genuinely need sequence (routing decisions off stale position data are how you deliver to the previous address) should opt into ordered delivery. And read the fine print on synchronous invocation: an ordered subscriber processes one event to completion before the next moves. Make something ordered and you've made it a latency participant. Keep that set small.Exactly-once means within five minutes. Content-based dedup hashes the payload and collapses matches in a five-minute window — that's a retry-collapser, not a database constraint. If your producers can already stamp an idempotency token, the announcement itself says keep doing that; dedup is for sources that can't reliably recognize their own retries. Design consumers idempotent regardless, as always.
Replay is your recovery drill. The Subscriber's variable start time is quietly the most valuable feature in the list. New consumer onboarding, a replay to recover from a poison-message incident, hydrating a fresh environment from the bus's retention — without anyone re-publishing or resurrecting a backfill Lambda. If your current answer to "we lost a day of events" is a ticket to the publishing team, this changes your incident runbook.
Costs and the security-read
The pricing model follows the architecture: publishers pay for events ingested, subscribers pay for events delivered. That replaces the per-event model where cross-account and bus-to-bus routing charges compound — the tax that multi-bus setups quietly accumulated. It also makes chargeback honest: publish costs land on the producing team, delivery costs on the consuming team. (The announcement points to the EventBridge pricing page for the actual figures; there isn't a calculator in this post and I'm not going to invent one.)
Security lens, because a shared org-wide bus is a deliberate concentration of blast radius:
- Scope sharing as narrowly as the org allows. RAM principals can be as broad as your organization. If tenaciously scoping to specific accounts or an OU works, use it — one shared resource with every account attached is one misconfigured trust policy away from a very chatty backbone.
- Least-privilege both directions. Publish permissions should be per-producer, subscriptions per-consumer. The upside of the centralization: the platform team finally gets a complete, queryable map of who publishes and consumes what — governance as an architecture property instead of folklore.
- Payloads still aren't secrets vaults. Every authorized subscriber can read events you publish. The "don't put credentials or PII in event payloads" rule is older than EventBridge and now applies to a wider audience.
- It's regional. Availability at launch covers US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain), and Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo) — no cross-region bus story in this announcement, so multi-region architectures keep their per-region buses for now.
The short version
Classic custom event buses continue untouched, so there's no forced migration — this is an opt-in at your own pace. But if your org's event topology has accumulated more routing hops than your service calls, this announcement is the off-ramp: one bus, honest chargeback, ordering where it matters, and a Subscriber resource that reads like someone finally sat through your incident reviews. That's not a small release dressed as one. That's the event backbone the multi-account pattern always implied someone should have shipped.
Primary sources: AWS News Blog announcement (Sept 2026) — details, quotas, regions, and pricing model all from AWS's own post. Cover the pricing page for figures before you budget.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article