Amazon EventBridge gets a single bus for multiple accounts, but it's not yet available in Brazil

AWS announced, on the AWS News Blog, an enhanced version of Amazon EventBridge's custom event bus, designed specifically for the moment when an event-driven architecture outgrows a single team. The announcement starts from a diagnosis that any architect who has scaled EventBridge beyond one squad recognizes right away: the service was built to work perfectly for one team, one account, one bus. When the organization grows and adopts the practice, recommended by AWS itself, of isolating each team in its own account, the solution turns into a tangle of cross-account rules and bus-to-bus configurations that reintroduce exactly the operational complexity that serverless architecture was supposed to eliminate.

The problem the announcement addresses

AWS's description is direct: in multi-account scenarios, each team ends up standing up its own bus and connecting them via cross-account rules or bus-to-bus routing. The side effect isn't just infrastructure bureaucracy. The platform team loses visibility into who is subscribing to what, cross-account and bus-to-bus routing costs pile up fast, and any need for event ordering forces the team to build workarounds or switch technology. It's the kind of technical debt that only shows up after the architecture is already in production and several squads depend on it, which makes migration expensive and risky.

How the enhanced custom event bus works

The proposal is a single bus shared across all accounts in an AWS Organization, with sharing handled via AWS Resource Access Manager (RAM). In the console, when creating a bus, there are now two options: "Custom event bus" (the new, recommended version) and "Custom event bus – classic," which keeps the current behavior based on rules and targets. When sharing is enabled, access can be granted by specific account, by the entire organization, by organizational unit, or by IAM role/user, without the platform team needing to manually configure cross-account permissions or bus-to-bus routing.

In practice, this flips the mental model: instead of each team spinning up its own bus and relying on point-to-point integration, publishers send events without knowing who will consume them, and each subscriber creates its own subscription independently. The platform team retains central visibility and fine-grained control over who publishes and who consumes. The new bus ships with a default quota of 10,000 Subscribers, adjustable on request, which avoids the fragmentation that today forces splitting the load across multiple buses just because of a subscriber limit.

Ordering without reinventing the wheel

The most technical point of the announcement is guaranteed ordering, something classic EventBridge never offered natively. Most event-driven systems were designed assuming order doesn't matter, but there are relevant exceptions: AWS itself cites, as an example, a logistics application where a driver's location updates need to arrive in sequence, because out-of-order events lead the routing algorithm to decide based on stale data.

The enhanced bus solves this with an EventGroupId field that the publisher includes in the event. Events with the same EventGroupId are delivered in sequence to subscribers that opted for ordered delivery, while other subscribers on the same bus keep receiving the same events asynchronously, with no guaranteed order. It's an interesting design detail: ordering stops being a property of the entire bus and becomes a property of the subscription, which avoids forcing everyone to pay the coordination cost that only part of the system actually needs.

To support this model, the bus now supports synchronous invocation of targets such as AWS Lambda, confirming successful processing before acknowledging the event. This eliminates the common pattern of placing an Amazon SQS queue between the event bus and Lambda just to guarantee reliability, a workaround that any team that has run EventBridge in production has probably already hand-built.

One resource instead of three

The second structural change is the new Subscriber resource, which consolidates event filtering, target configuration, retry policy, and dead-letter destination into a single manageable object. Today, achieving the same result in classic EventBridge requires configuring rules, targets, and retry policies as separate resources scattered across the account. Each consuming team now has a single resource that describes what it wants to receive, where to deliver it, and how to handle failure, including variable start-time options that make it easier both to onboard a new consumer and to replay events to recover from an application error or to populate a new system.

AWS also added content-based deduplication: the publisher turns the option on and EventBridge starts hashing the relevant parts of the event, discarding retries that arrive within a five-minute window, without the team needing to generate and track an idempotency ID manually. Anyone who already stamps their own idempotency token doesn't need to change anything, this option is aimed at sources that can't reliably guarantee identification of the same event on a retry.

Another practical addition: subscribers can now use JSONata expressions to reformat an event before delivering it, extracting or renaming fields and computing values when the target API expects a different format. And anyone who already produces events in Apache Avro or Protocol Buffers gets automatic deserialization to JSON, allowing fine-grained filtering and routing over the full payload without the subscriber having to consume, deserialize, and discard it on its own.

The pricing model changes the math

The enhanced bus swaps the per-event model for an ingress and egress throughput model: publishers pay for the volume ingested, subscribers pay for the volume delivered. This replaces the per-event charge that, in multi-bus architectures, multiplied with every cross-account or bus-to-bus hop. For whoever designs the architecture, the practical effect is that scaling cost stops growing with the number of routing hops and becomes a direct function of volume published and volume consumed, which makes it easier to attribute cost by publishing team and by consuming team, something that today requires a manual spreadsheet in any organization with more than two or three buses. The pricing details are on the EventBridge pricing page, which AWS did not disclose in the post itself.

What changes for those building in Brazil

Here's the point any team in Brazil needs to note before celebrating: the enhanced custom event bus is available, for now, in US East (Northern Virginia and Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain), and Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo). The São Paulo region isn't on the list. Anyone running their main workload in sa-east-1 for latency or data-residency reasons will stay on the classic bus until AWS expands availability, or will need to weigh whether it's worth centralizing the bus in a region outside Brazil and paying the extra cross-region routing latency just to gain ordering and a unified Subscriber.

This changes the adoption calculus: it's not a purely architectural decision, it's a decision conditioned by infrastructure geography. Teams that already have part of their stack in us-east-1 or eu-west-1 for other reasons (compliance, partner integration, service availability) have a clear path to pilot the enhanced bus. Those that are 100% in São Paulo due to regulatory requirements or latency will have to wait, and that wait has no date announced by AWS in the post.

When migrating is worth it, and when it isn't

The enhanced bus solves a real problem for large organizations: visibility into who consumes what, cross-account routing costs that pile up, and the lack of native ordering. If your architecture already has multiple buses connected by cross-account rules just to simulate a single backbone, or if some consumer depends on order and that's currently solved with an intermediate queue plus sequencing logic in the application, the new model is worth the migration.

If your EventBridge is still a single bus for a single team, with no need for ordering, the change brings no immediate benefit: the classic bus keeps working with no alteration whatsoever, and AWS made clear that adopting the enhanced bus is optional and at each organization's own pace. It's also worth considering the new ingress/egress pricing model before migrating very-high-volume workloads: it can be better or worse than the per-event model depending on the traffic pattern, and that can only be figured out by comparing the projected bill against the official pricing page, not against the announcement's generic promise of "economies of scale."