AWS EventBridge: Serverless Event Bus & Routing

Q: EventBridge vs SNS vs SQS — which do I use?

Rough rule of thumb: use SQS when you need a durable work queue between two components (buffering, retries, one consumer group). Use SNS for simple, fast pub/sub fan-out to a few subscribers. Use EventBridge when you want content-based routing across many event types and sources, integration with SaaS partners or custom buses, scheduling, or API destinations. They're often combined — e.g. an EventBridge rule delivering to an SQS queue that a fleet drains.

Q: How do I schedule recurring jobs?

Use EventBridge Scheduler — create a schedule with a cron or rate expression and point it at a target (Lambda, Step Functions, etc.). It's the modern, scalable replacement for scheduled CloudWatch Events rules and supports time zones, one-time schedules, and flexible time windows.

Q: Can EventBridge call external (non-AWS) APIs?

Yes — via API destinations. You configure a connection (with API key, OAuth, or Basic auth managed by EventBridge) and an HTTPS endpoint, then target it from a rule. EventBridge handles auth, retries, and rate limiting, making it a clean way to push events to third-party systems without a glue Lambda.

AWS EventBridge

Amazon EventBridge is AWS's serverless event bus — it receives events (JSON records describing "something happened") and routes them to targets (Lambda functions, SQS queues, Step Functions, and dozens more) based on rules that match on event content. It's the connective tissue of event-driven architecture on AWS: producers emit events without knowing who consumes them, and consumers subscribe declaratively without the producer changing.

EventBridge grew out of CloudWatch Events, and the two share the same underlying engine. What sets EventBridge apart is that it ingests events not just from ~200 AWS services but also from your own applications (custom buses) and from SaaS partners (Stripe, Zendesk, Datadog) — making it a hub for decoupling systems across boundaries. Much of the general event-driven and message queue thinking applies here; this is the AWS-native, fully managed implementation.

TL;DR

EventBridge is a serverless event bus that routes JSON events to targets based on rules — the backbone of event-driven design on AWS.
Three event sources: AWS services (built-in), your apps (custom event bus via PutEvents), and SaaS partners (partner event sources).
Rules match events with event patterns (filter on any field) and fan out to up to 5 targets each; content-based filtering happens in the bus, not your code.
EventBridge Scheduler replaces cron-style scheduled invocations (the old "CloudWatch Events rule on a schedule") at massive scale with one-time and recurring schedules.
Schema registry discovers and stores event shapes so you can generate typed bindings.
It's not a high-throughput streaming pipe (use Kinesis) or a work queue with fine-grained retry control (use SQS) — it's about routing and decoupling.

Core Concepts

Events, Buses, Rules, and Targets

The mental model is a pipeline:

An event is a JSON object with a standard envelope (source, detail-type, detail, time, region). An event bus receives events — you get a default bus (all AWS-service events land here), can create custom buses for your own domains, and get partner buses for SaaS integrations. A rule on a bus has an event pattern and one or more targets; when an event matches the pattern, EventBridge delivers a copy to each target.

Event Patterns (Content-Based Filtering)

Rules match on the event body, so filtering happens in the bus — consumers only ever see events they care about. A pattern is JSON that mirrors the event structure:

This matches only confirmed orders over $100. Patterns support prefix matching, numeric comparisons, anything-but, existence checks, and more — meaningfully richer than SNS message filtering. This is the key advantage: routing logic lives in declarative rules, not scattered if statements in your handlers.

Targets and Delivery

A rule can send matched events to up to 5 targets, and a huge catalog is supported: Lambda, SQS, SNS, Step Functions, ECS tasks, Kinesis, another event bus (cross-account/cross-region), and API destinations (call any external HTTP API with managed auth). EventBridge retries failed deliveries with exponential backoff and supports a dead-letter queue (SQS) for events that can't be delivered — important, because otherwise failed events are silently dropped after retries exhaust.

EventBridge Scheduler

EventBridge Scheduler is a dedicated service for time-based invocation — one-time or recurring (cron/rate) schedules that trigger any target. It supersedes the old pattern of a scheduled rule on the default bus, scaling to millions of schedules with per-schedule time zones, flexible time windows, and built-in retries. If you were reaching for "run this Lambda every 5 minutes" or "kick off this job at 2am," this is the modern answer.

Schema Registry and Pipes

Schema registry — discovers the structure of events flowing through a bus and stores versioned schemas, from which you generate typed code bindings (Java, Python, TypeScript).
EventBridge Pipes — point-to-point integrations with optional filtering and enrichment, purpose-built for connecting a source (e.g. a DynamoDB stream or SQS queue) to a target with a transform step in between — a lighter-weight alternative to writing glue Lambdas.

Common Mistakes

Using EventBridge as a Streaming or Work Queue

EventBridge routes discrete events with at-least-once delivery, but it is not a high-throughput streaming service or an ordered work queue. If you need ordered, replayable, high-volume records (analytics, log pipelines), use Kinesis. If you need a durable work queue with visibility timeouts and fine control over redrive, use SQS. EventBridge shines at routing and decoupling, not buffering heavy load.

Forgetting the Dead-Letter Queue

By default, if a target keeps failing, EventBridge exhausts retries and drops the event. Without a DLQ configured on the target, those events are gone with no record. Always attach an SQS DLQ to important rules so undeliverable events can be inspected and replayed.

Over-Broad Event Patterns

A pattern that matches too much floods targets (and your Lambda bill) with events they immediately discard. Push filtering into the pattern — match on source, detail-type, and specific detail fields — so targets only fire for events they truly need. This is the whole point of content-based routing.

Assuming Ordering or Exactly-Once

EventBridge delivers at least once and does not guarantee ordering. Duplicate deliveries happen; design targets to be idempotent. If strict ordering matters, EventBridge is the wrong tool — reach for a Kinesis stream or an SQS FIFO queue.

Confusing It with SNS

Teams often ask "isn't this just SNS?" SNS is simpler and lower-latency pub/sub with basic filtering; EventBridge adds rich pattern matching, the SaaS/partner and custom-bus ecosystem, scheduling, schema discovery, and API destinations — at slightly higher latency and cost. Picking EventBridge "because events" when plain SNS fan-out would do adds needless complexity.

FAQ

EventBridge vs SNS vs SQS — which do I use?

Rough rule of thumb: use SQS when you need a durable work queue between two components (buffering, retries, one consumer group). Use SNS for simple, fast pub/sub fan-out to a few subscribers. Use EventBridge when you want content-based routing across many event types and sources, integration with SaaS partners or custom buses, scheduling, or API destinations. They're often combined — e.g. an EventBridge rule delivering to an SQS queue that a fleet drains.

Is EventBridge a Kafka replacement?

No. Kafka (or Kinesis) is a durable, ordered, replayable log built for high-throughput streaming with consumer-controlled offsets. EventBridge is a routing bus with at-least-once delivery and no replay of the bus itself. They solve different problems; some architectures use both (stream in Kafka/Kinesis, route control events through EventBridge).

How do I schedule recurring jobs?

Use EventBridge Scheduler — create a schedule with a cron or rate expression and point it at a target (Lambda, Step Functions, etc.). It's the modern, scalable replacement for scheduled CloudWatch Events rules and supports time zones, one-time schedules, and flexible time windows.

What happens when a target fails?

EventBridge retries with exponential backoff for up to 24 hours (configurable maximum age and retry count). If retries exhaust and you've configured a dead-letter queue, the event lands there for inspection/replay; if not, it's dropped. Always set a DLQ on rules whose events you can't afford to lose.

Can EventBridge call external (non-AWS) APIs?

Yes — via API destinations. You configure a connection (with API key, OAuth, or Basic auth managed by EventBridge) and an HTTPS endpoint, then target it from a rule. EventBridge handles auth, retries, and rate limiting, making it a clean way to push events to third-party systems without a glue Lambda.