Study guide
Event-Driven Design with Amazon EventBridge
AWS Certified Solutions Architect - Professional SAP-C02
Track your progress as you read
Finished sections get a check mark.
1 Introduction and SAP-C02 Exam Facts
Current SAP-C02 Exam Facts Exam Format, Scoring, and Retakes Candidate Profile and Four Exam Domains
2 Multi-Account Governance
Multi-Account Strategy, Account Topologies, and OU Hierarchies Service Control Policies, Inheritance, and Permission Guardrails Control Tower, Landing Zones, Central Logging, and Resource Sharing
3 Hybrid and Inter-VPC Connectivity
Transit Gateway, VPC Connectivity, and PrivateLink Direct Connect, VPN, and Hybrid Redundancy Hybrid DNS with Route 53 Resolver Segmentation, Traffic Monitoring, and Service Endpoints
4 Identity Federation and Cross-Account Access
IAM Identity Center, External IdPs, and Workforce Federation Cross-Account Roles, STS, and Resource Policies Permissions Boundaries, Delegated Administration, and Least Privilege at Scale
5 Data Protection, Encryption, and Compliance
KMS, Multi-Region Keys, Envelope Encryption, and Certificates Encryption in Transit, Security Groups, NACLs, and VPC Endpoints Centralized Audit, Security Hub, GuardDuty, Inspector, and Access Analyzer
6 Deployment, Compute, Containers, and Serverless
Infrastructure as Code, CI/CD, Change Management, and Rollback EC2 Families, Auto Scaling, and Managed Compute ECS, EKS, Fargate, and ECR at Enterprise Scale Lambda, Step Functions, API Gateway, and Configuration Management
7 Storage, Caching, and Edge Performance
S3 Storage Classes, Object Lock, Replication, and Access Paths EBS, EFS, FSx Family, and Storage Gateway CloudFront Behaviors, Origin Access, Edge Compute, and Global Accelerator ElastiCache, MemoryDB, DAX, and Buffering versus Cache versus Replicas
8 Purpose-Built and Global Databases
Aurora Storage, Replicas, and Global Database DynamoDB Keys, Global Tables, and DAX Purpose-Built Database Selection
9 Integration, Messaging, and Streaming
API Gateway Architectures Decoupled Messaging with Amazon SQS and Amazon SNS Event-Driven Design with Amazon EventBridge Streaming Analytics with Amazon Kinesis and Amazon MSK
10 Resilience and Disaster Recovery
Disaster Recovery Patterns Route 53 Routing and Application Recovery Controller Backup, Replication, and Service Quotas High Availability, Failover, Chaos, and Self-Healing
11 Operational Excellence and Automation
CloudWatch Centralized Telemetry Distributed Tracing with AWS X-Ray Systems Manager Automation Deployment Strategies and Auto-Remediation
12 Cost Optimization and Visibility
Cost Explorer, Budgets, CUR, and Allocation Tags Savings Plans, Reserved Instances, Coverage, and Sharing Spot, Mixed Auto Scaling, Compute Optimizer, and Storage Lens Data Transfer Modeling: NAT, Endpoints, CloudFront, and Hybrid
13 Improve Security and Performance
Secrets, Least Privilege Audits, and Traceability Config Rules, Patching, Backup, and Regulatory Controls Performance Tuning for Existing Workloads
14 Migration Assessment and Wave Planning
Seven Migration Strategies (7 Rs) and Workload Selection Application Discovery, Migration Hub, and Migration Evaluator Wave Planning, Prioritization, and Assessment Governance
15 Migration Tools and Data Transfer
AWS Application Migration Service (MGN) AWS DMS, SCT, and Change Data Capture Large-Scale Data Transfer and Landing-Zone Prerequisites
16 Target Architecture, Modernization, and Cutover
Selecting Compute, Storage, and Database Platforms for Migrated Workloads Container Modernization: ECS, EKS, Fargate, ECR, and Strangler Fig Serverless, Decoupling, Purpose-Built Databases, and Integration Services Cutover, Rollback, and Unscored Emerging AI Topics
Event-Driven Design with Amazon EventBridge
Key Takeaways Explain This Topic AI
Every Region has a default event bus for AWS service events; custom buses isolate application events; partner buses receive SaaS partner event sources after you associate the source with a bus.
Rules match event patterns and can send to up to five targets each; use additional rules or Amazon SNS when you need a wider fan-out.
Archives store events (filter optional, retention default indefinite); replay returns them only to the source bus, optionally to selected rules, with a regional cap on concurrent replays.
EventBridge Pipes are point-to-point (one source, one target) with filter, enrichment, and transform—distinct from many-to-many buses.
EventBridge Scheduler is the current scheduling service (one-time and recurring, time zones, flexible windows, universal targets). Scheduled rules on a bus remain as a legacy pattern.
Last updated: October 2026
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 ExamFinch 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.
- Bus Typical producers Who puts events Isolation
- Default AWS services; optional custom PutEvents AWS plus principals you allow Shared with AWS events
- Custom Your applications, other buses Principals allowed by the bus policy Per domain or team
- Partner One SaaS partner event source The partner after association Partner-only ingest
Events are JSON with source , detail-type , detail , time , and account . Maximum event size is 1 MB (raised from 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
Payment SaaS creates a partner event source for HarborCart's account.
HarborCart associates it with a partner event bus payments-saas .
A rule matches detail-type = DisputeCreated and targets the fraud SQS queue in the security account (cross-account target or intermediate bus).
An archive on payments-saas keeps disputes 30 days.
When fraud ships a new classifier, they replay two days of disputes to the new rule only.
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
Putting SaaS partner events on the default bus with a handmade HMAC Lambda and calling that a partner integration.
Expecting replay onto a different bus.
One rule with twelve targets.
Using a bus when the need is SQS-to-Step Functions Pipes .
New cron work on scheduled bus rules when Scheduler is the feature-rich service.
Cross-account with no bus policy.
Treating schema registry as an authorizer.