# Amazon EventBridge Introduces Enhanced Custom Event Bus for Scaling Event-Driven Architectures
### The Challenge of Event Management at Scale
Event-driven architectures have become the backbone of modern cloud applications. When organizations first adopt event-driven patterns, they typically start simple — a single event bus, a handful of services, one team in charge. This setup works beautifully in its early stages. However, as organizations grow and more teams begin building event-driven applications, the limitations of that simple approach become impossible to ignore.
Cross-account event routing, bus-to-bus configurations, fragmented visibility, compounding costs, and the lack of native ordering guarantees all start to erode the very benefits that made serverless event-driven design appealing in the first place. Platform teams find themselves drowning in infrastructure management while application teams wait on provisioning and configuration before they can ship new features.
A new offering from Amazon Web Services aims to address these pain points head-on.
—
### A Centralized Event Backbone Across Your Entire Organization
The latest evolution of EventBridge’s custom event bus is designed with one core principle in mind: let organizations deploy a single, centralized event bus that spans every AWS account within an organization. Rather than managing dozens of event buses across multiple accounts with complex cross-account permissions and bus-to-bus routing rules, teams can now share a single bus as the central event backbone.
This approach fundamentally changes how event infrastructure is managed. Platform teams define and own the bus once. Application teams across the organization then publish and subscribe to events independently, without waiting on infrastructure provisioning or dealing with cross-account networking. Publishers don’t need to know which teams consume their events, and subscribers can define their own consumption patterns on the same shared bus.
The new bus also introduces a generous default quota of 10,000 subscribers per bus, with the ability to request higher limits. This helps eliminate the fragmentation that previously forced teams to split event traffic across multiple buses, each with its own routing and cost overhead.
—
### Ordered Delivery Without Sacrificing Asynchronous Patterns
Event-driven architectures thrive on asynchronous design, where the sequence of events often doesn’t matter. But there are real-world scenarios where order is critical. In logistics platforms, for example, a driver’s location updates must arrive in the correct sequence. An out-of-order update can cause routing algorithms to operate on stale or incorrect data, leading to poor decisions.
The enhanced event bus handles both patterns simultaneously. Publishers can attach an `EventGroupId` to their events. Subscribers who opt into ordered delivery receive events grouped under the same `EventGroupId` in the correct sequence, while other subscribers on the same bus continue to receive events asynchronously. This means you can maintain strict ordering for time-sensitive data streams like location updates while keeping the rest of your consumer ecosystem fully decoupled and asynchronous.
To further support reliable ordered processing, the new bus includes native synchronous invocation for targets such as AWS Lambda. Instead of placing an intermediate queue like Amazon SQS between the event bus and Lambda to confirm delivery, synchronous mode ensures that the target has successfully processed the event before it is acknowledged. This simplifies the architecture and reduces the number of components teams need to manage.
—
### The Subscriber Resource: Simplifying Consumer Configuration
Managing event consumers used to require stitching together multiple resources — rules for filtering, targets for delivery, retry policies for handling failures, and dead-letter queues for unprocessable events. Each of these lived as a separate resource, making it difficult to understand the full picture of any given consumer at a glance.
The new enhanced event bus introduces the Subscriber resource, which consolidates all of these concerns into a single unit. A subscriber defines what events it wants to receive, where those events should be delivered, how many times to retry on failure, and where to send events that repeatedly fail. This unified model dramatically simplifies the management of event consumers and gives each team full control over their own subscription lifecycle.
Subscribers also include variable start time options, which are particularly useful when onboarding new consumers or replaying events after an application error. Teams can now recover from failures or hydrate new applications by replaying historical events directly from the bus, without needing complex external tooling or backup systems.
—
### Smarter Event Evaluation and Payload Handling
Two notable improvements in event evaluation round out the new capabilities. First, content-based deduplication allows publishers to let EventBridge automatically detect and drop duplicate events based on the payload itself. EventBridge hashes the meaningful portions of an event and collapses matches that arrive within a five-minute window, delivering exactly-once semantics for retries rather than the default at-least-once model. This is particularly valuable for event sources that cannot reliably generate their own deduplication identifiers. For publishers that already include their own idempotency tokens, those continue to work as before.
Second, subscribers can now use JSONata expressions to reshape incoming events before they reach their target. This means extracting specific fields, renaming them, or computing new values to match the expected input format of a downstream API — all within the event bus itself. Additionally, EventBridge can now deserialize payloads in formats like Apache Avro or Protocol Buffers directly to JSON, enabling subscribers to apply fine-grained filtering and routing on the complete event payload without needing to handle deserialization and matching on their own.
—
### A New Pricing Model Built for Scale
One of the most significant changes is the pricing model. The enhanced custom event bus moves away from a per-event charge toward an ingress and egress throughput model. Publishers are billed for the events they ingest into the bus, while subscribers are billed for the events delivered to them. This replaces the previous model where cross-account and bus-to-bus routing charges compounded rapidly in architectures with multiple buses and numerous inter-account connections.
The result is a more predictable cost structure that scales more favorably as organizations add teams, accounts, and event volume. The improved economics at scale make it financially viable to adopt a centralized bus strategy without worrying about runaway routing costs.
Existing custom event buses continue to function exactly as they do today. They are now labeled as “Custom event bus – classic” in the console, while the enhanced version appears simply as “Custom event bus.” Adoption is entirely optional and can be phased in at each organization’s own pace.
—
### Availability and Getting Started
The enhanced custom event bus is available today in several AWS Regions across North America, Europe, and Asia Pacific, including US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain), and Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo). Teams can create a new enhanced event bus through the AWS Management Console, the AWS CLI, or directly via EventBridge APIs.
—
### Frequently Asked Questions
**Q: Do I need to migrate my existing custom event buses to the enhanced version?**
A: No. Existing custom event buses continue to operate as they do today under the “Custom event bus – classic” label. The enhanced version is a new resource that you can adopt at your own pace.
**Q: Can I mix the classic and enhanced event buses in the same organization?**
A: Yes. Both versions coexist, allowing teams to migrate incrementally or keep legacy buses running while adopting the enhanced model for new workloads.
**Q: What happens if a subscriber fails to process an event?**
A: Subscribers support configurable retry policies and dead-letter destinations. Failed events are retried according to the defined policy, and events that continue to fail are routed to a designated dead-letter target for analysis or reprocessing.
**Q: How does event ordering work with the enhanced bus?**
A: Publishers include an `EventGroupId` with their events. Subscribers that opt into ordered delivery receive all events within the same group in sequence. Other subscribers on the same bus can receive the same events without ordering constraints.
**Q: Is content-based deduplication mandatory?**
A: No. It is an opt-in feature. If your event sources already include reliable deduplication identifiers, you can continue using your existing approach. Content-based deduplication is most useful for sources that cannot generate their own.
**Q: How does the new pricing model compare to the previous per-event model?**
A: The new model separates costs into ingress (publisher-side) and egress (subscriber-side) throughput charges. This tends to be more cost-effective at scale, especially in multi-account architectures where cross-account and bus-to-bus routing charges previously compounded quickly.
**Q: Can I use AWS RAM to manage access to the enhanced event bus?**
A: Yes. Resource sharing leverages AWS Resource Access Manager, which handles cross-account permissions automatically without requiring manual configuration of individual cross-account policies.
—
### Conclusion
The introduction of the enhanced custom event bus represents a meaningful step forward for organizations running event-driven architectures at scale. By consolidating event infrastructure into a single shared backbone, simplifying consumer management through the Subscriber resource, adding native ordering guarantees, and introducing a pricing model that rewards growth rather than penalizes complexity, this new offering removes many of the operational and financial barriers that have historically held back widespread adoption of event-driven patterns across large organizations.
Platform teams gain visibility and control. Application teams gain autonomy and speed. And the organization as a whole gains a scalable, cost-effective foundation for the event-driven applications of the future.
Thank you for reading
