EventBridge event buses are like the central nervous system for your cloud events, and resource policies are how you control who gets to talk to them.
Let’s see this in action. Imagine you have a central main event bus in your AWS account. You want another account (let’s call it the "producer" account with ID 111122223333) to send events to your main bus. You also want your main bus to send events to a specific Lambda function (my-lambda-function) in your account.
Here’s what the resource policy on your main event bus might look like:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowProducerAccountToPutEvents",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::111122223333:root"
},
"Action": "events:PutEvents",
"Resource": "arn:aws:events:us-east-1:ACCOUNT_ID:event-bus/main"
},
{
"Sid": "AllowEventBusToInvokeLambda",
"Effect": "Allow",
"Principal": {
"Service": "events.amazonaws.com"
},
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:us-east-1:ACCOUNT_ID:function:my-lambda-function",
"Condition": {
"ArnLike": {
"aws:SourceArn": "arn:aws:events:us-east-1:ACCOUNT_ID:event-bus/main"
}
}
}
]
}
This policy has two key statements. The first (AllowProducerAccountToPutEvents) grants permission to the 111122223333 account to send events (events:PutEvents) to your main bus. The Principal is set to the root of that account, meaning any IAM principal within 111122223333 can send events. The Resource specifies your main event bus.
The second statement (AllowEventBusToInvokeLambda) is crucial for routing. It allows the EventBridge service itself (events.amazonaws.com) to invoke your my-lambda-function. The Resource points to the Lambda function. The Condition ArnLike: {"aws:SourceArn": "arn:aws:events:us-east-1:ACCOUNT_ID:event-bus/main"} is vital: it ensures that only events originating from your main event bus can trigger this Lambda function. This prevents other services or event buses from accidentally invoking your Lambda.
Think of the event bus as a post office. The resource policy is the set of rules on the post office door. One rule says, "Anyone from address 111122223333 can drop off mail." Another rule says, "We can deliver mail to my-lambda-function if the mail came from this post office."
The problem this solves is multi-account event ingestion and cross-service event routing in a secure, auditable way. Instead of complex VPC peering or API Gateway setups for inter-account communication, you can simply grant EventBridge access.
Internally, when an event is sent to an event bus, EventBridge checks its resource policy. If the PutEvents action is allowed for the source principal, the event is accepted. Then, EventBridge evaluates its rules. For each rule that matches the event, it checks the target’s resource policy (if the target is in a different account or service) or the event bus’s policy (if the target is within the same account and requires explicit permission, like a Lambda function). If the target’s policy allows the invocation, the event is sent.
The exact levers you control are:
- Principal: Who is allowed to perform an action (e.g., an AWS account, a specific IAM user/role, a service).
- Action: What operation is being allowed or denied (e.g.,
events:PutEvents,lambda:InvokeFunction). - Resource: Which AWS resource the policy applies to (e.g., an event bus ARN, a Lambda function ARN).
- Condition: Contextual constraints on the policy (e.g., source ARN, VPC endpoint, IP address).
A common misconception is that you only need a policy on the receiving event bus to allow cross-account PutEvents. However, the sending account’s IAM principal also needs events:PutEvents permission on their own event bus or the global endpoint. If the producer account uses the default event bus, they’ll need to grant events:PutEvents to your account on their default bus.
If you are using EventBridge Pipes, you’ll encounter the concept of source and target ARNs within the Pipe definition, which abstract some of these underlying resource policy details.