Solving EventBridge Cross-Account Event Challenges in AWS Organizations

Solving EventBridge Cross-Account Event Challenges in AWS Organizations

TL;DR: Cross-account EventBridge event delivery in AWS Organizations requires careful configuration of permissions, resource policies, and understanding of organizational trails vs. EventBridge capabilities. This deep dive explains common issues and provides practical solutions for enterprise multi-account architectures.

The Challenge: When EventBridge Events Don't Cross Account Boundaries

A common scenario many AWS architects encounter involves setting up event-driven architectures across multiple accounts within an AWS Organization. Picture this: you have several organizational units (OUs), some using AWS Control Tower while others were dropped from centralized management. You're trying to get EventBridge to read events from all accounts within the organization using a centralized rule in a management account, but events seem to get lost in transit.

This challenge touches on a fundamental misunderstanding about how AWS Organizations, CloudTrail organizational trails, and EventBridge cross-account capabilities actually work together—and more importantly, where they don't.

Understanding the Core Problem

The default event bus accepts events from AWS services, other authorized AWS accounts, and PutEvents calls. The permissions for an event bus are granted or denied using a resource-based policy attached to the event bus. However, simply having an organizational trail doesn't automatically make all events available to EventBridge rules in a central account.

The confusion often stems from assuming that organization trails log events for the management account and all member accounts in the organization means those events are automatically accessible to EventBridge in the management account. This isn't the case—organizational trails and EventBridge operate on different principles.

The Architecture Reality Check

What Organizational Trails Actually Do

An organization trail is a configuration that enables delivery of CloudTrail events in the management account and all member accounts in an AWS Organizations organization to the same Amazon S3 bucket, CloudWatch Logs, and Amazon EventBridge. Note the critical detail here: events are delivered to EventBridge in each account, not centralized to one EventBridge instance.

The EventBridge Cross-Account Limitation

Here's where many architects hit a wall: You cannot have events transitively routed to a third bus (local -> global -> local). Only one cross-account target is allowed in the chain (global -> local). This means you can't simply create a rule in the management account that magically receives all events from member accounts through organizational trail inheritance.

Solution Patterns for Cross-Account EventBridge

Pattern 1: Hub-and-Spoke with Explicit Event Forwarding

The most robust solution involves creating a dedicated event hub architecture:

Central Account Setup:
Create a custom EventBridge bus in your central account (often the management account or a dedicated security/operations account)
Grant additional permissions to an event bus by attaching a resource-based policy to it that allows your organization to send events

Resource Policy Example: 

JSON

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowOrganizationToPutEvents",
    "Effect": "Allow",
    "Principal": "*",
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:region:central-account:event-bus/org-events-hub",
    "Condition": {
      "StringEquals": {
        "aws:PrincipalOrgID": "o-your-org-id"
      }
    }
  }]
} 

Member Account Setup: Each member account needs rules that forward specific events to the central bus. On the sender account, set up one or more rules that have the receiver account's event bus as the target.

Pattern 2: Direct Cross-Account Targets (New Capability)

AWS recently introduced cross-account targets for Amazon EventBridge Event Buses, which allows you to deliver events directly to targets in different accounts without requiring an intermediate event bus.

This pattern works well when you want to send events from multiple accounts to centralized targets like SQS queues or Lambda functions in a security account.

Setup Requirements:

• Source event bus rules must have an AWS Identity and Access Management (IAM) role that allows them to send events to specific targets
• Target resources need resource policies allowing the source account's execution role

Pattern 3: Centralized EventBridge with CloudWatch Integration

For comprehensive monitoring across your organization, you can combine EventBridge with CloudWatch:

By sending specific events from an AWS account to an EventBridge event bus in another AWS account, you can quickly determine the impact by seeing how many accounts and which services are impacted by an incident.

Common Troubleshooting Scenarios

Issue 1: Events Not Appearing in Central Account

Root Cause: Missing resource policies or incorrect IAM permissions

Diagnostic Steps:

1. Check EventBridge metrics: EventBridge publishes an event across accounts only when the source account initiates an event rule and invokes the target
2. Verify the TriggeredRules metric in source accounts
3. Check FailedInvocations metrics for permission issues

Solution: Ensure both resource policies on the target event bus and IAM roles on source rules are correctly configured.

Issue 2: Organizational Trail Events Not Reaching EventBridge Rules

Root Cause: Misunderstanding of how organizational trails work with EventBridge

Reality Check: Regardless of whether a trail is multi-Region or single-Region, events sent to Amazon EventBridge are received in each Region's event bus, rather than in one single event bus.

Solution: Create forwarding rules in each member account rather than expecting automatic centralization.

Issue 3: Events Lost When Control Tower Management Drops

Root Cause: Although most AWS Regions are enabled by default for your AWS account, you must manually enable certain Regions (also referred to as opt-in Regions)

When accounts lose Control Tower management, they might lose access to certain regions or organizational policies.

Solution:

• Verify region availability in all member accounts
• Enable the opt-in Region in each member account in your organization
• Implement independent IAM roles for EventBridge cross-account access

Best Practices for Enterprise EventBridge Architecture

1. Implement Comprehensive Monitoring

Use CloudWatch metrics to monitor your cross-account event flows:

• MatchedEvents and TriggeredRules for rule performance
• IngestionToInvocationSuccessLatency metric provides insights into the end-to-end event delivery latency
• Set up alarms for FailedInvocations to catch permission issues quickly

2. Design for Observability

A simple way to address this is to create a rule to capture and log all events to CloudWatch Logs in your central account. Create a catch-all rule with an empty prefix to capture all events for debugging.

3. Use Dead Letter Queues

A best practice is to use a Dead Letter Queue (DLQ) for handling failed invocations to ensure no critical events are lost during cross-account delivery failures.

4. Implement Proper Resource Tagging

Use consistent tagging strategies across accounts to enable condition-based permissions in your resource policies.

Advanced Considerations

Security and Compliance

When implementing cross-account EventBridge:

• Use least-privilege principles in resource policies
• The principal in the trust policy can also be an AWS service principal to grant to an AWS service the permission needed to assume the role
• Consider using AWS Organizations SCPs to control EventBridge permissions organization-wide

Cost Optimization

Events sent from one account to another are charged to the sending account as custom events. The receiving account is not charged. Design your event routing to minimize unnecessary cross-account hops.

Scalability Planning

EventBridge can scale to thousands of records per second depending on the AWS Region, but plan for potential throttling in high-volume scenarios.

Conclusion

Cross-account EventBridge architectures in AWS Organizations require careful planning and understanding of the distinct roles of CloudTrail organizational trails versus EventBridge event routing. The key insight is that organizational trails don't automatically centralize events—they distribute logging capabilities.

Success comes from implementing explicit event forwarding patterns, proper permission models, and comprehensive monitoring. Whether you choose a hub-and-spoke pattern, direct cross-account targets, or a hybrid approach, the foundation remains the same: clear resource policies, proper IAM roles, and robust observability.

The investment in getting this architecture right pays dividends in operational visibility, security monitoring, and the ability to build truly event-driven organizations that can respond to changes across your entire AWS footprint in real-time.

For implementation examples and CloudFormation templates demonstrating these patterns, check out the AWS EventBridge documentation and the AWS Prescriptive Guidance patterns referenced in this article.

Need AWS Expertise?

We'd love to help you with your AWS projects.  Feel free to reach out to us at info@pacificw.com.

Written by Aaron Rose, software engineer and technology writer at Tech-Reader.blog.