Event-Driven Design with Amazon EventBridge

Why EventBridge is the bus, not the queue

Amazon EventBridge is a serverless event bus: producers put events, rules match event patterns, and EventBridge delivers to targets. SAP-C02 Task 2.4's loose coupling shows up here as temporal decoupling—the producer does not wait for every consumer—and Task 2.5's scale shows up as many producers to many consumers without a mesh of point-to-point APIs. Independent SAP-C02 study material by OpenExamPrep keeps EventBridge distinct from Amazon SNS (protocol fan-out) and Amazon SQS (competing consumers on a buffer).

HarborCart's fraud team wants every order.confirmed event, every Amazon S3 PutObject on the inbound invoice bucket, and every SaaS payment-partner dispute event. Those three sources should not each hard-code the fraud Lambda ARN. They put events on the right event bus; fraud owns rules.

Default, custom, and partner buses

AWS provisions a default event bus in each account and Region. AWS services deliver events there (for example aws.ec2 instance state-change notifications). You can also PutEvents onto the default bus, but mixing application events with AWS events on one bus makes rule hygiene harder in a large organization.

A custom event bus is a named bus you create for application or domain events (orders, inventory). Teams get a blast-radius boundary: inventory rules never see AWS Health events unless you explicitly route them. Resource policies on the bus control who may put events and who may create rules.

A partner event bus is how SaaS partner integrations land. You copy your account ID into the partner's setup, the partner creates a partner event source, and you associate that source with a bus. Only the partner account of that source may put events on the associated partner bus—an AWS::Events::EventBusPolicy that tries to open a partner bus like a custom bus is the wrong tool and can fail. HarborCart's payment SaaS (disputes, payouts) is a partner source; it is not a default-bus CloudWatch event and not an SNS topic the SaaS happens to know about.

Events are JSON with source, detail-type, detail, time, and account. Maximum event size is 256 KB. Oversize payloads use the claim-check pattern (S3 object plus a reference in detail).

Rules, patterns, and targets

You associate a rule with one bus. The rule's event pattern is a JSON fragment that must match—for HarborCart, source harborcart.orders and detail.status CONFIRMED. Matching is content-based on the event, which is richer than SNS attribute filters for nested fields, numeric comparisons, and existence checks.

Each matching event can go to up to five targets on that rule. AWS's own guidance is that a source that must reach a dozen systems needs more rules or an SNS topic (or SQS) as a target that then fans out. Targets include Lambda, SQS, SNS, Kinesis Data Streams, Step Functions, API destinations, another event bus, and more. You can transform the input before the target (input paths, input transformer) so consumers are not tightly coupled to the producer's field names.

Managed rules are created by AWS services. Force-deleting them breaks the service that owns them. Leave them unless AWS documentation for that service says otherwise.

Failed deliveries can use a DLQ (SQS) and retry policies on the target. That is not archive/replay; it is transport retry.

Archive and replay

An archive is attached to a source bus. You optionally apply an event pattern so you store only order.* events. Retention defaults to indefinite; you can set a day count. Archives are how HarborCart answers "the new fraud consumer missed last Tuesday."

Replay resends archived events. Constraints AWS documents:

• Replay only to the source event bus, not to a different bus.
• Optionally replay to specific rules on that bus so you do not re-email every shopper.
• Ten active concurrent replays per account per Region.
• Replay does not delete events from the archive; you can replay more than once.
• EventBridge deletes replay records after 90 days (the archive contents follow archive retention, not that 90-day replay-object lifetime).
• Replayed events include a replay-name field. EventBridge installs a managed rule so replayed events are not re-archived, avoiding loops.

Replay is for recovery and backfill, not for everyday competing-consumer work (that is SQS) and not for 365-day clickstream (that is Kinesis retention).

Pipes versus buses

EventBridge Pipes are point-to-point: one source, one target, with optional filter, enrichment, and enrichment/transform. Sources include Amazon SQS, Kinesis Data Streams, DynamoDB streams, Amazon MQ, Amazon MSK, and self-managed Apache Kafka. Enrichment can call Lambda, Step Functions, API Gateway, or an API destination, then the pipe delivers to the target.

Use a bus when many producers and many consumers must meet. Use a pipe when HarborCart already has orders.fifo and needs a filtered, enriched delivery into Step Functions without writing a Lambda that only exists to poll SQS and StartExecution. Pipes are not a partner SaaS ingest path; partner events still land on a partner bus first.

Schema registry

The EventBridge schema registry stores schemas (OpenAPI 3 or JSON Schema) for events. Schema discovery can infer schemas from events on a bus so consumer teams generate code bindings instead of guessing detail fields. Discovery has a cost meter; turn it on in non-production or for a sampling window if spend matters. Schemas do not replace IAM or bus policies; they reduce consumer breakage when HarborCart adds detail.currency.

Scheduler versus rate and cron rules on a bus

EventBridge Scheduler is a dedicated serverless scheduler. AWS FAQs state it builds on scheduled rules and adds time zones, higher scale (AWS documents millions of tasks), custom payloads, one-time schedules, flexible time windows, retry limits, and a monitoring dashboard. You do not need an event bus to create a schedule. Templated targets cover SQS, SNS, Lambda, and EventBridge; a universal target can call more than 270 AWS services and 6,000+ APIs.

Scheduled rules on an event bus (rate or cron) still exist. AWS labels creating a scheduled rule as legacy in the EventBridge user guide and recommends Scheduler for new work. HarborCart's "every weekday at 09:00 America/New_York, start the replenishment Step Functions" is Scheduler with a timezone. "Every 5 minutes, put a tick on the default bus for any rule that still listens" is the old rate rule. One-time "retry this payout at 02:17 UTC tomorrow" is Scheduler, not a bus rule you remember to delete.

Cross-account events

Multi-account HarborCart (orders account, fraud account, data account) uses resource policies on the destination bus. The classic pattern: a rule in account A targets the event bus ARN in account B; B's policy allows A's principal events:PutEvents (and you tighten with source, event bus ARN, and organization ID conditions). AWS also expanded APIs so some rule operations can target a cross-account bus ARN, and later launched direct cross-account targets (for example SQS, Lambda, SNS in another account) so you are not forced to place a second bus in the consumer account. On the exam, read the constraint: if the stem still describes bus-to-bus isolation (consumer team owns rules on their bus), do that; if it asks to drop the extra bus, direct targets are the newer capability.

Never "just PutEvents" into a partner bus from your own account. Never open a destination bus to Principal: * without conditions.

HarborCart SaaS partner flow

1. Payment SaaS creates a partner event source for HarborCart's account.
2. HarborCart associates it with a partner event bus payments-saas.
3. A rule matches detail-type = DisputeCreated and targets the fraud SQS queue in the security account (cross-account target or intermediate bus).
4. An archive on payments-saas keeps disputes 30 days.
5. When fraud ships a new classifier, they replay two days of disputes to the new rule only.
6. Order events stay on the custom orders bus; AWS EC2 events stay on default. Schema discovery runs on orders in the shared-dev account.

Traps

1. Putting SaaS partner events on the default bus with a handmade HMAC Lambda and calling that a partner integration.
2. Expecting replay onto a different bus.
3. One rule with twelve targets.
4. Using a bus when the need is SQS-to-Step Functions Pipes.
5. New cron work on scheduled bus rules when Scheduler is the feature-rich service.
6. Cross-account with no bus policy.
7. Treating schema registry as an authorizer.