Route EventBridge Events Across an AWS Organization (2026)

EventBridge event buses can be configured to send events to other AWS accounts within your organization, enabling centralized event processing and decoupled architectures.

Let’s see this in action. Imagine you have a central "security" account that needs to know about any S3 bucket policy changes across your entire organization. Instead of each account individually sending its CloudTrail logs to the security account, you can configure EventBridge to do this automatically.

Here’s the setup:

1. On the "Producer" Account (where S3 events originate):

Enable EventBridge Event Bus: Ensure EventBridge is enabled for your account. This is usually done by default.

Create a Rule: You’ll create a rule that matches S3 bucket policy change events.

{
  "source": ["aws.s3"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventSource": ["s3.amazonaws.com"],
    "eventName": ["PutBucketPolicy", "DeleteBucketPolicy"]
  }
}

Configure the Target: The target of this rule will be the EventBridge event bus in your central security account. You’ll need the AWS Account ID of your security account and the name of its event bus (typically default).
- Target Type: Event Bus
- Region: The region where your security account’s event bus resides.
- Account ID: 111122223333 (replace with your security account ID)
- Event Bus Name: default
When you set up the target, EventBridge will automatically prompt you to create a resource-based policy on the destination event bus (in the security account) to grant permission for the producer account to send events. This is crucial.

2. On the "Consumer" Account (your central security account):

Event Bus Policy: The EventBridge console, when setting up the target in the producer account, will often guide you through this. You need to ensure your security account’s default event bus has a resource-based policy allowing events from the producer account.
- Principal: The ARN of the IAM role EventBridge assumes to send events from the producer account (e.g., arn:aws-iam:*:111122223333:root or a more specific service principal like events.amazonaws.com). The console often simplifies this to just the producer account ID.
- Action: events:PutEvents
- Resource: The ARN of the event bus in the security account (e.g., arn:aws:events:us-east-1:111122223333:event-bus/default).
- Condition (Optional but Recommended): You can add conditions to restrict which sources or accounts can send events. For example, to only allow events from a specific producer account ID:
```
{
    "Sid": "AllowSpecificAccount",
    "Effect": "Allow",
    "Principal": { "Service": "events.amazonaws.com" },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-1:111122223333:event-bus/default",
    "Condition": {
        "ArnLike": {
            "aws:SourceArn": "arn:aws:events:*:PRODUCER_ACCOUNT_ID:event-bus/default"
        }
    }
}
```
  Note: The console often generates a simpler policy that works for basic cross-account sharing.
Create a Rule in the Security Account: Now, create a rule in your security account’s default event bus to receive and act upon these events.
- Event Source: aws.s3
- Event Type: AWS API Call via CloudTrail
- Details: The same detail-type, eventSource, and eventName filters as in the producer rule.
- Target: This rule’s target could be an SNS topic to notify security analysts, a Lambda function to automatically remediate policy violations, or even another EventBridge event bus for further processing.

The mental model is that EventBridge acts as a central nervous system. Each account can publish its "nervous impulses" (events) to its local event bus. By configuring cross-account targets and permissions, you can route these impulses to a designated "brain" (a central account’s event bus) for global analysis and reaction. This decouples the event producers from the event consumers, meaning the security account doesn’t need to know which specific accounts are sending S3 policy change events, and the producing accounts don’t need to know how the security team is processing those events. They just publish.

A common point of confusion is the directionality of permissions. The producer account needs permission to send events to the consumer’s event bus. This is granted via a resource-based policy on the consumer’s event bus, allowing the producer’s EventBridge service to PutEvents. The EventBridge console usually simplifies this by asking for the producer’s account ID when configuring the target.

The next step is often setting up event archiving or more complex routing logic using EventBridge Pipes to connect event sources to specific targets without Lambda.