EventBridge's relaunched buses let other AWS accounts attach their own subscribers through RAM

Classic buses kept rules and targets in the bus's own account and region ^[2]. A central bus therefore left a platform team three options, according to a dev.to post walking through the relaunch: give every team access to the central account, have the platform team own every subscription, or forward events to buses in other accounts and lose the central view of what is connected ^[3]. The post's author wrote, "I've seen an organization develop its own serverless eventing platform to avoid these limitations in EventBridge." ^[16]

The new bus moves the subscription into the consuming account. The post describes the sequence ^[8]:

1. The owner shares the bus through AWS Resource Access Manager, with the whole organization or with specific accounts. 2. The consuming account accepts the invitation in the RAM console. 3. The bus appears in that account's bus list, where the account can add subscribers or publish events.

The owner's view of those subscribers stops at metadata ^[13]. It can see when a subscriber was last updated but not where that subscriber sends events. The owner can tell which accounts are attached, but cannot answer an audit question about where a given event lands.

In my view, an in-house layer still has a case in two places. The first is that inventory. If a compliance process needs a central record of every downstream target, the bus will not produce it, and the subscribing teams will have to report it.

The second is regions. The post describes the classic multi-region workaround as sending events between regional buses with no built-in deduplication and with filters written to avoid loops ^[4]. It describes content-based and ID-based deduplication on the new buses ^[9]. The post does not say whether a subscriber can attach from a region other than the bus's own. Until AWS documents that, a multi-region design should assume the loop problem is still the team's to solve.

Elsewhere the managed bus takes on jobs the classic bus left to consumers. Classic buses fixed the overall event format and did not provide ordering ^[5]. Ordering is now chosen per subscriber, so one shared bus can feed a FIFO consumer and an unordered one side by side ^[15]. The setting belongs there, because ordering is a requirement of the consumer and the bus serves many consumers. Delivery can be the raw payload, the payload with AWS metadata, or a version reshaped by a JSONata expression ^[11]. The post says that leaves room for a team's own format or for the CNCF-backed CloudEvents specification ^[11]. Retention is built in and runs from one day to one year ^[12].