EventBridge Enhanced Custom Event Bus Architecture Diagram: Org-Wide Ordered Events

On September 24, 2026, AWS announced an enhanced custom event bus in Amazon EventBridge — a purpose-built backbone for organizations that outgrew a single-account bus and then discovered that stitching many buses with cross-account rules or bus-to-bus routing recreates the operational complexity serverless was meant to remove. This EventBridge enhanced custom event bus architecture diagram walks the new shape: one shared bus across an AWS Organization via AWS RAM, publishers that do not need to know consumers, a Subscriber resource that collapses filter/target/retry/DLQ into one unit, EventGroupId ordered delivery for opt-in subscribers, content-based deduplication, and an ingress/egress pricing model. Facts below follow the AWS News Blog launch post; classic buses remain as “Custom event bus – classic” and coexist.

Classic pain: many buses, cross-account rules, compounding cost

Teams usually start with one custom event bus in one account. That works while a single team owns the architecture. AWS multi-account best practice then pushes each product team into its own account. To move events between them, teams create multiple buses linked through cross-account rules or bus-to-bus configurations. Platform teams lose a single view of who subscribes to what. Cross-account and bus-to-bus routing charges compound. Teams that need ordering bolt on SQS or another stack — or leave EventBridge entirely for a different technology. On an architecture review diagram, that mesh looks like many small buses with dashed permission edges between accounts; every edge is another failure mode and another billing line. The enhanced custom event bus exists to replace that mesh with one organization-wide backbone — not to delete classic buses overnight.

One shared bus via AWS RAM

Create a Custom event bus (the console labels the new option “New”; classic remains available). The create page highlights ordered delivery, filter patterns, event replay, and sharing across your AWS organization as the enhanced path. Enable event bus sharing and scope it — for example, allow sharing only within your organization — then share with an organization, OU, AWS account, or IAM role/user. Sharing uses AWS Resource Access Manager (AWS RAM), so you do not hand-roll cross-account permissions or bus-to-bus hops. Platform teams deploy one bus as the central event backbone. Application teams across the organization publish and subscribe on that same bus without waiting for another team’s infrastructure ticket. You can also create the bus via AWS CLI or EventBridge APIs when GitOps is the source of truth.

Default quota is about 10,000 Subscribers per bus (higher quotas can be requested). That reduces the fragmentation that used to force another bus when subscriber limits filled up.

Publishers, subscribers, and independent Subscriptions

On the diagram, left-side publisher accounts call PutEvents (and optionally stamp EventGroupId). Publishers send events without needing to know which teams consume them. Subscribers create their own Subscriptions independently. Platform teams keep visibility into event flows and fine-grained control over who can publish and consume. That is the architectural pivot: fan-in to one bus, fan-out through many Subscriber resources — not a mesh of privately owned buses.

EventGroupId ordering and sync Lambda targets

Most event-driven consumers should stay asynchronous — order does not matter. Some domains care: logistics driver-location updates must arrive in sequence so routing does not act on stale points. The enhanced bus supports both patterns on the same bus. Publishers include an EventGroupId when order matters. EventBridge delivers events that share that id in sequence to Subscribers that opted into ordered delivery. Other subscribers receive the same events without ordering.

Ordered processing includes synchronous invocation for targets like AWS Lambda: sync mode confirms successful processing before acknowledging the event, eliminating the common pattern of parking Amazon SQS between the bus and Lambda just to get reliable ordered handoff.

The Subscriber resource: filter, target, retry, DLQ

Classic EventBridge spreads the same outcome across separate rules, targets, and retry settings. The enhanced bus introduces the Subscriber resource: one manageable unit that combines event filtering, target configuration, retry policies, and dead-letter destinations. Draw it as a single box with four internal lanes — that matches how operators will reason about ownership. Subscribers also include variable start-time options so teams can onboard new consumers, replay events after application errors, or hydrate new applications without reinventing retention tooling.

Content-based deduplication, JSONata, and Avro/Protobuf

Publishers can enable content-based deduplication: EventBridge hashes meaningful parts of the payload and collapses matching retries that arrive within five minutes, giving those retries exactly-once delivery semantics instead of the usual at-least-once model. You do not have to invent a deduplication ID when a timeout or partial failure resends the same event. If you already stamp your own idempotency token, keep using it — content-based dedupe is for sources that cannot reliably identify the same event on retry.

Subscribers can use JSONata expressions to reshape an event before it reaches a target (extract, rename, or compute fields). If you produce Apache Avro or Protocol Buffers events, EventBridge can deserialize those payloads to JSON so subscribers filter and route on the full payload without each consumer deserializing and discarding locally.

Ingress/egress pricing vs classic compounding

The enhanced custom event bus uses an ingress and egress throughput pricing model: publishers pay for events ingested; subscribers pay for events delivered. That replaces the classic per-event model where cross-account and bus-to-bus routing charges compound in multi-bus architectures — and it gives cleaner cost allocation between producers and consumers. See the EventBridge pricing page for current rates; this post stays architectural.

When to migrate — and when to stay classic

Existing custom event buses continue unchanged and appear as Custom event bus – classic. Enhanced is a new resource you adopt at your own pace — dual-run is an explicit design choice, not an accident. Migrate when you want one org-wide backbone, RAM sharing instead of bus-to-bus, Subscriber-centric ownership, EventGroupId ordering with sync Lambda, content-based dedupe, or clearer ingress/egress economics. Stay classic for workloads that are stable, single-account, or not ready to re-model rules as Subscribers. A pragmatic cutover pattern: stand up the enhanced bus, share it via RAM, move new domains first, then migrate high-churn classic rules once Subscriber ownership maps cleanly to team boundaries. Regions at launch (per AWS News Blog): US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain), and Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo).

FAQ

What is an EventBridge enhanced custom event bus?

A new EventBridge resource (Sep 24, 2026) for enterprise-scale event-driven apps: one centralized bus shared across an AWS Organization via AWS RAM, with EventGroupId ordering, a Subscriber resource (filter/target/retry/DLQ), content-based deduplication, and ingress/egress pricing. Classic buses remain as Custom event bus – classic.

How does EventGroupId ordered delivery work?

Publishers include an EventGroupId; EventBridge delivers same-id events in sequence to Subscribers that chose ordered delivery. Other subscribers on that bus can stay unordered and async. Ordered paths support synchronous Lambda invocation so you skip the SQS-between-bus-and-Lambda workaround.

How does enhanced EventBridge pricing differ from classic buses?

Publishers pay ingress (events ingested); subscribers pay egress (events delivered). That replaces classic per-event compounding across cross-account and bus-to-bus hops. Check the EventBridge pricing page for rates.

Conclusion

Draw the backbone story: publisher accounts → one RAM-shared enhanced custom event bus → independent Subscriber resources, with a dashed EventGroupId ordered path beside unordered async, a small classic multi-bus mesh as the “before,” and ingress/egress labels on the edges. Cite the AWS News Blog for launch scope and regions, and keep classic buses on the diagram as a coexisting resource — not a deprecated footnote. Browse more architecture diagrams on the ByteDiagram blog.