Introduction

Amazon EventBridge is a powerful event bus service that makes it easier to build event-driven architectures. It allows you to connect different AWS services or even external SaaS applications through a simple and scalable setup.

While EventBridge is incredibly versatile, its ability to target endpoints or consumers is typically restricted to the same AWS account.
The exception is an event bus in a different account, which can be a valid target.

To achieve this, events must be pushed from the source account's event bus to the destination account's event bus. This cross-account communication is essential for managing critical events and ensuring centralized visibility and control.

In this blog, we'll demonstrate this with an example: when a security service in AWS is disabled, it generates an event that is forwarded to a central monitoring account event bus, triggering an alarm. This approach helps maintain a robust, scalable, and secure event-driven architecture across AWS accounts.

Architecture and Workflow

In given architecture :

1. We have two accounts workload account (source account for event) and central-monitoring account (destination account).
2. If Security service like SecurityHub disable in workload account, event rule on default event bus will get triggered.
3. This event rule has target and respective permission to send event to central-monitoring account event custom bus. You can configure default event bus as well.
4. Custom event bus in central-monitoring account have similar event rule as above. This event rule triggers Lambda function , that can enrich event and send it to SNS.
5. On SNS, if you subscription conifgured, you will get notification.

Deployment

• To create resources via Cloudformation you can refer this Github repo.

• Part of this stack below resources get created

Central Account - Receiver

1. Custom event bus with permission for workload i.e. source account.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowSourceAccountPutEvents",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::99999999999:root"
    },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-1:111111111:event-bus/CentralMonitoringBus"
  }]
}

Note: Here in principle I have specified root of workload account. It means any entity from workload account can publish message. My advice would be to have specific role.

1. Event rule that matches event related to security hub

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "AllowSourceAccountPutEvents",
    "Effect": "Allow",
    "Principal": {
      "AWS": "arn:aws:iam::714258651552:root"
    },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-1:11111111:event-bus/CentralMonitoringBus"
  }]
}

1. Lambda function that will be the target of above rule. This lambda will extract details from event and send it to SNS.

Workload Account - Source

1. Event rule on default event bus. It get trigger when security hub is disable. It has target set to custom event bus of central account.

Demo

1. In workload account, I disabled security hub, this triggered event rule in workload account.

1. This event sent further details to central account where event rule triggers lambda function that extract details from event like Accountid, service which is getting disabled. These details will get send to SNS. For this demo I have created Email subscription under SNS topic. So I get notification over an email. As per your need you can set communication channel.

Conclusion

I hope this blog gives you an idea how we can set cross account communication between AWS accounts via even bridge. Event-bridge is one of the important service in AWS which we can use effectively to build scalable application.