12.2 EventBridge Event Routing, Patterns & Multi-Account Buses

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:

1. 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).
2. 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.
3. 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

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.

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

1. 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).
2. 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.
3. 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.
4. 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.