Amazon EventBridge
Serverless event bus that routes events from AWS services, your applications, and SaaS partners to targets based on rules that match event content.
Verified against AWS documentation · 2026-08-24
Key facts
- 01Producers publish to a bus, rules match on the event's JSON body, matched events fan out to targets — no polling, no consumers to run
- 02Three bus types: default (AWS service events, free to ingest), custom (your apps), partner (SaaS); rules filter on payload content, not just metadata
- 03At-least-once delivery, no ordering guarantee — failed deliveries retry ~24 hours / 185 attempts, then drop unless a standard SQS DLQ is attached
- 04Limits: 1 MB max PutEvents request, 5 targets per rule (hard, not adjustable), 300 rules per bus, 100 buses per Region
Exam triggers
Phrases and scenarios that point here.
- "React to a change in state", "event-driven", "loosely coupled", "serverless integration between AWS services"
- An AWS service action must trigger something — S3 upload, EC2 state change, CloudTrail API call, Config finding → EventBridge, not SNS or SQS
- "Schedule", "cron", "nightly job", "run every N minutes" without a server → EventBridge Scheduler or a scheduled rule
- Ingesting events from a third-party SaaS (Datadog, Zendesk, Auth0, Shopify) → partner event bus; no other AWS service does this
Not this service
- High-throughput fan-out to many subscribers, or push to SMS/email/mobile → SNS (EventBridge caps at 5 targets per rule)
- Multi-step workflow with state, branching, and per-step retries → Step Functions; EventBridge routes single events, it doesn't orchestrate
Use cases
- 01Reacting to control-plane changes without polling — a security group opening port 22 to the world fires a rule within seconds of the API call and invokes a remediation Lambda, instead of waiting for a scheduled compliance scan
- 02Retiring cron boxes with EventBridge Scheduler — stopping non-production RDS instances and EC2 fleets at 7pm and restarting at 8am in the team's local timezone, with no server to patch and no drift when DST shifts
- 03Adding a consumer to an existing domain event without touching the producer — an OrderPlaced event already on the bus picks up a new fraud-scoring target by adding one rule, and the ordering service ships nothing
- 04Centralizing security signals across accounts — spoke accounts forward GuardDuty findings and Config non-compliance events to a single bus in the security account, so routing and alerting live in one place
- 05Pushing internal events straight to SaaS tools via API destinations — a deployment-failed event calls the PagerDuty or Slack HTTP endpoint directly, with auth and rate limiting handled by the connection instead of a glue Lambda
How it's charged
- 01You pay at ingest, not at fan-out — rules, pattern evaluation, and same-account delivery are free, so a fifth consumer on an existing event adds nothing to the EventBridge meter (the target's own meter still bills)
- 02AWS service management events on the default bus are ingested free; your own custom events and SaaS partner events are billed per million published
- 03Billed in 64 KB chunks, not per event — a 256 KB event counts as four, and at the 1 MB ceiling one event can bill as sixteen, so trim payloads or store the body in S3 and pass a pointer
- 04Cross-account and cross-Region delivery is charged to the sending account, so a hub-and-spoke security bus pays on every forward while same-account delivery stays free
- 05Archive and replay meter three separate ways — data archived, data stored per month, and events replayed; Scheduler bills on its own meter with a large monthly free allowance
