Amazon EventBridge

What EventBridge is

EventBridge is a router for events. A bus receives events — from AWS services, from a SaaS partner, or from your own application via the PutEvents API — and every rule on the bus checks each event against a pattern that filters on its source, type, and contents. When an event matches, EventBridge forwards a copy to that rule’s targets, which run in parallel.

The point is decoupling with routing. A producer emits “order placed” and has no idea who reacts to it; the routing logic lives in the bus, not the producer. Design Beaver models EventBridge as a regional, API-accessed router rather than something that sits inside a VPC subnet, and validates as you draw which targets a rule can actually reach and what each one needs to be correct.

When to use EventBridge (and when not to)

Reach for EventBridge when you need content-based routing across many event types, sources, and targets — the routing belongs in the bus, not baked into every producer. It’s also the natural way to react to AWS service events, since most services emit them to the default bus for free, and the way to keep microservices decoupled so producers and consumers evolve independently.

Don’t reach for it for plain fan-out to a fixed, known set of subscribers — SNS is simpler and cheaper for pure pub/sub. A single consumer that needs a durable buffer is a bare SQS queue. High-throughput, strictly-ordered stream processing is Kinesis, not an event bus. And cron-style or one-off scheduled invocations are EventBridge Scheduler — a separate feature, not the event bus modeled here.

Variants: default, custom, and partner buses

These are the buses you actually choose between when placing one on a canvas — not to be confused with the separate EventBridge features (Scheduler, Pipes, Schema Registry, API Destinations) that aren’t modeled here.

EventBridge pricing

You pay per event published to a bus, and the fact that shapes architecture is that events AWS services emit to the default bus are free — reacting to an S3 upload or an EC2 state change costs nothing at the bus itself. Your own custom events and partner events are billed by volume, and there’s no separate charge for rules or delivery. The targets, though, carry their own normal charges.

How EventBridge connects to other services

A bus on a canvas is just a box until you know which targets a rule can actually deliver to and what each delivery requires — the resource-based policy, the direction, the at-least-once caveat. Design Beaver models each of these edges, so it knows what EventBridge can route to and what makes that route correct.

• →Lambda

  A rule matches an event and invokes a Lambda function with the event as its payload — the most common EventBridge target for running custom logic in response to an event

• →SQS

  A rule routes matched events into an SQS queue, giving a consumer a durable buffer to process them at its own pace — the routing-plus-queue pattern when you want both filtering and back-pressure

• →SNS

  A rule publishes matched events to an SNS topic to fan them out to many subscribers at once — EventBridge does the content-based routing, SNS does the fan-out

• →Step Functions

  A rule starts a Step Functions state machine execution when an event matches — the event becomes the workflow input, kicking off a multi-step process in response to something happening

What EventBridge can’t connect to

Some edges look reasonable on a canvas but don’t exist in AWS — the bus routes events to targets that can receive them, not into a database, bucket, or CDN. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕S3

  S3 is not an EventBridge rule target — the bus can't deliver an event into a bucket. The real relationship runs the other way: with EventBridge notifications enabled on the bucket, S3 sends object events TO the bus (an S3 -> EventBridge edge). To write to S3 in response to an event, target a Lambda that puts the object.

• ✕DynamoDB

  DynamoDB isn't a native rule target — a rule can't write an item to a table directly. Target a Lambda that writes the item instead. (DynamoDB Streams can be an event *source* via EventBridge Pipes, which is the reverse direction and a separate feature.)

• ✕RDS

  A database is not an event target — EventBridge has no way to deliver an event into RDS. Put a consumer (a Lambda target) between the bus and the database to persist anything.

• ✕SES

  SES is not a native EventBridge rule target — the bus can't hand an event to SES to send email. To email on an event, target a Lambda that calls SES. (SES can publish its own sending events TO EventBridge, which is the reverse direction.)

• ✕CloudFront

  CloudFront is a CDN that serves content from HTTP origins — it is neither an event target nor an event source for the bus. There is no EventBridge -> CloudFront relationship to draw.

• ✕Route 53

  A bus has no DNS-addressable hostname, and DNS is not an event target — Route 53 has no role in event routing. Producers and targets reach the bus through the EventBridge API, not a domain name.

Anti-patterns Design Beaver catches

These are the EventBridge mistakes that pass a diagram review but bite in production — the ones the validation engine flags as you draw.

Gotchas that bite in production

• Delivery is at-least-once. In rare cases a rule runs more than once for an event, or a target is invoked more than once. Make target handlers idempotent — dedupe on an event ID — instead of assuming exactly-once.
• Undeliverable events are dropped without a DLQ. After the retry policy is exhausted (24 hours or up to 185 attempts by default), an event that still can’t be delivered is gone. Attach a dead-letter queue — an SQS queue — to each target so you can inspect what failed.
• It’s not a streaming pipeline. An event bus routes discrete events with no ordering guarantee. For ordered, high-volume streams, that’s Kinesis, not EventBridge.
• Don’t reach for it just to fan out. If you’re not doing content-based routing, the bus is an extra hop and cost over publishing straight to SNS for fan-out or SQS for one durable consumer. Add EventBridge when the routing earns its place.
• FIFO and encryption caveats on SQS targets. Targeting a FIFO queue requires the rule to supply a message group ID and the queue to use content-based deduplication. EventBridge also can’t target an SQS queue encrypted with an AWS-owned KMS key.

Further reading

• Official AWS documentation
• Why we built a validation engine