Event Buses, Rules & Targets

## Three kinds of bus An **event bus** is the router: producers put events on it, rules attached to it evaluate every event, and matching rules invoke targets. Everything else in EventBridge hangs off that one idea. **The default bus.** Every AWS account has one per region, literally named `default`. Two things make it special. First, AWS services deliver their own events — an EC2 instance state change, an S3 object-created notification routed through EventBridge, a CodeBuild phase change — only here. You cannot configure `aws.ec2` to publish somewhere else. Second, because it is shared by everything in the account, it is the bus most likely to accumulate rules owned by different teams. **Custom buses.** You create these (`CreateEventBus`) and name them. They receive only what you explicitly publish with `PutEvents` (or what another bus forwards to them). Each one has its own set of rules, its own resource-based policy, its own archives, and its own share of per-bus quotas such as the number of rules. That isolation is the whole point. **Partner buses.** A SaaS vendor that has integrated with EventBridge exposes a *partner event source*; you accept it and EventBridge creates a bus dedicated to that source, with a name under the `aws.partner/` namespace. Their events then arrive on that bus and you write rules exactly as you would anywhere else. The value is operational: no webhook endpoint to run, authenticate, scale and retry — the vendor's events show up as first-class AWS events with the same rules, retries and DLQs. ## How to choose The practical rule is: **default bus for AWS's events, one custom bus per bounded context for yours.** Reasons to split into custom buses rather than putting everything on `default`: - **Blast radius and quotas.** Rules per bus is a quota. A domain that grows to hundreds of rules on the shared default bus becomes everyone's problem; on its own bus it is only its own team's problem. - **Access control.** A bus has a resource policy, so you can say who may `events:PutEvents` to *this* bus. Scoping that per domain is far easier to reason about than one policy on the account's default bus. - **Archives and replay.** Archives are configured per bus. A domain bus gives you a clean, cheap archive of just that domain's events instead of archiving every EC2 state change in the account. - **Clarity.** `orders-bus` tells a reader what flows through it. `default` tells them nothing. A reasonable counter-argument for smaller estates: one custom bus for the whole application is simpler than ten, and consumers can filter by `source` anyway. The split pays off when teams and ownership boundaries multiply, not when the event count does. ## Getting AWS service events onto a custom bus Because AWS services only emit to `default`, a common pattern is a forwarding rule: a rule on the default bus whose **target is another event bus**. Buses are valid targets, which is also how cross-account and cross-region fan-out is built — the receiving bus's resource policy has to permit it, and the rule needs an IAM role that allows `events:PutEvents` on the destination. ```json { "source": ["aws.s3"], "detail-type": ["Object Created"], "detail": { "bucket": { "name": ["acme-ingest"] } } } ``` A rule with that pattern on `default`, targeting `arn:aws:events:eu-west-1:111122223333:event-bus/ingest-bus`, moves just the S3 events you care about into the domain bus, leaving the noisy remainder behind. ## Things candidates get wrong The most frequent error is believing you can point an AWS service at a custom bus — you cannot, and the forwarding rule is the answer. The second is assuming a custom bus changes delivery semantics: it does not. Ordering is still not guaranteed, delivery to targets is still at-least-once, and an event matching no rule is still silently discarded on any bus. The third is treating a partner bus as an outbound channel; it is inbound only — sending events *to* a SaaS vendor is an API destination target, which is a different mechanism.