ExamFinch.com My Study

Study guide

12.2 EventBridge Event Routing, Patterns & Multi-Account Buses

Practice this exam

AWS Certified DevOps Engineer – Professional Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: CI/CD Pipeline Architecture & Source Integration

1.1 Multi-Stage & Multi-Account CodePipeline Design 1.2 CodeBuild Projects, Build Environments & Pipeline Secrets 1.3 Source Control Workflows, Webhooks & Branching Models

2 Chapter 2: Automated Testing, Test Gates & Quality Verification

2.1 Automated Unit, Integration & Acceptance Testing in Pipelines 2.2 Load Testing, Performance Benchmarking & Synthetic Canaries 2.3 Security Scanning, SAST/DAST & Approval Gates

3 Chapter 3: Artifact Management & Multi-Platform Deployment Strategies

3.1 Artifact Lifecycle Management with CodeArtifact, ECR & S3 3.2 Automated Image Baking with EC2 Image Builder 3.3 In-Place, Rolling & Immutable Deployments on EC2 3.4 Blue/Green & Canary Deployments for ECS, EKS & Lambda

4 Chapter 4: CloudFormation, CDK & Reusable IaC Components

4.1 Advanced CloudFormation: Nested Stacks, Change Sets & Custom Resources 4.2 Cross-Account & Multi-Region StackSets & Drift Detection 4.3 Modern IaC: AWS CDK, SAM & Service Catalog Governance

5 Chapter 5: Multi-Account Architecture, Organizations & Control Tower

5.1 AWS Organizations Hierarchy, OUs & Account Provisioning 5.2 Service Control Policies (SCPs) & Multi-Account Guardrails 5.3 AWS Control Tower, Account Factory & Landing Zone Automation

6 Chapter 6: Systems Manager & Large-Scale Fleet Configuration

6.1 SSM Agent, Hybrid Activation & Session Manager 6.2 Systems Manager Run Command, State Manager & Associations 6.3 Patch Manager, Parameter Store vs Secrets Manager & AppConfig

7 Chapter 7: High Availability & Multi-Region Resiliency

7.1 Designing Resilient Multi-AZ & Multi-Region Architectures 7.2 Route 53 Traffic Flow, Health Checks & DNS Failover 7.3 Data Replication: Aurora Global DB, DynamoDB Global Tables & S3 CRR

8 Chapter 8: Scalability, Auto Scaling & Disaster Recovery Automation

8.1 EC2 Auto Scaling Policies, Lifecycle Hooks & Warm Pools 8.2 Container & Serverless Scalability: ECS Capacity Providers, EKS & API Gateway 8.3 Disaster Recovery Strategies: RTO, RPO & Architecture Tiers 8.4 Automated Backup & Recovery with AWS Backup & Elastic Disaster Recovery

9 Chapter 9: CloudWatch Metrics, Agent Collection & Log Aggregation

9.1 CloudWatch Metrics, Dimensions, Metric Math & High Resolution 9.2 Unified CloudWatch Agent & Custom Metric Collection 9.3 Centralized Log Aggregation, Retention & Cross-Account Subscriptions

10 Chapter 10: Log Analysis, Dashboards & Distributed Tracing with X-Ray

10.1 CloudWatch Logs Insights, Filter Syntax & Query Optimization 10.2 CloudWatch Dashboards, Composite Alarms & Anomaly Detection 10.3 Distributed Tracing with AWS X-Ray & Service Maps

11 Chapter 11: Automated Observability & Event-Driven Monitoring

11.1 Application & Infrastructure Health Checks with Route 53 & ALB 11.2 Centralized Observability with Amazon OpenSearch & Athena 11.3 Synthetic Monitoring with CloudWatch Synthetics Canaries

12 Chapter 12: Event-Driven Incident Detection & Notification Pipelines

12.1 AWS Health, CloudTrail Events & Operational Notification 12.2 EventBridge Event Routing, Patterns & Multi-Account Buses 12.3 Asynchronous Event Processing: SNS, SQS Queues & Dead-Letter Handling

13 Chapter 13: Automated Remediation & Deployment Troubleshooting

13.1 AWS Config Managed Rules & Automated Remediation with SSM 13.2 Event-Driven Infrastructure Self-Healing with Lambda & Step Functions 13.3 Troubleshooting CI/CD Pipeline & Deployment Failures 13.4 Root Cause Analysis for Auto Scaling & Container Failures

14 Chapter 14: Identity, Access Management & Secrets at Scale

14.1 IAM Policy Evaluation Logic, NotAction & Explicit Denies 14.2 IAM Permissions Boundaries & Delegated Administration 14.3 IAM Identity Center, Cross-Account Roles & STS Session Policies 14.4 Automated Secrets Management & Secret Rotation with Secrets Manager

15 Chapter 15: Security Automation, Data Protection & Compliance Auditing

15.1 Network Security Automation: Security Groups, NACLs, Network Firewall & WAF 15.2 Cryptographic Controls & Key Management with AWS KMS & ACM 15.3 Automated Threat Detection: GuardDuty, Inspector & Security Hub 15.4 Continuous Compliance Auditing & Log Integrity with CloudTrail & Config

12.2 EventBridge Event Routing, Patterns & Multi-Account Buses

Key Takeaways Explain This Topic AI

Amazon EventBridge segregates event streams into Default buses (AWS services), Custom buses (internal application microservices), and Partner buses (integrated third-party SaaS platforms like Datadog, PagerDuty, and Auth0).

EventBridge rules evaluate JSON envelopes using sophisticated pattern-matching operators including prefix, suffix, wildcards, numeric ranges, existence checks, CIDR matching, and anything-but logic.

EventBridge Archive and Replay allows long-term event persistence and non-destructive point-in-time event replay to recover from downstream consumer outages or application bugs without manual data reconstruction.

Cross-account event routing requires configuring resource-based event bus policies (PutPermission) on the central event bus and IAM execution roles with events:PutEvents permissions in member sender accounts.

EventBridge Pipes establishes high-performance point-to-point integrations between streaming/queuing sources (SQS, Kinesis, DynamoDB Streams) and targets with optional event pattern filtering and enrichment stages.

Last updated: September 2026

Amazon EventBridge Architecture: Event Buses & Schemas

Amazon EventBridge is a serverless, highly scalable event bus that ingests, filters, transforms, and routes real-time streaming data from AWS services, proprietary microservices, and external software-as-a-service (SaaS) providers. Mastering EventBridge topology and rule mechanics is essential for multi-account governance on the DOP-C02 exam.

Event Bus Topologies

EventBridge organizes event streams across three distinct bus classifications:

Default Event Bus : Automatically provisioned in every AWS account and region. It is the exclusive recipient of native AWS service events (e.g., EC2 state changes, Auto Scaling lifecycle transitions, GuardDuty findings, CodePipeline stage changes, and CloudTrail management API calls).

Custom Event Buses : Created by cloud engineers to handle proprietary application events across microservices (e.g., OrderProcessingBus , PaymentGatewayBus ). Custom buses isolate application traffic from raw AWS service telemetry, simplifying security boundaries and billing allocation.

Partner Event Buses : Ingests real-time events from authorized third-party SaaS partners (such as Datadog, PagerDuty, Auth0, Shopify, Zendesk, and MongoDB Atlas). An AWS partner provisions a Partner Event Source , which the AWS customer associates with a dedicated partner event bus in their account.

The Canonical JSON Event Envelope Schema

Every event passing through EventBridge conforms to a standardized top-level JSON structure known as the Event Envelope . Downstream rules match against envelope metadata as well as nested fields within the detail object: {

  • "version": "0",
  • "id": "c6af9ac6-b621-421e-ad6f-d9f75d65421b",
  • "detail-type": "EC2 Instance State-change Notification",
  • "source": "aws.ec2",
  • "account": "111122223333",
  • "time": "2026-09-11T16:15:30Z",
  • "region": "us-east-1",
  • "resources": [
  • "arn:aws:ec2:us-east-1:111122223333:instance/i-0123456789abcdef0"
  • ],
  • "detail": {
  • "instance-id": "i-0123456789abcdef0",
  • "state": "shutting-down"
  • }
  • }

source : Identifies the service or system that emitted the event. AWS services use the aws. prefix (e.g., aws.ec2 , aws.guardduty ). For custom applications, use reverse domain-name notation (e.g., com.corp.ecommerce.checkout ).

detail-type : Identifies the specific type and schema of the event (e.g., OrderCreated , PaymentFailed ).

detail : A free-form JSON object containing the application-specific or service-specific event payload.

Advanced Event Pattern Matching Syntax

EventBridge rules evaluate incoming events using declarative JSON pattern filters. If an event matches the pattern, EventBridge routes the payload to up to five configured targets per rule. Pattern matching is strictly case-sensitive and evaluates values as arrays (logical OR within an array; logical AND across distinct keys).

Pattern Matching Operators

  • Pattern Operator Syntax Example Evaluation Behavior
  • Exact Match "state": ["RUNNING", "PENDING"] Matches if the field equals any value in the array
  • Prefix Match "source": [{"prefix": "aws."}] Matches if the string starts with the defined prefix
  • Suffix Match "key": [{"suffix": ".json"}] Matches if the string ends with the specified suffix
  • Wildcard Match "repo": [{"wildcard": "production/*-api"}] Matches using * wildcards across the string

Numeric Range "amount": [{"numeric": [">=", 100, "<", 500]}] Matches numeric values within defined range boundaries

  • Exists Match "securityTag": [{"exists": true}] Matches if the JSON key is present in the payload
  • Anything-But "status": [{"anything-but": ["TERMINATED"]}] Matches any value except the listed values

Anything-But (Prefix) "arn": [{"anything-but": {"prefix": "arn:aws:iam::"}}] Matches values that do not begin with the prefix

  • Null Match "cancellationReason": [null] Matches if the key exists and its value is explicitly null
  • CIDR Match "ip": [{"cidr": "10.200.0.0/16"}] Matches IPv4 or IPv6 addresses inside the network block
  • Comprehensive Event Rule Pattern Example

The following production-grade rule matches high-value financial orders originating from specific enterprise CIDR ranges that do not originate from testing environments: {

  • "source": ["com.corp.ecommerce"],
  • "detail-type": ["OrderPlaced"],
  • "detail": {
  • "environment": [{
  • "anything-but": ["test", "sandbox", "dev"]
  • }],
  • "orderValue": [{
  • "numeric": [">=", 1000.00]
  • }],
  • "clientIp": [{
  • "cidr": "192.168.10.0/24"
  • }],
  • "customerMetadata": {
  • "taxId": [{
  • "exists": true
  • }]
  • }
  • }
  • }
  • EventBridge Archive & Replay

In distributed microservices, downstream consumers may experience catastrophic outages (e.g., relational database deadlocks, network partitions, or bad application deployments that cause unhandled exceptions). During such outages, events sent to an event bus may be lost or rejected if dead-letter queues are misconfigured or exhausted.

EventBridge Archive and Replay provides native, non-destructive resilience:

Archive Configuration : An archive can be attached to any event bus. It stores copies of all events (or a subset defined by an optional event pattern filter) passing through the bus.

Retention Policy : Event retention can be configured for a specific window from 1 to 2,147,483,647 days , or set to 0 for indefinite retention .

Replay Execution : Once downstream bugs are resolved, an engineer initiates a replay specifying the archive ARN, target event bus, and an exact time window (start time and end time): aws events start-replay \

  • -replay-name PaymentRecoveryReplay \
  • -event-source-arn arn:aws:events:us-east-1:123456789012:archive/PaymentArchive \
  • -destination '{"Arn":"arn:aws:events:us-east-1:123456789012:event-bus/PaymentBus"}' \
  • -event-start-time "2026-09-11T08:00:00Z" \
  • -event-end-time "2026-09-11T11:00:00Z"

Tip

Loop Prevention during Replay : Replayed events contain an identical top-level envelope, but EventBridge automatically injects a metadata field: "replay-name": "PaymentRecoveryReplay" . Downstream consumers and EventBridge rules can check for the presence or absence of the replay-name field to prevent recursive loops or trigger specialized reprocessing logic.

Loading diagram... Multi-Account EventBridge Routing and EventBridge Pipes Architecture

Cross-Account & Cross-Region Event Routing

In enterprise AWS Organizations architectures (e.g., AWS Control Tower environments), best practices dictate establishing a centralized Security/Operations Account that acts as the hub for all operational telemetry, compliance alerts, and incident responses.

Hub-and-Spoke Configuration Mechanics

Cross-account routing requires two independent configuration components: the receiver bus policy and the sender forwarding rule.

1. Central Hub Account Configuration (Receiver)

The central account hosts a custom event bus (e.g., CentralSecOpsBus ). A resource-based policy must be attached to the bus granting permission to invoke events:PutEvents . To allow all existing and future member accounts in the organization to forward events without manual policy edits, scope access using the aws:PrincipalOrgID condition key: {

  • "Version": "2012-10-17",
  • "Statement": [
  • {
  • "Sid": "AllowOrganizationToPutEvents",
  • "Effect": "Allow",
  • "Principal": "*",
  • "Action": "events:PutEvents",
  • "Resource": "arn:aws:events:us-east-1:999988887777:event-bus/CentralSecOpsBus",
  • "Condition": {
  • "StringEquals": {
  • "aws:PrincipalOrgID": "o-abcdef1234"
  • }
  • }
  • }
  • ]
  • }
  • 2. Spoke Member Account Configuration (Sender)

In each member account, an EventBridge rule is created on the default bus matching the target events (e.g., GuardDuty findings or AWS Health events). The rule targets the ARN of the central event bus in the central account:

Target ARN : arn:aws:events:us-east-1:999988887777:event-bus/CentralSecOpsBus

IAM Execution Role : EventBridge in the sender account must be granted an IAM role allowing events:PutEvents on the central bus ARN: {

  • "Version": "2012-10-17",
  • "Statement": [
  • {
  • "Effect": "Allow",
  • "Action": "events:PutEvents",
  • "Resource": "arn:aws:events:us-east-1:999988887777:event-bus/CentralSecOpsBus"
  • }
  • ]
  • }
  • 3. Cross-Region Routing

EventBridge rules can route events across different AWS regions (e.g., from eu-west-1 to us-east-1 ). The target in the destination region must always be an event bus (either the default bus or a custom bus in the destination region). Direct cross-region delivery to targets like AWS Lambda, Amazon SQS, or Amazon SNS is not supported; events must land on an event bus in the destination region, which then routes locally.

EventBridge Pipes: Point-to-Point Integration

While EventBridge Event Buses implement a many-to-many publish/subscribe paradigm, Amazon EventBridge Pipes establishes a dedicated point-to-point integration mechanism connecting event producers directly to event consumers. Source (SQS / DynamoDB Streams / Kinesis / Kafka)

  • ──> [ Filter (Pattern Match) ]
  • ──> [ Enrichment (Lambda / Step Functions / API Destination) ]
  • ──> [ Target (SQS / SNS / Event Bus / Step Functions) ]
  • The Four Stages of an EventBridge Pipe

Source : Ingests records from streaming and queuing sources: Amazon SQS, Amazon Kinesis Data Streams, Amazon DynamoDB Streams, Apache Kafka (Amazon MSK or self-managed), and Amazon MQ (ActiveMQ or RabbitMQ).

Filter : Evaluates incoming records against event patterns. Records that do not match the filter are discarded immediately. Filtered records incur zero cost in downstream enrichment or target stages , drastically reducing unnecessary Lambda compute invocations.

Enrichment (Optional) : Transforms, augments, or validates the event before target delivery using AWS Lambda, AWS Step Functions, API Destinations (external HTTP/REST endpoints), or Amazon API Gateway.

Target : Delivers the final enriched payload to any supported EventBridge target, including Amazon SQS, Amazon SNS, EventBridge Event Buses, AWS Step Functions, CloudWatch Logs, or Kinesis Firehose.

Architectural Benefits on DOP-C02

EventBridge Pipes eliminates the need to author, deploy, and maintain custom "glue-code" Lambda functions whose sole purpose is polling an SQS queue or DynamoDB stream, calling an external HTTP API, and pushing the record to an event bus. EventBridge Pipes provides managed batching windows, concurrency controls, partial batch failure reporting ( ReportBatchItemFailures ), and automatic Dead-Letter Queue (DLQ) routing natively.