AWS Daily Intelligence #40 - A hundred buses became five

Executive summary

Amazon EventBridge has relaunched its custom event bus. The announcement lists what you would expect: “24 hours of built-in retention that can be extended for up to one year”, a “new Subscriber resource… to filter events and deliver them to over 250 AWS services”, “native support for strictly ordered use cases” with “automatic content based deduplication”, and “a new pricing model that charges for data transferred rather than events.”

The quota page is more interesting than the announcement. The default number of buses an account may own is now 5. On Custom Event Bus - Classic it is 100.

That is not a tightening. It is the visible consequence of the bus no longer being the thing you decompose a system with — and the new ceilings say so: 10,000 subscribers per bus and 500,000 events per second per bus.

What changed

Under Classic, a bus is “a router that receives events and delivers them to zero or more destinations” using “rules and targets that the bus owner writes.” The bus owner holds the routing table. Wanting independent routing meant wanting another bus, and Classic supported 100 of them with 300 rules each.

The new model inverts ownership. AWS describes the Custom Event Bus as one that “routes events to subscribers that consumers create themselves and retains events for replay”, with the guidance that “for new applications, start with the Custom Event Bus.”

So the consumer owns its own filter and delivery, on somebody else's bus, shared through AWS Resource Access Manager. You need fewer buses because a bus is no longer how teams stay out of each other's way.

Nothing breaks. “All existing APIs remain unchanged” and the old bus is “renamed… to Custom event bus - classic”. This is an addition with a rename, not a migration.

Architecture

Diagram: how the EventBridge relaunch moves the unit of decomposition from the bus to the subscriber. On the left, Custom Event Bus Classic: the bus owner writes rules and targets, so routing is owned centrally. Its quotas allow up to 100 event buses per account per Region, 300 rules per bus in most Regions, and a fixed maximum of 5 targets per rule, with PutEvents throttled at 10,000 per second in North Virginia, Oregon and Ireland but only 400 per second in most other Regions. Teams that wanted independent routing asked for another bus, which is why the allowance was large. On the right, the new Custom Event Bus: consumers create their own subscriber resources, each filtering events and delivering to over 250 AWS services, so routing is owned by the consumer rather than the bus owner. Its quotas allow only 5 buses owned per account by default, though this is adjustable and buses shared with the account do not count, alongside 10,000 subscribers per bus counting every account the bus is shared with, and 500,000 events per second per bus, which is not adjustable. Retention is 24 hours by default and configurable from 1 to 365 days, retry attempts range from 0 to 185 with a default of 5, event age ranges from 60 to 86,400 seconds with a default of 300, and the deduplication window is fixed at 300 seconds. A central panel records the arithmetic: twenty times fewer buses and fifty times the per-second event ceiling, because the bus became a shared pipe rather than a boundary. A closing panel records the operational catch, that only one subscriber create or delete may be in progress on a bus at a time across every account it is shared with, with a second call failing with ConcurrentModificationException, and that filter changes are capped at 24 per subscriber in any rolling 24 hours. — The bus stopped being the boundary. The subscriber became it — and subscriber management is serialised across every account on the bus.

Read the two quota tables side by side and the design is unambiguous.

Classic optimises for many buses. 100 buses, “300” rules each, and “Targets per rule… 5” which is not adjustable. Throughput is per-Region and uneven: “us-east-1: 10,000 per second… Each of the other supported Regions: 400 per second.”

The new bus optimises for one big one. Five buses, but “Subscribers per bus the account owns, counting every account the bus is shared with: 10,000” and “Events per second per bus… 500,000” — the latter marked not adjustable, because it is the architecture rather than a safety valve.

Twenty times fewer buses; fifty times the per-second ceiling of the best Classic Region. A bus is now a pipe that everyone shares rather than a fence between teams.

Business value

The decoupling claim is real and it is about org charts, not throughput. Under Classic, adding a consumer meant a rule on somebody else's bus — a change request to the platform team, in their repository, on their deployment schedule.

A subscriber the consumer owns removes that queue. The producer publishes; the consumer decides what it wants and where it goes, across “over 250 AWS services”, without editing anything the producer owns.

Retention is the second real gain. “24 hours of built-in retention that can be extended for up to one year” — with RetentionPeriodInDays settable “1 to 365” — makes replay a property of the bus. Under Classic, replay meant an archive you configured and reasoned about separately.

And ordering with “automatic content based deduplication” removes the usual reason teams left EventBridge for a queue or a stream. “Events are processed in the exact order they were received” is a sentence Classic could never offer.

Security considerations

Sharing the bus through AWS RAM and letting consumers create their own subscribers moves a trust boundary. A subscriber is a filter plus a delivery target, authored by another account, reading from your bus.

The quota wording is explicit that the blast radius is cross-account: “Subscribers per bus the account owns, counting every account the bus is shared with”, and the same phrase attaches to the 500,000 events per second. Consumers you do not control draw down limits you are accountable for.

That makes event content the thing to govern. On Classic, a consumer had to ask for a rule, and the request was a review point. Here, anything published to the bus is available to every account it is shared with, subject only to the filters those accounts write for themselves.

Cost considerations

“A new pricing model that charges for data transferred rather than events.” That inverts the optimisation: under per-event pricing, a chatty stream of small events is expensive; under per-byte, event size is what costs, and a fat payload with fields nobody filters on is waste.

It also changes a common pattern's economics. Publishing a thin event and having consumers call back for detail was a way to keep events cheap. Under per-byte pricing that trade shifts — and the callbacks were never free.

Retention is storage, and the range is wide: 1 to 365 days. A year of replayable events on a high-throughput bus is a bill, and the default of 24 hours is the conservative starting point.

Operational considerations

Subscriber management is serialised across every account on the bus. This is the one to plan for: “Subscriber creates or deletes in progress on one bus… 1 across all accounts; a second call fails with ConcurrentModificationException.”

The model invites many teams onto one shared bus, then permits one subscriber mutation at a time across all of them. Two pipelines deploying at once, in different accounts, and one fails on a resource neither team owns. Any IaC that creates subscribers needs to retry this rather than treat it as an error.

Filter changes are rate-limited per subscriber. “24 in any rolling 24 hours”, not configurable. That is generous for deliberate changes and thin for a pipeline that reapplies a filter on every deploy to a busy service.

The deduplication window is fixed. “Deduplication window… Not configurable… 300 seconds.” Duplicates further apart than five minutes are not caught, so this replaces application-level idempotency only within that window.

Retry defaults are conservative relative to their ceilings. MaxRetryAttempts is “0 to 185, default 5” and MaxEventAgeInSeconds is “60 to 86,400, default 300”. Five attempts within five minutes is the out-of-the-box behaviour; a target with a longer outage needs both raised deliberately.

Watch the bus count before you need it. Five is adjustable, and the count “is also published as the ResourceCount metric in the AWS/Usage namespace, so you can alarm before you reach the limit.”

Tradeoffs

Team autonomy against shared-limit exposure. Consumers route themselves without asking, and they consume quotas counted against the bus owner.

Fewer boundaries against simpler topology. One bus with 10,000 subscribers is easier to reason about than fifty buses, until you want a hard separation — and then the bus is no longer where you get one.

Fourteen Regions. A real constraint for anyone already running Classic buses more widely; the old bus remains everywhere, the new one does not.

Implementation guidance

Make subscriber creation retry ConcurrentModificationException. With a shared bus this is expected behaviour, not an incident.

Do not reapply filters on every deploy. The 24-per-24-hours ceiling turns an idempotent pipeline habit into a throttle.

Decide retention deliberately, starting at the 24-hour default. The year is available and it is storage you pay for on every event.

Design event payloads for per-byte pricing. Publish what consumers filter and act on; the cost model now rewards that directly.

Leave Classic where it is. APIs are unchanged and there is a documented migration path when the time comes; nothing about this launch requires moving today.

Best practices

Treat the bus as a shared pipe with governed content. The review point has moved from "who may add a rule" to "what may be published".

Alarm on ResourceCount in AWS/Usage. Five is a small default to discover at deploy time.

Keep idempotency in the consumer. A fixed 300-second dedup window is a helpful narrowing, not a guarantee.

Who should adopt this

AWS's own guidance is unambiguous for greenfield: “For new applications, start with the Custom Event Bus.”

Adopt now if you are starting an event-driven system in one of the fourteen Regions, or if you left EventBridge for a queue because you needed ordering. Wait if you run Classic buses outside those Regions, if your topology depends on many buses as isolation boundaries, or if you cannot yet make your deployment tooling tolerate a serialised subscriber API.

Key takeaways

EventBridge relaunched the custom event bus; the old one is renamed Custom event bus - classic and its APIs are unchanged.
The default bus allowance fell from 100 to 5 — a twentyfold reduction, and adjustable.
In exchange: 10,000 subscribers per bus and 500,000 events/sec per bus, the latter not adjustable.
Classic tops out at 10,000 PutEvents/sec in its best Regions and 400/sec in most — so the new ceiling is 50x.
Consumers create their own subscribers, delivering to over 250 AWS services — routing moved from bus owner to consumer.
Retention is 24 hours by default, settable 1 to 365 days, making replay a bus property.
Strict ordering with content-based deduplication, on a fixed 300-second window.
Pricing now charges for data transferred rather than events — payload size is the cost lever.
One subscriber create/delete in progress per bus, across all accounts; a second fails with ConcurrentModificationException.
Filter changes capped at 24 per subscriber per rolling 24 hours, not configurable.
Fourteen Regions at launch.