This chapter covers Amazon EventBridge rules, event buses, and replay — essential components for building event-driven architectures on AWS. For the SAA-C03 exam, EventBridge appears in roughly 5-8% of questions, often integrated with Lambda, SQS, and Step Functions. You will learn how to create and configure event buses, write event patterns for rules, and use replay to recover from failures. Mastery of these concepts is critical for designing resilient, decoupled systems that respond to state changes across AWS services and custom applications.
Jump to a section
Imagine a large corporate mailroom that handles all incoming and outgoing correspondence for a company with many departments. The mailroom has a main public address (the default event bus) where any external sender can drop mail. Inside, there are several internal mailboxes for specific departments (custom event buses), such as HR, IT, and Finance. Each mailbox has a set of routing rules (rules) that determine what happens to each piece of mail based on its envelope color, stamp type, or return address (event pattern matching). For example, any mail with a red envelope goes to HR, and any mail with a priority stamp goes to the CEO. The mailroom also keeps a carbon copy of every piece of mail for 24 hours (event archive), so if a department loses a letter, the mailroom can replay all mail from a specific time window (replay). This is like having a time machine for events. If a rule is misconfigured, mail might be delivered to the wrong department or lost entirely, but the archive allows recovery. In EventBridge, events are JSON objects, rules filter them based on patterns, and targets (like Lambda, SQS, or Step Functions) are the final recipients. The default bus accepts AWS service events, while custom buses handle your own application events. Replay is only possible if archiving is enabled before the events occur.
What is Amazon EventBridge?
Amazon EventBridge is a serverless event bus service that enables you to build event-driven applications by connecting your own applications, AWS services, and third-party SaaS providers. It acts as a central hub for events, allowing you to define rules that match incoming events and route them to one or more targets for processing. EventBridge evolved from Amazon CloudWatch Events, offering additional features like custom event buses, schema registries, and replay capabilities.
Why EventBridge Exists
Before EventBridge, developers had to build custom event routing logic using SNS, SQS, or Lambda. This led to tightly coupled architectures and increased operational overhead. EventBridge provides a fully managed, scalable, and highly available event bus with built-in filtering, transformation, and delivery. It decouples event producers from consumers, allowing each to evolve independently. The SAA-C03 exam tests your ability to choose EventBridge over alternatives like SNS or SQS for scenarios requiring complex event filtering, multiple targets per rule, or replay.
How EventBridge Works Internally
EventBridge operates on a publish-subscribe model. An event producer publishes an event to an event bus. The event bus contains rules that evaluate each event against defined event patterns. If an event matches a rule's pattern, the rule triggers one or more targets. Targets are AWS resources that can process the event, such as Lambda functions, SQS queues, SNS topics, Step Functions state machines, Kinesis streams, or API Gateway endpoints. EventBridge can also invoke targets in other AWS accounts via cross-account event buses.
Event Structure
An event in EventBridge is a JSON object with a specific structure. The following fields are required: - version: The version of the event format (currently "0"). - id: A globally unique identifier for the event. - detail-type: A string that describes the type of event (e.g., "EC2 Instance State-change Notification"). - source: A string that identifies the service that generated the event (e.g., "aws.ec2"). - account: The AWS account ID where the event originated. - time: The timestamp when the event occurred (ISO 8601 format). - region: The AWS region where the event originated. - resources: An array of ARNs (Amazon Resource Names) identifying affected resources. - detail: A JSON object containing the event-specific data. The structure of the detail field varies by source.
Example event:
{
"version": "0",
"id": "6a7e8f9b-1c2d-3e4f-5a6b-7c8d9e0f1a2b",
"detail-type": "EC2 Instance State-change Notification",
"source": "aws.ec2",
"account": "123456789012",
"time": "2023-01-15T10:30:00Z",
"region": "us-east-1",
"resources": ["arn:aws:ec2:us-east-1:123456789012:instance/i-0abcd1234efgh5678"],
"detail": {
"instance-id": "i-0abcd1234efgh5678",
"state": "running"
}
}Event Buses
An event bus is a logical entity that receives events from sources. There are three types: - Default event bus: Automatically created in every AWS account. It receives events from AWS services (e.g., EC2, S3, CloudTrail) and can also receive custom application events. AWS service events are automatically sent to the default bus unless you configure a different bus. - Custom event bus: Created by you to isolate events from specific applications or environments. For example, you might have a custom bus for your payment processing application and another for your inventory system. Custom buses can receive events from your own applications, AWS services (if you configure them), and other AWS accounts. - Partner event bus: Used to receive events from SaaS partners (e.g., Datadog, PagerDuty, Shopify) that have integrated with EventBridge. Partner buses are created when you configure a partner event source.
Rules
A rule is a set of conditions (event pattern) that determines which events are routed to which targets. Each rule belongs to a single event bus. Key properties: - Event pattern: A JSON object that defines the matching criteria. Patterns can match on any field in the event, including nested fields in the detail object. Patterns support exact matching, prefix matching, suffix matching, numeric comparison, and existence checks. You can also use "anything-but" and "exists" operators. Patterns can be combined with logical AND (by specifying multiple fields) and OR (by using arrays for a field's value). - Targets: An array of up to 5 targets per rule. Each target specifies an ARN and optional input transformation, dead-letter configuration, and retry policy. - State: Rules are enabled or disabled. Disabled rules do not evaluate events. - Event bus: The bus the rule belongs to.
Event Pattern Examples
Match all EC2 instance state change events:
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"]
}Match only when instance stops:
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"],
"detail": {
"state": ["stopped"]
}
}Match events from multiple sources:
{
"source": ["aws.ec2", "aws.autoscaling"]
}Match using prefix:
{
"detail": {
"state": [{"prefix": "run"}]
}
}Targets and Retry Policy
Each target can have: - Retry policy: Defines the number of retries (0-185) and the maximum event age (1-86400 seconds). Default is 24 retries over 24 hours. - Dead-letter queue (DLQ): An SQS queue where events that fail to be delivered after all retries are sent. This prevents event loss. DLQ is optional but recommended for production. - Input transformer: Allows you to modify the event before sending it to the target. You can extract fields from the original event and create a new JSON payload or even a text string.
Cross-Account Event Buses
EventBridge supports cross-account event delivery. You can create a rule on a custom event bus in Account A that targets a resource in Account B. To do this, you must: 1. Create a custom event bus in Account B. 2. In Account A, create a rule on a custom bus that targets the event bus ARN in Account B. 3. In Account B, create a resource-based policy on the custom bus that allows Account A to put events.
Cross-account rules are useful for centralized logging or triggering actions in multiple accounts from a single event source.
Replay
EventBridge replay allows you to reprocess historical events from a specified time window. To use replay, you must have an event archive enabled on the event bus. Key facts: - Event archive: Captures all events sent to a bus. You can set a retention period from 1 hour to 365 days. Archiving is charged based on the volume of events stored. - Replay: You can replay events from a specific time range (start time to end time) within the archive's retention period. You specify the target event bus and optionally filter events using an event pattern (only matching events are replayed). The replayed events are treated as new events; they are not duplicates of the originals. Replay is useful for testing, debugging, or recovering from failures. - Limitations: Replay cannot replay events that were archived before you enabled the archive. Replay does not guarantee exactly-once delivery; targets should be idempotent. Replay can take minutes to hours depending on the number of events.
Interaction with Other Services
EventBridge integrates deeply with many AWS services: - Lambda: The most common target. EventBridge can invoke Lambda functions synchronously or asynchronously. - SQS: Events can be sent to an SQS queue for decoupled processing. - SNS: Events can be sent to an SNS topic for fan-out to multiple subscribers. - Step Functions: Events can start a state machine execution. - Kinesis: Events can be sent to a Kinesis stream for real-time analytics. - CloudWatch Logs: Events can be sent to a log group for auditing. - API Gateway: Events can invoke an API Gateway endpoint.
Configuration Commands (AWS CLI)
Create a custom event bus:
aws events create-event-bus --name my-custom-busCreate a rule:
aws events put-rule --name my-rule --event-bus-name my-custom-bus --event-pattern '{"source":["myapp"]}'Add a target:
aws events put-targets --rule my-rule --event-bus-name my-custom-bus --targets '{"Id":"1","Arn":"arn:aws:lambda:us-east-1:123456789012:function:my-function"}'Enable archiving:
aws events create-archive --archive-name my-archive --event-source-arn arn:aws:events:us-east-1:123456789012:event-bus/default --retention-days 30Start a replay:
aws events start-replay --replay-name my-replay --event-source-arn arn:aws:events:us-east-1:123456789012:event-bus/default --destination arn:aws:events:us-east-1:123456789012:event-bus/default --event-start-time "2023-01-01T00:00:00Z" --event-end-time "2023-01-01T01:00:00Z"Default Values and Timers
Maximum event size: 256 KB
Maximum number of rules per event bus: 100 (default) but can be increased via service quota
Maximum number of targets per rule: 5
Maximum retries: 185 (default 24)
Maximum event age for retries: 86400 seconds (24 hours)
Archive retention: 1 hour to 365 days
Replay time window: must be within archive retention period
EventBridge SLA: 99.99% availability for event buses
How EventBridge Differs from CloudWatch Events
EventBridge is the successor to CloudWatch Events. While CloudWatch Events is still available, EventBridge offers additional features:
- Custom event buses - Partner event sources - Schema registry - Replay - Input transformers (more powerful) - Cross-account event buses For the exam, assume you should use EventBridge for new architectures, but be aware that CloudWatch Events may appear in legacy questions.
Create a Custom Event Bus
Start by creating a custom event bus for your application. In the AWS Management Console, navigate to EventBridge, choose 'Event buses', and click 'Create event bus'. Enter a name (e.g., 'my-app-bus'). Optionally, add a resource-based policy to allow other accounts to send events to this bus. The bus is now ready to receive events. You can also use the AWS CLI: `aws events create-event-bus --name my-app-bus`. Each custom bus is isolated from others, so events from different applications don't mix. The default bus is automatically created and receives AWS service events.
Define an Event Pattern in a Rule
Create a rule on the custom bus to filter incoming events. In the console, go to 'Rules', click 'Create rule', select the custom bus, and enter a name. In the 'Event pattern' section, choose 'Custom pattern' and paste a JSON pattern. For example, to match events where 'source' is 'myapp' and 'detail.status' is 'error', use: `{"source":["myapp"],"detail":{"status":["error"]}}`. EventBridge will evaluate each event against this pattern. Only events that match will trigger the rule's targets. Patterns can include exact matches, prefix/suffix, numeric ranges, and logical OR (using arrays).
Configure Targets and Retry Policy
In the same rule, add one or more targets. Choose a target type (e.g., Lambda function) and select the specific resource. Optionally, configure input transformation to modify the event payload before sending. Set a retry policy: number of retries (0-185) and maximum event age (1-86400 seconds). For critical events, enable a dead-letter queue (SQS) to capture failed deliveries. Each target must have a unique ID within the rule. You can add up to 5 targets per rule. Save the rule; it will be enabled by default.
Enable Event Archiving
To use replay, create an event archive for the bus. In the console, go to 'Archives', click 'Create archive', select the event bus, enter an archive name, and set retention days (e.g., 30). The archive captures all events sent to the bus. You can also filter events to archive only specific ones using an event pattern. Archiving is charged per GB of events stored. Once created, the archive immediately starts capturing events. Without an archive, replay is not possible. Note that events that occurred before creating the archive cannot be replayed.
Replay Historical Events
To replay events, go to 'Replays' in the console, click 'Create replay', select the event source (the archive), set the time window (start and end time), choose the destination event bus (can be the same or different), and optionally add an event pattern to filter which events to replay. Click 'Start replay'. EventBridge will re-publish matching events to the destination bus. The replayed events have new event IDs and are processed like new events. Replay can take time; you can monitor its status. Use replay for testing rule changes or recovering from processing failures.
Enterprise Scenario 1: Centralized Security Event Monitoring
A large enterprise with multiple AWS accounts wants to centralize security events (e.g., CloudTrail API calls, GuardDuty findings) into a single account for analysis. They create a custom event bus in the central security account. In each member account, they create a rule on the default bus that matches security-related events (e.g., source: aws.cloudtrail) and sends them to the central bus using a cross-account target. The central account has a rule that sends all events to a Lambda function that logs them to a security information and event management (SIEM) system. They also enable archiving on the central bus with a 90-day retention for compliance. If the SIEM system goes down, they can replay events from the archive once it's back up. Common pitfalls: forgetting to set resource-based policies on the central bus to allow member accounts to put events, and not using a dead-letter queue for failed deliveries.
Enterprise Scenario 2: E-commerce Order Processing
An e-commerce platform uses a custom event bus for order events (order_placed, payment_received, shipment_created). Each event type triggers different workflows. For example, 'order_placed' events are sent to a Step Functions state machine that orchestrates inventory check, payment processing, and shipping. 'payment_received' events update a DynamoDB table. They use input transformers to add order metadata. To handle peak traffic (Black Friday), they rely on EventBridge's automatic scaling. They also enable archiving for 7 days to replay events if a downstream service fails. During a deployment, a misconfigured rule accidentally sent 'order_placed' events to a test Lambda, causing duplicate orders. They fixed the rule and replayed the affected events from the archive to the correct target. Lesson: always test rules in a staging environment and use dead-letter queues.
Scenario 3: SaaS Integration with Partner Events
A company uses Datadog for monitoring. They configure a partner event source in EventBridge to receive Datadog alerts. A rule on the partner bus matches high-severity alerts and triggers an SNS topic that sends SMS to on-call engineers. They also archive partner events for 30 days. When Datadog had an outage, they missed some alerts. After recovery, they replayed the missed alerts from the archive. This required that archiving was enabled before the outage. Common mistake: assuming partner events are automatically archived; you must explicitly create an archive on the partner bus.
What the SAA-C03 Tests
EventBridge is tested under Objective 2.1: 'Design highly available and/or fault-tolerant architectures'. Specific areas:
Identify when to use EventBridge vs. SNS or SQS for event routing.
Understand event bus types: default, custom, partner.
Know how to write event patterns for filtering.
Understand replay and archiving for fault tolerance.
Cross-account event delivery.
Retry policies and dead-letter queues.
Common Wrong Answers and Why
Choosing SNS over EventBridge for complex filtering: SNS only supports subscription filter policies based on message attributes, not deep JSON pattern matching. EventBridge allows complex patterns on the entire event body. Candidates often pick SNS because they think it's simpler, but the exam expects EventBridge for sophisticated filtering.
Using CloudWatch Events instead of EventBridge: CloudWatch Events is legacy. EventBridge offers custom buses, replay, and partner integrations. The exam will present scenarios requiring these features; candidates who choose CloudWatch Events will be wrong.
Assuming replay is always available: Replay requires an event archive that was created before the events occurred. A common trap: a question describes a failure and asks how to reprocess events. The incorrect answer suggests using replay without mentioning archiving. The correct answer will include enabling archiving first.
Thinking rules can have multiple event patterns: Each rule has exactly one event pattern. To match multiple patterns, you must create multiple rules. Candidates may think they can add multiple patterns in one rule, but that's not supported.
Specific Numbers and Terms
Maximum 5 targets per rule.
Maximum 185 retries; default 24.
Maximum event age for retries: 86400 seconds.
Archive retention: 1 hour to 365 days.
Event size limit: 256 KB.
Key terms: event pattern, detail-type, source, input transformer, dead-letter queue, replay, archive.
Edge Cases and Exceptions
Cross-account events: The target must be an event bus in another account; you cannot directly target a Lambda in another account. You must target the event bus, and then a rule in that account triggers the Lambda.
Replay idempotency: Since replay can deliver duplicate events, targets must be idempotent. The exam may ask how to handle duplicates; answer: use idempotent logic or deduplication IDs.
Input transformers: They can only transform the event payload; they cannot change the target ARN. To route to different targets based on event content, use multiple rules with different patterns.
How to Eliminate Wrong Answers
If a scenario requires filtering on nested JSON fields, eliminate SNS and SQS (they only support attribute-based filtering).
If the scenario needs to reprocess events from the past, look for 'archive' and 'replay' in the answer. Eliminate options that suggest manual reprocessing or Lambda retries.
If the scenario involves SaaS integration, look for 'partner event bus'. Eliminate options that suggest custom bus with manual polling.
If the scenario requires decoupling with multiple consumers, EventBridge can fan out to multiple targets per rule, but SNS is also an option. The differentiating factor is filtering capability.
EventBridge has three bus types: default, custom, and partner.
Rules have one event pattern and up to 5 targets.
Event patterns support exact match, prefix, suffix, numeric, and existence checks.
Replay requires an event archive enabled before the events occur.
Archive retention: 1 hour to 365 days.
Maximum retries: 185; default 24; max event age: 86400 seconds.
Event size limit: 256 KB.
For cross-account delivery, target an event bus in the other account, not a Lambda directly.
These come up on the exam all the time. Here's how to tell them apart.
Amazon EventBridge
Supports complex JSON event pattern matching on the entire event body.
Can have up to 5 targets per rule with different retry policies.
Supports replay of historical events with archiving.
Integrates with SaaS partners via partner event buses.
Supports cross-account event delivery via event bus policies.
Amazon SNS
Filtering is limited to message attributes (not body).
Fan-out to many subscribers (unlimited) via topics.
No built-in replay; messages are pushed and not stored.
No native SaaS integration; requires custom integration.
Cross-account delivery via topic policies, but less flexible.
Mistake
EventBridge can replace SQS for decoupling.
Correct
EventBridge is for event routing with filtering, not for message queuing. It does not store events after delivery (unless archived). For durable, persistent message storage, use SQS. EventBridge can send events to SQS for decoupling.
Mistake
All AWS service events go to the default bus automatically.
Correct
Most AWS services send events to the default bus, but some services (like CloudTrail) require you to create a trail to deliver events. Also, you can configure services to send events to a custom bus.
Mistake
Replay guarantees exactly-once delivery.
Correct
Replay does not guarantee exactly-once. Events may be delivered more than once. Targets should be idempotent to handle duplicates.
Mistake
You can have up to 10 targets per rule.
Correct
The limit is 5 targets per rule. To send to more targets, create additional rules with the same pattern.
Mistake
Event patterns can include regular expressions.
Correct
Event patterns do not support regex. They support exact match, prefix, suffix, numeric comparison, and existence checks. For complex matching, use a Lambda function as a target to perform custom logic.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
EventBridge is the successor to CloudWatch Events. It offers additional features: custom event buses, partner event sources, schema registry, replay, and more powerful input transformers. CloudWatch Events is still available but considered legacy. For new architectures, use EventBridge. The exam may still reference CloudWatch Events in older scenarios, but prefer EventBridge.
Yes, via cross-account event buses. You create a rule on a custom bus in Account A that targets a custom event bus in Account B. Account B must have a resource-based policy allowing Account A to put events. You cannot directly target a Lambda in another account; you must target the event bus, then a rule in Account B triggers the Lambda.
Configure a dead-letter queue (DLQ) on the target. The DLQ is an SQS queue that receives events that failed delivery after all retries. Also, enable event archiving on the bus so you can replay events later. For critical events, set a high retry count and use DLQ.
EventBridge rejects events larger than 256 KB. The event is not delivered. To handle large payloads, consider storing the payload in S3 and sending a reference (e.g., S3 key) in the event.
No. Replay only works for events that were captured in an archive. You must create the archive before the events occur. Events that happened before archive creation cannot be replayed.
The default quota is 100 rules per event bus. You can request a quota increase via AWS Support. Each rule can have up to 5 targets.
Input transformation allows you to modify the event payload before sending it to the target. You can extract fields, create new JSON structures, or convert to plain text. This is useful when the target expects a specific format.
You've just covered EventBridge Rules, Event Buses, and Replay — now see how well it sticks with free SAA-C03 practice questions. Full explanations included, no account needed.
Done with this chapter?