Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Sending events to an Amazon service in another account in EventBridge

EventBridge can send events from an event bus in one Amazon account to supported Amazon services in another account, thereby simplifying the architecture of your event-driven solutions and reducing latency.

For example, suppose you have a set of event buses, hosted in multiple accounts, that you require to send security-related events to an Amazon SQS queue in a centralized account for further asynchronous processing and analysis.

EventBridge supports sending events to cross-account targets in the same Region.

Supported services

EventBridge supports sending events to the following targets in other Amazon accounts:

For pricing, see Amazon EventBridge pricing.

Permissions

Enabling access for cross-account event delivery to Amazon services as targets involves the following steps:

Specify an execution role

Specify an execution role for EventBridge to use when sending events to the target when the rule is triggered.

This execution role must be in the same account as the event bus. EventBridge assumes this role when attempting to invoke the target, and any Service Control Policies (SCPs) affecting this account are applied.

SCPs are a type of organization policy that you can use to manage permissions in your organization. For more information, see Service control policies in the Amazon Organizations User Guide.

For example, the following policy allows the EventBridge service to assume the execution role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
       },
      "Action": "sts:AssumeRole"
    }
  ]
}

And the following policy allows the role to send messages to Amazon SQS queues:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sqs:SendMessage",
      "Resource": "target-queue-arn"
    }
  ]
}

For accounts using Amazon Organizations, you can apply an SCP to prevent invoking resources that do not belong to your organization, as shown in the following example:

{
    "Version": "2012-10-17",
    "Statement": [
          {
            "Action": [
                "*"
            ],
            "Resource": "*",
            "Effect": "Deny",
            "Condition": {
                "StringNotEquals": {
                    "aws:ResourceOrgID": "o-1234567890"
                }
            }
        }
    ]
}

Attach a resource access policy to the target

The Amazon services that can receive cross-account events support IAM resource-based policies. This enables you to attach a resource access policy to the target, so you can specify which account has access to it.

Building on our earlier example, the following policy allows the event bus account access to the Amazon SQS queue in the target account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "SQS:SendMessage"
      ],
      "Effect": "Allow",
      "Resource": "target-queue-arn",
      "Principal": {
        "AWS": "source-account-id"
     }
    }
  ]
}

For more information, see Identity-based policies and resource-based policies in the Amazon Identity and Access Management User Guide.

Creating rules that send events to Amazon services in other accounts

Specifying an Amazon service in another account as a target is part of creating the event bus rule.