EventBridge routes events to targets based on rules, and it can also run on a schedule. It decouples producers from consumers: a producer emits an event, and any number of rules route it, so adding a consumer does not change the producer.
Before you start
You should understand events and queues. This article covers rules, schedules and delivery.
Step-by-step walkthrough
Step 1: Match events with rules
A rule has an event pattern that matches fields such as source and detail type, and one or more targets. An event that matches no rule is dropped unless you capture it, so patterns must be written deliberately and tested against real events.
Step 2: Run scheduled jobs with rate or cron
A rule can use a rate(...) or cron(...) expression to invoke a target on a schedule, which replaces a cron server. The schedule is managed and scales without a host, and the target is typically a Lambda or a task.
Step 3: Handle delivery failures
Delivery is at-least-once, so a target may receive an event more than once and must be idempotent. Failed deliveries retry and can go to a dead-letter queue; without a DLQ, failures are lost. Configure retries and a DLQ so a bad event is visible.
Worked scenario
The rule matches order events and routes to a Lambda.
{
"source": ["app.orders"],
"detail-type": ["OrderPlaced"],
"detail": { "status": ["confirmed"] }
}Walk through the example
Only OrderPlaced events from app.orders with a confirmed status match, and they are sent to the target. Events outside the pattern are not delivered, which is why the pattern must reflect the real event shape. The target must tolerate duplicate delivery.
Common mistake
Assuming exactly-once delivery, so a duplicate event causes a duplicate side effect. Another is no dead-letter queue, so a persistently failing event disappears silently.
Verify the behavior
Send an event that matches and confirm the target fires; send one that does not and confirm it is dropped. Trigger the schedule and confirm the target runs. Force a target failure and confirm the event reaches the DLQ after retries.
Interview exercise
Why must an EventBridge target be idempotent?
Answer and reasoning
Because delivery is at-least-once: retries and internal duplication can deliver the same event more than once. A target that is not idempotent would perform the side effect twice, such as charging a customer twice. Idempotency keys or deduplication make repeated delivery harmless.
Continue learning
Compare fan-out in SNS fan-out and delivery in SQS delivery. Read the AWS EventBridge documentation and try the AWS interview questions.