Lesson 147 · AWS Learning Path

AWS 147: Amazon EventBridge

Anil Jalela · Published Nov 19, 2025 · 8 min read

Why this lesson matters

Route events across buses using patterns, targets, schemas, archives, replay, schedules, and policies without confusing routing with queue storage.

What you will be able to do

By the end, you can:

• explain amazon eventbridge in plain language;
• locate the current service controls in the AWS Management Console;
• run the matching CloudShell or AWS CLI queries and explain every important field;
• draw the identity, network, data, failure, and monitoring path;
• choose the service from requirements and reject it when those requirements are absent;
• diagnose a failed or misleading result from evidence;
• state the cost owner and prove cleanup or a no-create result.

Before you start

• Use a personal AWS account only when its owner has approved the lesson. Do not use the root user for daily work.
• CloudShell is the default command environment. AWS028 explains CloudShell; AWS029 and AWS030 explain local AWS CLI installation and profiles.
• The course example Region is ap-south-1. Global services and services with a required control Region are called out in their commands.
• Run aws sts get-caller-identity privately. Redact the account number before sharing evidence.
• Never paste access keys, passwords, secret values, private object data, presigned URLs, or full account-specific ARNs into a submission.
• This is a no-create lesson. Every Console action and AWS CLI command is read-only. Create the practical artifact locally.
• Console wording can change. Use the Console service search if a menu label has moved, then confirm the current field in the official documentation.

The core model

How the request flows

+----------------------+
|    Event producer    |
+----------------------+
           |
           v
+---------------------------+
|  Bus and content pattern  |
+---------------------------+
             |
             v
+-----------------------+
|  One or more targets  |
+-----------------------+
           |
           v
+--------------------------------------------+
|  Retry, DLQ, archive, and target evidence  |
+--------------------------------------------+

For Amazon EventBridge, the important boundary is this: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon EventBridge. Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon EventBridge. That is why the lesson pairs the Console with CLI output and a practical artifact. One interface may hide a field, use a cached view, or be scoped differently. Matching evidence is stronger than a screenshot alone.

Architecture decision table

Event buses, rules and delivery

An event envelope has stable routing metadata - source, detail-type, time, Region/account/resources - and a domain-owned detail payload. AWS service events arrive on the default bus; applications use default or custom buses; partner buses receive supported SaaS events. Resource policies can permit cross-account PutEvents, but organization/account/source restrictions and target roles must be explicit.

Rules compare the whole event against declarative JSON patterns. Fields not mentioned are ignored; arrays, prefixes, numeric matching, exists/anything-but and nested structures have exact semantics. Rules are not processed in a guaranteed order and may match the same event. Use the console sandbox/test-event-pattern plus positive, negative and schema-evolution fixtures. A broad { "source": [...] } pattern can route sensitive or recursive events. Prevent loops with source/detail markers and architecture boundaries.

After a match, EventBridge transforms or passes input and invokes each target independently using a resource policy or execution role according to target type. Delivery is at least once and target order is not guaranteed. Configure maximum age, retry attempts and an encrypted SQS DLQ per target where supported. A DLQ record means target delivery failed; it does not capture target-side business failure after acceptance.

Archives retain selected bus events and replay them later to the source bus; replayed events can retrigger every matching current rule, so use isolation, idempotency and controlled windows. Schema Registry/discovery can help code generation and evolution but does not enforce producer compatibility. API Destinations add connections/credentials, rate limits and third-party endpoint behavior. EventBridge Scheduler is the purpose-built scheduler for one-time/recurring invocations; scheduled rules are legacy-compatible but are not the same feature.

Event buses route; they are not consumer-controlled durable queues with receive/delete/visibility semantics. Add SQS when a consumer needs backlog, pull rate, redrive and independent retention. Monitor PutEvents entry failures, matched events, invocations, failed/throttled invocations, DLQ depth, archive/replay and target business metrics.

AWS Management Console, step by step

Sign in with the normal non-root learning identity. Write the expected starting state before opening the service.

1. Use the Console service search and open EventBridge, Event buses, Rules, Pipes, and Scheduler; confirm the account and Region before reading the page.
2. Inspect the supplied or owned resource's status, configuration, permissions, networking, encryption, monitoring, tags, and dependencies without changing it.
3. Open the related metrics, logs, events, or history view and record one timestamped signal that would prove or disprove the expected behavior.
4. Return to the resource list, clear filters, and record the final inventory. On the read-only track, do not choose Create, Save, or Delete.

CloudShell and AWS CLI, step by step

Start with a known caller and Region:

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws configure list

Redact the account part of the ARN in shared evidence. Now run the topic queries:

aws events list-event-buses --query 'EventBuses[].{Name:Name,Arn:Arn}' --output table
aws events list-rules --event-bus-name default --query 'Rules[].{Name:Name,State:State,Pattern:EventPattern,Schedule:ScheduleExpression}' --output table
aws scheduler list-schedules --output table

Expected interpretation

An enabled rule still requires a matching event, authorized target invocation, target success, retry evidence, and DLQ handling.

Practical work

Write an OrderCreated event envelope and three rules. Test positive and negative pattern cases, target permissions, retry policy, DLQ, archive/replay need, and schema ownership.

Version the schema and route billing, fraud and analytics without duplicating business truth. Include malformed batch-entry response handling, cross-account bus policy, target role, KMS, loop prevention and trace ID. Test unexpected source, missing detail field, duplicate event ID/business key, target denial/throttle, DLQ, archive replay against changed rules and scheduler timezone/DST assumptions.

Diagnose this topic from its own evidence

First inspect PutEvents per-entry results; an HTTP success can contain failed entries. If put succeeds but no match, run the exact archived event through the exact rule pattern and verify bus/account/Region. A match with failed invocation points to target policy/role, KMS, quota or endpoint response; correlate rule metrics and DLQ. Repeated events may be retry or a loop - trace event ID, source and producer logs. Never broaden the pattern to {} as a production diagnostic.

Cost and cleanup

Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Knowledge check

1. What operational purpose is this lesson solving?

Expected direction: Route events across buses using patterns, targets, schemas, archives, replay, schedules, and policies without confusing routing with queue storage.

1. Which scope or ownership boundary must be proved first?

Expected direction: The learner must identify the account and Region scope, resource boundary, identity path, data or network path, failure behavior, observability, and cleanup ownership for Amazon EventBridge.

1. What evidence is strong enough to accept the result?

Expected direction: Success means the Console fields, CLI result, workload behavior, monitoring evidence, and architecture claim agree. An available state alone is not enough for Amazon EventBridge.

1. Which tempting design or shortcut must be rejected?

Expected direction: Avoid treating an event bus as an unlimited ordered queue or writing broad patterns that match unintended events.

1. Which cost dimensions and retained resources need an owner?

Expected direction: Requests, running capacity, storage, logs, data transfer, retained state, and optional features must be priced for the exact design.

Lesson acceptance

Pass when the learner designs a versioned envelope, tests precise patterns, maps bus/target authorization, handles at-least-once idempotently, separates target-delivery DLQ from business failure, and safely plans archive/replay and scheduling. Fail if EventBridge is treated as an ordered queue, PutEvents HTTP success replaces entry checks, or replay/loops can trigger uncontrolled side effects.

Official sources

• EventBridge User Guide
• Event patterns
• Lambda Developer Guide
• Serverless Lens