AWS EventBridge Explained for Event-Driven Applications

Amazon EventBridge is AWS’s serverless event bus for connecting applications with a stream of JSON events. Producers publish facts—“order placed,” “file uploaded,” “deployment finished”—without knowing which services will react. Consumers subscribe with rules that filter and route events to targets such as Lambda, Step Functions, SQS queues, or API destinations.

If you are moving from point-to-point Lambda triggers toward clearer domain boundaries, EventBridge is often the backbone of an event-driven design on AWS.

Events, buses, and rules

Event envelope

Every EventBridge event includes fields like source, detail-type, detail, account, region, and time. Your application payload lives in detail, usually as a JSON object.

Convention matters: use dotted source names (com.mycompany.orders) and stable detail-type strings (OrderPlaced) so rules stay readable.

Event buses

• Default bus — receives events from AWS services automatically (EC2 state change, S3 notifications forwarded, etc.).
• Custom event buses — isolate domains or tenants; only publishers you authorize can put events on the bus.
• Partner event buses — ingest events from SaaS integrations EventBridge supports.

Most greenfield apps create at least one custom bus per environment (orders-prod, orders-staging) to avoid accidental cross-talk.

Rules

A rule matches events (with optional content filtering) and forwards copies to targets. Multiple targets can react to the same event—fan-out without the producer looping callers.

Rules are not queues. If a target is down, retry behavior depends on the target type and dead-letter configuration you attach.

EventBridge vs SNS vs SQS

Service	Mental model	Typical use
SNS	Pub/sub notifications, many subscribers, often push	Fan-out alerts, mobile push, triggering Lambdas
SQS	Durable queue, pull-based consumers	Work buffering, throttling, retries with visibility timeout
EventBridge	Event router with schema registry and content filtering	Domain events, SaaS integration, scheduled triggers

Common pattern: EventBridge rule → SQS queue → worker fleet. EventBridge handles routing; SQS handles backpressure.

Publishing events from your code

Use the PutEvents API (via AWS SDK). Batch up to ten entries per call for efficiency.

import boto3, json

client = boto3.client("events")
client.put_events(
    Entries=[
        {
            "Source": "com.example.billing",
            "DetailType": "InvoiceFinalized",
            "Detail": json.dumps({"invoiceId": "inv_123", "amountCents": 9900}),
            "EventBusName": "billing-prod",
        }
    ]
)

Grant the publisher IAM permission events:PutEvents on the bus ARN—nothing broader.

Consuming events

Lambda target

Create a rule with a pattern and point it at a Lambda function. The function receives the full event envelope. Keep handlers idempotent: EventBridge may deliver more than once depending on downstream retries.

API destinations

HTTP endpoints (your SaaS or internal REST API) can be targets with optional OAuth connection resources. Useful when a partner cannot host an AWS integration but exposes a webhook.

Step Functions

Start state machines directly from rules—good for multi-step workflows that need visual auditing and built-in retry policies.

Archive and replay

Event archives retain matched events for replay after bug fixes. Replaying to the same bus can duplicate side effects unless consumers deduplicate with event IDs.

Filtering without fragile string hacks

EventBridge supports content-based filtering on detail fields:

{
  "source": ["com.example.billing"],
  "detail-type": ["InvoiceFinalized"],
  "detail": {
    "amountCents": [{ "numeric": [">=", 10000] }]
  }
}

Schema registries (and discovered schemas) help teams agree on detail shapes. Treat undocumented fields as private.

Scheduling with EventBridge Scheduler

EventBridge Scheduler (distinct from legacy CloudWatch Events rate expressions on the default bus) invokes targets on one-off or recurring schedules with flexible time windows and dead-letter queues.

Use Scheduler for cron-style jobs; use custom buses for domain events. Mixing concerns on one bus creates noisy rules.

Security and governance

• Resource policies on custom buses control which accounts and organizations can PutEvents.
• IAM policies on publishers and consumers follow least privilege per bus and rule.
• Encryption — EventBridge encrypts at rest with AWS owned keys by default; sensitive payloads may still need application-level encryption in detail.
• Audit — CloudTrail logs management operations; consider logging matched events to S3 or CloudWatch Logs for compliance when required.

Design guidelines that age well

1. Events name facts, not commands. Prefer OrderPlaced over ChargeCustomer unless you truly intend imperative messaging.
2. Version your detail schema with a schemaVersion field inside detail.
3. Keep details small — reference IDs, not megabyte payloads; store blobs in S3 and pass URIs.
4. Plan idempotency keys in consumers, especially when fan-out hits payment or inventory systems.
5. Document ownership — each source should map to an on-call team in your service catalog.

Failure modes teams learn the hard way

Infinite loops — Lambda publishes an event that triggers itself. Break cycles with rule filters or separate buses for commands vs facts.

Thundering herds — A deployment emits thousands of ResourceUpdated events per minute. Add SQS buffering or concurrency limits on targets.

Schema drift — Producers deploy before consumers understand new fields. Use contract tests and feature flags in consumers.

Assuming ordering — EventBridge does not guarantee global ordering across producers. Use sequence numbers in detail if order matters, or funnel through a single writer partition (e.g., Kinesis) when strict ordering is required.

FAQ

Is EventBridge the same as CloudWatch Events?
CloudWatch Events was rebranded and expanded into EventBridge. New work should use EventBridge APIs and terminology.

How do I test rules locally?
Use the EventBridge sandbox in the console, or put test events with the CLI aws events put-events. Unit-test consumer handlers with sample envelopes checked into your repo.

Can I cross regions?
Event buses are regional. Cross-region fan-out requires explicit forwarding (e.g., secondary bus in another region) or global services designed for it.

What about cost?
You pay per million events published and per invocations triggered. High-volume telemetry sometimes belongs on Kinesis or dedicated streaming stacks—profile before piping firehoses through EventBridge.

When should I skip EventBridge?
Tight synchronous request/response paths, ultra-low-latency internal RPC, or simple “one S3 file → one Lambda” flows may stay on direct triggers until cross-team events appear.

Observability and operations

Turn on CloudWatch metrics for matched events, failed invocations, and throttled targets per rule. Dashboards should show which detail-type values spike after deploys—often the first sign a producer changed JSON shape without telling consumers.

For on-call runbooks, store sample events (redacted) alongside each rule. When a target Lambda errors, replaying the sample in a staging bus validates fixes without touching production traffic. Tag rules with Owner and Service dimensions so paging routes to the team that created the rule, not the default platform rotation.

As traffic grows, consider event governance: a lightweight RFC for new source namespaces, automated linting of PutEvents IAM policies, and alarms when a single publisher exceeds historical publish rates. EventBridge stays boring infrastructure when discovery and ownership stay explicit—exactly what search queries like “aws eventbridge” usually need before adoption spreads past the first enthusiastic squad.