AWS has introduced an enhanced Custom Event Bus for Amazon EventBridge, targeting a problem that often emerges when event-driven architectures move beyond a single team or AWS account: the event infrastructure itself becomes fragmented. The new model allows organisations to create a single event bus shared across multiple AWS accounts, while adding native event ordering, retention and replay, content-based deduplication, simplified subscriptions and a new pricing model.
The change addresses an architectural tension in enterprise AWS environments. Organisations commonly use multiple accounts to provide isolation between teams and applications, but this can lead to EventBridge buses being connected through cross-account rules and forwarding configurations. As the number of consumers grows, the resulting topology becomes harder to govern and understand, while forwarding the same event through multiple buses can introduce additional processing and routing costs. AWS's new model instead positions a central bus as an organisational event backbone, with individual teams managing their own subscriptions.
The enhanced Custom Event Bus can be shared across AWS accounts using AWS Resource Access Manager (RAM). A platform team can therefore establish a central event bus while allowing application teams to publish and subscribe from their own accounts. AWS says the new bus supports up to 10,000 subscribers by default, with the option to request a higher quota.
This changes the governance model as much as the technical one. Rather than a platform team configuring every cross-account connection, it can establish the boundaries around the central bus while individual application teams manage their own subscriptions, filtering, targets, retries, and failure destinations. That creates a separation between platform-level governance and application-level event consumption, potentially reducing the amount of infrastructure work required to onboard another consumer.
AWS also introduces synchronous invocation for targets such as AWS Lambda. This can remove a pattern where teams place Amazon SQS between EventBridge and Lambda primarily to provide stronger processing acknowledgement. The result is a bus that can support both conventional asynchronous event consumption and workloads where ordering and processing confirmation are important.
The new Subscriber resource is another important change to the EventBridge model. Previously, consumers were typically represented through combinations of rules, targets, and retry configurations. The Subscriber resource brings filtering, target configuration, retries, and dead-letter destinations together into a single consumer definition. It also supports variable start times, which can be used when onboarding a new consumer or replaying historical events.
The bus itself also becomes more useful as a durable event backbone. Events can be retained for a configurable period of between one and 365 days, allowing consumers to start from an earlier point in the event history or recover after application failures. AWS also supports JSONata transformations and can deserialize Avro and Protocol Buffers payloads into JSON for filtering and routing.
The enhanced bus adds content-based deduplication, allowing EventBridge to identify retries of the same event based on its payload. AWS says matching events received within a five-minute window can be collapsed, providing exactly-once semantics for that specific deduplication scenario. This does not remove the need for application-level idempotency, particularly where events are replayed or processed across regions.
AWS has also changed the pricing model. Rather than allowing costs to compound with every cross-account and bus-to-bus forwarding hop, the enhanced bus uses an ingress and egress throughput model, with publishers paying for events ingested and subscribers paying for events delivered. This more closely aligns cost with the amount of event data entering and being consumed from the central bus rather than the number of intermediate routing steps in the architecture.
The enhanced EventBridge model moves into territory traditionally associated with enterprise event brokers and streaming platforms such as Apache Kafka, but the two technologies still address somewhat different architectural needs. Kafka is fundamentally a distributed event-streaming platform built around durable logs, partitions, and consumer groups, giving engineering teams extensive control over high-throughput streaming workloads and consumption semantics. EventBridge remains a managed, serverless event-routing service, with AWS handling the underlying infrastructure while providing filtering, routing, retention, transformations, and integration with AWS targets. The new capabilities therefore make EventBridge more capable as an enterprise event backbone, but they do not turn it into a direct replacement for Kafka in every streaming architecture.
Importantly, AWS is not replacing the existing EventBridge model immediately. Existing custom buses continue operating unchanged and are now labelled Custom event bus-classic, while the enhanced bus is introduced as a separate resource. Organisations can therefore adopt the new architecture incrementally rather than having to redesign existing event-driven applications as part of the launch.
The enhanced Custom Event Bus is initially available across selected AWS Regions in North America, Europe and Asia Pacific, and can be created through the AWS Management Console, CLI or EventBridge APIs.