Not all events should flow through the same pipe. EventBridge provides three distinct bus types, each serving a different traffic source.
1. Default Event Bus
Every AWS account has exactly one default event bus, created automatically. This bus receives all events generated by AWS services themselves — things like EC2 instance state changes, S3 object creation notifications, CloudWatch alarm state transitions, CodePipeline execution updates, and hundreds of other AWS service events.
You cannot delete the default bus, and you cannot send custom application events to it (well, technically you can, but it is a bad practice — mixing infrastructure events with application events makes rules harder to manage and audit).
Use case: React to AWS infrastructure changes. For example, automatically trigger a Lambda to send a Slack notification whenever an EC2 instance enters the stopped state.
2. Custom Event Buses
These are buses you create and name yourself. They carry events from your own applications — creating one is a single API call that takes nothing but a name.
You might create separate buses for different domains: marketing-bus, fulfillment-bus, payments-bus. This isolation means a misconfigured rule in the marketing domain cannot accidentally route payment events to the wrong target. It also makes IAM permissions cleaner — the payments team can be granted access only to the payments bus.
Use case: Application-level events like OrderPlaced, UserSignedUp, PaymentProcessed.
3. Partner Event Buses
AWS has pre-built integrations with dozens of SaaS providers. When you enable a partner event source (e.g., Shopify, Datadog, Auth0, Zendesk, PagerDuty), AWS creates a special partner event bus in your account. Events from that SaaS platform flow directly into this bus without you writing any polling or webhook infrastructure.
Use case: Trigger a Lambda whenever a Zendesk ticket is created, or run a Step Functions workflow whenever a Shopify order is fulfilled — all without managing API credentials or polling loops.
Key Point: Bus isolation is an architectural decision, not just an organizational preference. In a multi-team environment, separate buses enforce domain boundaries and enable independent IAM policies. Cross-account event delivery is also possible — you can grant another AWS account permission to put events onto your bus, enabling event-driven communication between accounts without VPC peering or API gateways.