Amazon EventBridge

A serverless event bus. Routes events from sources (AWS services, your code, SaaS partners) to targets (Lambda, SQS, SNS, Step Functions, HTTP endpoints, …) based on declarative rules. The modern replacement for “SNS topic fans out to handlers” when you need pattern-based routing.

EventBridge vs SNS vs SQS

Rule of thumb:

• Two-service handoff with reliability → SQS.
• Fan-out to a few subscribers with simple filters → SNS.
• Many event types, many consumers, want pattern-based routing → EventBridge.

Event structure

{
  "version": "0",
  "id": "6a7e8feb-b491-...",
  "detail-type": "Order Placed",
  "source": "myapp.orders",
  "account": "123456789012",
  "time": "2026-05-12T18:43:48Z",
  "region": "us-east-1",
  "resources": [],
  "detail": {
    "order_id": "ord_42",
    "user_id": 7,
    "total": 99.50,
    "currency": "USD"
  }
}

Required fields: source, detail-type, detail. AWS-emitted events follow the same shape; the source is something like aws.s3 or aws.ec2.

Rules — pattern matching

{
  "source": ["myapp.orders"],
  "detail-type": ["Order Placed"],
  "detail": {
    "total": [{ "numeric": [">", 100] }],
    "currency": ["USD"]
  }
}

Match operators:

• Exact: ["USD"]
• Anything-but: [{"anything-but": ["test"]}]
• Prefix: [{"prefix": "ord_"}]
• Numeric ranges: [{"numeric": [">", 100, "<=", 1000]}]
• Exists: [{"exists": true}]
• IP CIDR: [{"cidr": "10.0.0.0/8"}]

A single rule can have multiple targets; events matching the pattern fan out to all of them.

Targets

Common ones:

• Lambda — invoked async.
• SQS — durable buffering before processing.
• SNS — additional fan-out.
• Step Functions — kick off workflows.
• API Destinations — call any HTTP/HTTPS endpoint (with optional connection auth).
• EventBridge bus in another account/region — cross-account routing.
• Kinesis / Firehose — stream to analytics.
• ECS task / batch job — invoke containers.

Per-target options:

• Input transformer — reshape the event before delivery.
• Dead-letter queue — capture failures.
• Retry policy — max age + retry attempts.

# CDK / boto3 — example rule
events.put_rule(
    Name="high-value-orders",
    EventBusName="default",
    EventPattern=json.dumps({
        "source": ["myapp.orders"],
        "detail-type": ["Order Placed"],
        "detail": {"total": [{"numeric": [">=", 100]}]},
    }),
    State="ENABLED",
)
events.put_targets(
    Rule="high-value-orders",
    Targets=[
        {"Id": "1", "Arn": LAMBDA_ARN},
        {"Id": "2", "Arn": HIGH_VALUE_SQS_ARN, "SqsParameters": {"MessageGroupId": "orders"}},
    ],
)

Buses

• default bus — receives all AWS service events automatically.
• custom bus — for your own events; isolation per domain / team.
• partner bus — created when you subscribe to a SaaS partner (Auth0, Datadog, Zendesk, Shopify) — events arrive automatically without webhook plumbing.

Cross-account: put a rule on bus A targeting bus B in another account; receiving account’s bus has resource policy allowing the sending account.

Schema Registry

Discovers schemas from events flowing through a bus and stores them; can be used to generate code bindings.

aws events put-rule --name discover-schema \
  --event-pattern '{"source":["myapp.orders"]}'
# Schema Discovery auto-creates schema in registry as events flow

Useful for: cross-team contracts, generating TypeScript/Python clients that emit valid events.

Archive + Replay

Archives can capture all matching events for a configurable retention window. Replay sends archived events back through your bus — useful for:

• Reprocessing after fixing a bug.
• Reproducing prod issues in staging.
• Backfilling new consumers with historical events.

aws events create-archive --archive-name orders-archive \
  --event-source-arn $BUS_ARN --retention-days 90

# Later — replay last 24h
aws events start-replay --replay-name fix-bug-X \
  --event-source-arn $ARCHIVE_ARN \
  --event-start-time 2026-05-11T00:00:00Z \
  --event-end-time 2026-05-12T00:00:00Z \
  --destination Arn=$BUS_ARN

This is one of EventBridge’s killer features. SNS has no equivalent.

Pipes

EventBridge Pipes (2022+) — a managed point-to-point integration with optional filter + enrich + transform stages.

source (Kinesis / DynamoDB Stream / SQS / Kafka / MSK / MQ)
   ↓ filter
   ↓ enrich (Lambda / Step Functions / API destination)
   ↓ target (Lambda / SQS / SNS / Step Functions / EventBridge bus / ...)

Replaces “Lambda that polls DDB stream, filters, calls API, writes to SQS” with a managed config. Less code; more reliability; built-in DLQ + retries.

Scheduler

EventBridge Scheduler (2022+) — managed cron / time-based triggers. Replaces “CloudWatch Events scheduled rules” (which still work but are legacy).

Differences vs scheduled rules:

• Higher per-account limit (millions of schedules vs hundreds).
• One-time + recurring.
• Per-schedule retry + DLQ.
• Time zones supported directly.
• Cleaner API.

For “fire a Lambda every 5 min” or “run this job at 03:00 UTC daily,” Scheduler is the modern choice.

Common patterns

Pattern 1: replace SNS → SQS fan-out with EventBridge → SQS

Old: producer → SNS topic → [SQS for service A, SQS for service B, SQS for service C]
New: producer → EventBridge bus → rules → [SQS_A, SQS_B, SQS_C]

Wins:

• Routing logic moves to declarative rules (vs subscription filter policies).
• Adding a new consumer = a new rule, no producer change.
• Archive + replay for free.

Pattern 2: cross-account event distribution

Account A’s bus has a rule targeting Account B’s bus. Resource policy on B’s bus allows A. Common in multi-team setups where each team owns a bus but events flow centrally.

Pattern 3: partner SaaS integration

Stripe, Auth0, GitHub, Datadog all emit to EventBridge via partner buses. Skip webhook receivers entirely — events arrive on a bus, you write rules.

Common gotchas

• Event size limit: 256 KB. Bigger payloads → store in S3, send a pointer.
• At-least-once delivery. Targets may receive an event twice. Idempotency required.
• No ordering guarantees. Events may arrive out of order at a target.
• Default bus is shared across the whole account. For domain isolation, custom buses.
• Schema Discovery on prod buses costs $$. Toggle off when not actively profiling.
• Pipes vs rules confusion. Pipes for point-to-point with enrich/filter. Rules for many-to-many routing on a bus.
• Schedule expressions: EventBridge cron differs from Unix cron (6 fields including year). Test carefully.

Cost

• Custom events: $1 per million published.
• Cross-region: $2/M.
• Partner events: free (SaaS pays).
• AWS events on default bus: free.
• Schema Registry: free for the registry; Discovery has per-event cost.
• Archive: storage $.10/GB-month + replay reprocessing fee.
• Scheduler: $1 per million invocations.

At typical scale, EventBridge is a rounding error in the AWS bill — much cheaper than the engineering time saved.

Interview angle

• “EventBridge vs SNS — when each?” — SNS for simple “tell these N services this happened” with subscription-level filters. EventBridge for many-to-many routing with declarative event patterns, archive+replay, schema management, partner integration, and cross-account routing. EventBridge is strictly more capable; SNS is simpler.
• “Design a real-time order-notification system.” — Producer publishes OrderPlaced to EventBridge custom bus. Rules route to: SQS for notifications-service (email/SMS), SQS for analytics-service, Lambda for fraud-check. Each rule can filter by detail.total, detail.country, etc. Archive enabled for replay during debugging.
• “What’s the difference between Pipes and rules?” — Pipes is point-to-point (one source → one target) with built-in filter/enrich/transform stages, replacing a custom Lambda pipeline. Rules are many-to-many routing on a bus. Pipes for stream → target ETL; rules for event broadcasting.
• “How do you avoid duplicate processing?” — EventBridge is at-least-once. Consumers must be idempotent. For exactly-once-effect, use idempotency keys keyed by event["id"] (EventBridge sets a unique id per event) or by domain identifier in detail.
• “Why pick EventBridge Scheduler over CloudWatch scheduled rules?” — higher limits (millions vs hundreds), per-schedule retry + DLQ, time-zone support, one-time schedules, cleaner API. Scheduled rules still work but are legacy.
• “Archive + Replay — when?” — reprocessing after fixing a consumer bug; reproducing prod incidents in staging; backfilling a new consumer with last 30 days of events. SNS can’t do this; EventBridge gives it as a managed feature.