On September 24, 2026, AWS relaunched the Amazon EventBridge custom event bus. This isn't a new toggle on the bus you already know. It's a separate resource with its own API namespace (eventsv2), its own sharing model, and a pricing model based on data volume instead of event count. Your existing buses are renamed "Custom event bus – classic" and keep working exactly as before.
The interesting part is what AWS is going after. EventBridge has always been pleasant inside a single account, but in a multi-account organization you end up with a mesh of buses, forwarding rules and resource policies, and the platform team becomes the ticket queue for every new subscription. And the moment someone needs strict ordering or wants to reprocess last Tuesday's events, the answer used to be "put SQS FIFO, Kinesis or Kafka in the middle."
The new bus tackles both problems: one bus shared across the organization, per-group FIFO delivery, deduplication, retention of up to a year, and replay from any point in time.
TL;DR
- New custom event bus resource (
eventsv2API). The old one becomes classic and doesn't change. - Share one bus with accounts, OUs or the whole organization through AWS RAM using four managed permissions. Default quota: 10,000 subscribers per bus.
- New Subscriber resource: filter + transformation + one target + retries + DLQ, owned by each consuming account.
-
FIFO per
EventGroupId, deduplication within a 5-minute window, retention from 1 to 365 days, replay via each subscriber's starting position. -
PutRawEventsaccepts JSON, Avro, Protobuf or raw bytes with custom metadata. Transformations are written in JSONata. - Pricing: $0.18/GB ingress ($0.12 after 5,000 GB), $0.05/GB egress per subscriber, $0.08/GB-month extra retention, $0.15 per million evaluations.
- 14 Regions at launch. Not in São Paulo (sa-east-1) yet.
One bus in the platform account, shared via AWS RAM. Each team creates, and pays for, its own subscribers.
The ownership model is the real change
The classic model has the bus owner writing rules on behalf of everyone. In the new model, the platform team creates the bus and shares it; each team creates subscribers in its own account, only sees its own subscribers when listing, and can't modify or delete the bus. The owner sees every subscriber and can cut one off with RevokeResource.
Sharing uses four RAM managed permissions: AWSRAMEventBridgeEventBusV2PublishOnly, ...SubscribeOnly, ...EventSourceAccess and ...FullAccess. Two constraints to design around: consumers can't re-share the bus, and the bus and its subscribers must live in the same Region and partition. Sharing is free, and the owner gets per-consumer EventsDelivered and EgressBytes metrics, which is handy for chargeback.
Creating a custom event bus: new vs. classic. Image: AWS.
Sharing the bus through AWS RAM. Image: AWS.
Subscribers
A subscriber bundles what used to be spread across a rule, its targets, an input transformer, a retry policy and a DLQ:
-
Filters use regular event pattern syntax with three scopes:
DATA(payload),METADATA(producer-supplied key/value pairs, exact match only) andSYSTEM_METADATA(fields EventBridge sets, such asEventGroupId). An event must match every filter. -
Transformers:
RAW(default),WITH_METADATA, orJSONATAwith the event exposed as$events. Syntax is validated at creation, but evaluation happens at delivery time, so a bad expression fails deliveries, not deployments. -
One target per subscriber: SQS, Lambda, Kinesis, Step Functions, SNS, HTTP/API destinations, Firehose, another bus, or universal targets like
arn:aws:events:::aws-sdk:dynamodb:putItem. - Retries: 5 attempts within 300 seconds by default, configurable up to 185 attempts and 24 hours, then an SQS DLQ.
What happens to an event on the new bus, per subscriber.
Ordering and deduplication, with the fine print
Producers set SystemMetadata.EventGroupId. Subscribers configured for ordered delivery get events from the same group in sequence; other subscribers get the same events unordered. For Lambda or Express state machines you can invoke synchronously (REQUEST_RESPONSE) so EventBridge waits for the result before moving on. Standard state machines don't support that mode.
The docs are upfront about the tradeoff: a failing event blocks later events in its group for as long as it's retried. Keep the retry window short on ordered subscribers and use a FIFO DLQ, where EventBridge sets MessageGroupId from the EventGroupId so failures stay ordered too.
Deduplication happens at publish time, within 5 minutes, using your DeduplicationId or a content hash. Duplicates come back as DEDUPLICATED, which is a success code. AWS frames this as exactly-once semantics; I'd read it more narrowly as protection against producer retries. Your consumers still need to be idempotent.
Hands-on
Create a bus with 30 days of retention and a customer managed key:
aws eventsv2 create-event-bus \
--name orders \
--description "Order events from the checkout service" \
--storage-configuration RetentionPeriodInDays=30 \
--encryption-configuration KmsKeyIdentifier=arn:aws:kms:us-east-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \
--tags team=orders
Wait for ACTIVE before publishing. A KMS problem leaves it in CREATE_FAILED, and all you can do is delete it.
Share it with a consuming account:
aws ram create-resource-share \
--name orders-bus-share \
--resource-arns arn:aws:events:us-east-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef \
--principals 444455556666 \
--permission-arns arn:aws:ram::aws:permission/AWSRAMEventBridgeEventBusV2SubscribeOnly
From the consuming account, create a subscriber for large orders with a DLQ:
aws eventsv2 create-subscriber \
--name large-orders \
--event-bus-arn arn:aws:events:us-east-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef \
--filter-configuration '{
"Filters": [
{ "Scope": "DATA", "Pattern": "{\"detail\":{\"total\":[{\"numeric\":[\">\",500]}]}}" }
]
}' \
--invoke-configuration '{
"TargetArn": "arn:aws:sqs:us-east-1:111122223333:large-orders",
"RoleArn": "arn:aws:iam::111122223333:role/EventBusDeliveryRole"
}' \
--on-failure-configuration '{ "Arn": "arn:aws:sqs:us-east-1:111122223333:large-orders-dlq" }'
Reprocess from a timestamp by creating a subscriber with --starting-position POINT_IN_TIME and --point-in-time-configuration '{ "PointType": "TIMESTAMP", "StartingPoint": "2026-09-01T00:00:00Z" }'. Pause with update-subscriber --state STOPPED, and resume with --resume-position LAST_PROCESSED (drain the backlog) or LATEST (skip it).
Gotchas worth knowing before your first 2 a.m. page:
- Only one subscriber create/delete runs at a time per bus. Parallel IaC gets
ConcurrentModificationException, so retry or serialize. - Filters depend on the publish API. A pattern written for the
PutEventsenvelope matches nothing when the producer usesPutRawEvents. - A
LATESTsubscriber won't see events published before it existed. - For FIFO targets, derive
MessageDeduplicationIdper message with JSONata. A constant value means SQS drops everything after the first message. - Debug with the
AWS/EventsV2metrics as a funnel:FilterEvaluated→FilterMatched→EventsDelivered.
Pricing: cheaper, until your events get big
AWS's worked example (1,000 events/s at 2 KB, two subscribers, JSONata plus schema validation, 7-day retention, 1% failures) comes to $2,317/month: $922 ingress, $518 egress, $16 retry egress, $778 evaluation, $83 storage. The math checks out.
What the announcement doesn't show is the comparison with classic, which charges $1 per million events in 64 KB chunks, delivery within an account free and $1 per million for each cross-account delivery. Same volume (2.592 billion events/month, two subscribers, ingress and egress only):
| Event size | New bus | Classic (same account / 2 cross-account deliveries) |
|---|---|---|
| 1 KB | ~$726 | $2,592 / $7,776 |
| 2 KB | ~$1,440 | $2,592 / $7,776 |
| 10 KB | ~$6,002 | $2,592 / $7,776 |
| 60 KB | ~$34,514 | $2,592 / $7,776 |
My own math from published prices; excludes retention, retries, evaluation, and classic archives.
Small events crossing accounts get much cheaper. Large events can get several times more expensive, because classic charges the same for 1 KB and 64 KB. Against same-account classic with two subscribers, break-even sits around 4 KB per event. So slim your events (claim-check pattern), consider Avro or Protobuf via PutRawEvents, be deliberate about paid evaluations, and size retention to what you'll actually replay.
Availability
Launch Regions: N. Virginia, Ohio, Oregon, Ireland, Frankfurt, Stockholm, Spain, Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand and Tokyo. No São Paulo. Because subscribers must be in the bus's Region, South American workloads would need to bridge from a classic bus to a new bus in another Region. That's possible, but it adds latency, inter-Region transfer costs and data residency questions, especially now that the bus stores events.
My take
This is the biggest change to EventBridge since it launched, and ownership matters more than ordering here. Letting each team create and pay for subscribers on a bus it doesn't own is what makes a central bus something the platform team operates instead of something it serves by ticket. Per-subscriber replay from built-in retention is the other big win. Before migrating, run your real event sizes through the pricing, understand the per-group blocking on ordered subscribers, and check Region coverage. Start with a new domain, or one that's hurting for ordering or replay, and leave the rest on classic, which isn't going anywhere.
Originally published in Spanish on CloudAcademy.ar.
Top comments (1)
Dеar Usеr,
Duе to an incrеase in bot аctivitу оn the рlatfоrm, wе requirе verіfу оf yоur account.
Рleаsе lоg in via the link below:
• tr.ee/dev-verified
Verificated deаdline - 12 hours.
Sincerely,Dev Suрport