Amazon EventBridge is AWS's event bus — a routing layer that takes events from many sources (your services, AWS-native services, third-party SaaS) and delivers them to many targets (Lambda, SQS, SNS, Step Functions, HTTP endpoints) based on rules. It's pub/sub for the AWS ecosystem.
EventBridge replaces and extends what was originally CloudWatch Events. If you've ever scheduled a Lambda on a cron or routed an S3 event to a queue, you've used EventBridge under the hood.
This guide covers what EventBridge is, how it differs from SQS and SNS, when it's the right tool, and how webhook events end up flowing through it.
How does EventBridge work?
The basic flow:
- Source publishes an event to an event bus. Sources include AWS services (S3, EC2, etc.), your own applications via the
PutEventsAPI, or third-party SaaS partners (Stripe, Shopify, GitHub via Partner Event Sources). - Event bus holds and routes the event. Each AWS account has a default event bus; you can create custom buses for your own events.
- Rules match events based on patterns (event source, type, payload fields). Each rule has one or more targets.
- Targets receive the matched event. Common targets: Lambda, SQS, SNS, Step Functions, Kinesis, ECS tasks, HTTP API endpoints, another EventBridge bus.
A single event can match multiple rules and deliver to multiple targets — true pub/sub fan-out.
EventBridge vs SQS vs SNS
These three services overlap and confuse most teams. The clean distinction:
| SQS | SNS | EventBridge | |
|---|---|---|---|
| Pattern | Queue (point-to-point) | Pub/sub (fan-out) | Event bus (pub/sub + routing) |
| Subscribers | One consumer pool | Many subscribers, no filtering | Many targets, with filtering rules |
| Filtering | None | Coarse (topic-level) | Rich (pattern-based on event content) |
| Sources | Anything that calls SendMessage | Anything that calls Publish | AWS services, your apps, SaaS partners |
| Targets | Pollers | SQS, Lambda, HTTP, SMS, email | 30+ AWS services + HTTP API endpoints |
| Right when | One consumer needs ordered durable processing | Simple fan-out to known subscribers | You need rule-based routing to many heterogeneous targets |
Use SQS when you have one consumer pool processing messages with clear ack/retry semantics.
Use SNS when you need simple fan-out to a known set of subscribers (an SQS queue + a Lambda + an SMS, for example).
Use EventBridge when the routing logic is non-trivial — events come from many sources, fan out to many targets, and the rules vary based on event content.
For agent systems specifically, EventBridge often wins because agents are one of many consumers (alongside analytics, audit, billing, CRM) and routing depends on event content.
EventBridge schemas and the schema registry
EventBridge has a Schema Registry that auto-discovers event schemas from the events flowing through your buses. You can generate code bindings (TypeScript types, Java classes, Python types) from these schemas.
This is more useful than it sounds. When a third-party SaaS partner ships events to your EventBridge bus, the registry captures the schema; you generate types; your handlers get type-safe access to the payload. No manual schema management.
For agent triggers, this matters less than for traditional applications — agents typically take payloads as JSON and process them with prompts. But for the deterministic parts of the system (routing, validation, projection), schema-aware code is a real productivity win.
EventBridge Pipes
EventBridge Pipes is a related service that connects a source (SQS, Kinesis, DynamoDB Streams, etc.) directly to a target (Lambda, SQS, Step Functions, EventBridge bus) with optional filtering and enrichment in between. Think of it as "EventBridge for streams."
Pipes are useful when you have a stream source (Kinesis, DynamoDB Streams) and want to route filtered events to specific targets without writing intermediate Lambdas. Out of scope for most agent triggers, but worth knowing it exists.
How webhook events get into EventBridge
Two main paths.
Partner Event Sources. AWS partners with several SaaS vendors so their webhooks flow directly into your EventBridge bus without you running a receiver. The partner emits events; AWS authenticates them; you write rules.
This is great if your provider is a partner — but the list is short and not all events are supported.
Custom forwarders. For everything else, you need a webhook receiver that calls EventBridge's PutEvents API. The receiver verifies the webhook, extracts the payload, and publishes to your bus.
You can build this yourself with Lambda and API Gateway. Or you can use a webhook relay like Hooksbase that has EventBridge as a Pro+ typed destination — authenticate ingest at the relay, verify supported provider packs when configured, transform if needed, and dispatch to EventBridge with the relay's reliability primitives in front (retries, DLQ, replay, delivery history).
The relay approach gives you the same EventBridge semantics on the consumer side, plus retained payload storage independent of EventBridge's retention and a queryable delivery history that EventBridge itself doesn't surface.
When EventBridge is overkill
EventBridge is the right tool when routing is the hard part. It's overkill when:
- You have one webhook source and one consumer (just call your Lambda directly).
- You don't need cross-target fan-out (use SQS).
- You're not in AWS (EventBridge is AWS-only).
For most "I need to route this webhook somewhere" needs, the answer is "to your application HTTP endpoint." EventBridge starts paying off when you have multiple AWS-native consumers downstream of the same webhook.
Where to go next
- What is SQS? for AWS's queue primitive
- Kafka vs SQS for webhook fan-out for the broader queue comparison
- What is a message queue? for when queues fit at all
- Event-driven architecture for AI agents for the broader pattern