AWS Multi-Account Event Notifications: Architecting Centralized Observability

In a complex AWS Organization, monitoring events (security alerts, state changes, or API calls) across hundreds of accounts individually is unmanageable. Centralizing these events into a single "Security" or "Log Archive" account allows for unified response, auditing, and visualization.

Learning Objectives

After studying this guide, you should be able to:

• Design a cross-account event routing architecture using Amazon EventBridge.
• Configure resource-based policies for event buses to allow cross-account PutEvents calls.
• Evaluate the security implications of centralized vs. decentralized event processing.
• Implement event filtering to minimize noise in a centralized monitoring account.

Key Terms & Glossary

• Event Bus: A pipeline that receives events. The default bus exists in every account, but custom buses can be created.
• Event Pattern: A JSON object used to filter events (e.g., "only EC2 Instance State Change events").
• Target: The resource that EventBridge sends an event to when a rule matches (e.g., Lambda, SQS, or another Event Bus).
• Resource-based Policy: A policy attached to an Event Bus that defines which principals (Accounts or Organizations) can send events to it.

The "Big Idea"

[!IMPORTANT] The core philosophy of multi-account event notifications is the "Hub-and-Spoke" model. The spoke accounts act as event producers, while a single hub account acts as the centralized consumer/aggregator. This architecture ensures that security teams have a "single pane of glass" for the entire organization without needing IAM credentials for every individual sub-account.

Formula / Concept Box

Hierarchical Outline

1. Event Source Identification
   • AWS Service Events: Automated state changes (e.g., GuardDuty Findings, EC2 Stop/Start).
   • CloudTrail Integration: Capturing API calls (e.g., StopLogging, DeleteS3Bucket).
2. The Routing Mechanism
   • Sender Configuration: Rules in the source account match specific patterns.
   • Destination Configuration: The Target is set to the ARN of the Event Bus in Account B.
3. Security & Governance
   • IAM Roles: Necessary for EventBridge to invoke the cross-account target.
   • Organization-wide Rules: Using CloudFormation StackSets to deploy rules to all accounts automatically.

Visual Anchors

Multi-Account Event Flow

Logic Architecture

\begin{tikzpicture}[node distance=2cm, every node/.style={draw, rectangle, align=center, minimum height=1cm}] \node (src) {Source Account$Producer)}; \node (rule) [right of=src, xshift=2cm] {Event Rule$Pattern Match)}; \node (bus) [right of=rule, xshift=2cm, fill=gray!20] {Central Event Bus$Hub)}; \node (action) [below of=bus, yshift=-1cm] {Target Action$SNS/Lambda)};

\end{tikzpicture}

Definition-Example Pairs

• Event Pattern Filtering: The process of selecting only relevant data to send across accounts.
  • Example: Instead of sending every S3 API call, a pattern is created to only send DeleteBucket events from a production account to the security account.
• Dead Letter Queue (DLQ): A target used to store events that could not be delivered to the central bus.
  • Example: If the central account's bus policy is misconfigured, the source account rule can send the failed event to an SQS DLQ for later analysis.

Worked Examples

Example 1: Forwarding GuardDuty Findings

Scenario: You want to aggregate all high-severity GuardDuty findings from 50 accounts into a central Security Account.

1. Central Account Setup: Create an Event Bus named OrgEvents. Add a policy:
   jsonCopy

   { "Sid": "AllowAllAccountsFromOrg", "Effect": "Allow", "Principal": "*", "Action": "events:PutEvents", "Resource": "arn:aws:events:us-east-1:111122223333:event-bus/OrgEvents", "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } } }
2. Spoke Account Setup: Create a Rule on the default bus.
   • Pattern: { "source": ["aws.guardduty"], "detail": { "severity": [7, 8] } }
   • Target: arn:aws:events:us-east-1:111122223333:event-bus/OrgEvents
3. Result: Only high-severity findings (7.0+) are routed centrally, saving costs and reducing noise.

Checkpoint Questions

1. What IAM permission must the EventBridge service have in a source account to send events to a central account bus?
2. True or False: Cross-account event routing works automatically for the default bus without any policy changes.
3. How can you restrict a central event bus to only accept events from a specific AWS Organization?

▶Click to see answers

1. events:PutEvents permission (specifically via an IAM Role used by the Rule Target).
2. False. The receiving bus must have a resource-based policy explicitly allowing the source.
3. Use the aws:PrincipalOrgID condition key in the Event Bus resource-based policy.

Muddy Points & Cross-Refs

• Cross-Region vs. Cross-Account: People often confuse these. Cross-account routing is a direct Target option. Cross-region routing is not always direct; you typically send to a bus in the same account/different region, or use an intermediate service like SQS or Kinesis.
• Circular Routing: > [!WARNING] Be careful not to create a rule in the Central Account that sends events back to the Source Account, as this can create an infinite loop and result in a massive AWS bill.
• Quota Limits: Remember that PutEvents has transactions-per-second (TPS) limits. In massive organizations, you may need to request a quota increase for the central bus.

Comparison Tables