EventBridge Cross-Account Events Not Arriving: the Bus Policy, the Sender Role, the Receiver Rule That Everyone Forgets, the No-Chaining Rule, Organizations and Cross-Region

EventBridge cross-account events not arriving comes down to one of five gaps, and you can find yours in ten minutes with two commands. A cross-account event crosses three checkpoints: the receiver's event bus policy must allow the sender account to events:PutEvents, the sender's rule must target the receiver's bus ARN with an IAM role (required for every cross-account bus target created since March 2, 2023), and the receiver needs its own rule on that bus, because a forwarded event does nothing by itself. Miss any one and the event vanishes without an error in either console. Two things catch even experienced teams. First, forwarded events are never forwarded again: if account B receives an event from A and has a rule sending it on to C, C never gets it, and the same is true for bus-to-bus-to-bus inside one account. Second, when the receiver's rule is "not matching," it is often matching the wrong thing: a rule with no account field matches forwarded events too, and a rule with "account": ["*"] matches nothing at all. Below: the diagnosis in order, the exact policies and commands for both accounts, the SQS and Lambda target traps on the receiving side, organizations, cross-Region, and the alarm that tells you when it breaks again.

Jake's shop has grown into two AWS accounts: one for the booking app, one that Ethan set up for the bookkeeper's reporting tools. Ethan wired an EventBridge rule in the app account to send "booking paid" events to the reporting account, so an invoice could be generated there. The rule in the app account showed invocations. The reporting account's queue stayed empty for a week. "It says it sent them," Jake said, pointing at the metric. "It did send them," said Ethan. "Nobody on the other side was listening." This page is the checklist he wishes he had started with.

New to EventBridge? Our plain-English EventBridge guide explains events, buses, rules and targets in about ten minutes, and for a rule that fails inside one account, our rule-never-fires guide covers the seven same-account causes. This page is only about events that have to cross an account boundary.

How a cross-account event actually travels

Inside one account an event has a simple life: something puts it on a bus, a rule on that bus matches it, the rule invokes a target. Across accounts there are two buses and two sets of rules, and the hop between them is itself a target:

1. Sender account: an event lands on the sender's bus. A rule there matches it and has, as its target, the receiver's event bus ARN. EventBridge assumes the rule's IAM role and calls PutEvents on the receiver's bus.
2. Receiver's bus policy: the receiver's bus accepts the call only if its resource policy allows events:PutEvents from the sender account (or the sender's organization).
3. Receiver account: the event is now on the receiver's bus, carrying the sender's account ID in its account field. Nothing happens until a rule on that bus matches it and invokes a target in the receiver account, with that target's own permissions.

Here is the same journey as a checklist you can tick off, with the command that proves each checkpoint:

Each hop has its own metric, which is what makes your diagnosis mechanical. The sender's rule reports Invocations when it successfully put the event on the receiver's bus and FailedInvocations when the receiver's bus refused it. The receiver's rule reports TriggeredRules when it matched and its own FailedInvocations when its target refused. A silent gap between the two means the receiver has no rule that matches.

One more fact shapes everything below: the sending account pays for the forwarded event as a custom event; the receiving account pays nothing for receiving it.

The two-command diagnosis

Run the first command in your sender account and the second in your receiver account, for the last hour. Together they tell you which of the five gaps you have.

# SENDER account: did my rule fire, and did the receiver's bus accept the event?
for m in TriggeredRules Invocations FailedInvocations; do
  echo "$m: $(aws cloudwatch get-metric-statistics --namespace AWS/Events --metric-name $m \
    --dimensions Name=RuleName,Value=booking-paid-to-reporting \
    --start-time $(date -u -d '1 hour ago' +%FT%TZ) --end-time $(date -u +%FT%TZ) \
    --period 3600 --statistics Sum --query 'Datapoints[0].Sum' --output text)"
done

# RECEIVER account: did any rule on my bus match, and did its target accept?
aws events list-rules --event-bus-name default --query "Rules[].Name" --output text
for m in TriggeredRules Invocations FailedInvocations; do
  echo "$m: $(aws cloudwatch get-metric-statistics --namespace AWS/Events --metric-name $m \
    --dimensions Name=RuleName,Value=booking-paid-to-invoices \
    --start-time $(date -u -d '1 hour ago' +%FT%TZ) --end-time $(date -u +%FT%TZ) \
    --period 3600 --statistics Sum --query 'Datapoints[0].Sum' --output text)"
done

Read the two results against this table:

If a rule was created or changed in the last few minutes, give it a moment; changes take a short time to apply. Jake's case was row three: 212 invocations on the sender, zero triggered rules on the receiver. Ethan had built the sending side carefully and assumed the event would "arrive in the queue." It arrived on the bus. The queue was two steps further on.

Checkpoint 1: the receiver's event bus policy

By default your event bus accepts events only from its own account, from AWS services, and from PutEvents calls made with that account's credentials. To accept events from another account, the receiver attaches a resource-based policy to the bus. The simplest form grants one account:

# RECEIVER account (reporting, 222233334444): allow the app account to put events on the default bus
aws events put-permission --event-bus-name default \
  --action events:PutEvents --principal 111122223333 --statement-id AllowBookingAppAccount

# read back what the bus now allows
aws events describe-event-bus --name default --query Policy --output text

The same thing as a full policy document, which is what you need for a custom bus with several statements or for conditions:

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

aws events put-permission --event-bus-name invoices-bus --policy file://bus-policy.json

The mistakes that leave this checkpoint failing for you, in the order they turn up:

• The policy is on the wrong bus. The sender targets event-bus/invoices-bus but the permission was added to default. The bus name in the policy's Resource, in put-permission, and in the sender's target ARN must all be the same bus.
• Wrong Region. A bus is regional. The receiver's bus in us-east-1 and the sender's rule in eu-west-1 only work if the target Region is a supported cross-Region destination; see cross-Region.
• Principal typo. Account IDs are twelve digits; a copied ARN with the wrong account is the most common version of this.
• The policy was replaced, not added to. put-permission --policy replaces the whole policy. If the bus already allowed another account, that grant is gone. Read the policy with describe-event-bus before you write it.

Our S3 cross-account guide explains the same "permission on both sides" rule for buckets; EventBridge follows it exactly.

Checkpoint 2: the sender's rule target and its IAM role

In the sender account, the rule's target is the receiver's bus ARN, and the target needs an IAM role that EventBridge assumes to make the PutEvents call. The console creates this role for you when you choose "Event bus in a different account or Region." From the CLI you make it yourself, and leaving it out is the single most common reason for FailedInvocations on the sender's rule, because every cross-account bus target created since March 2, 2023 must have one; only targets created before that date still work without it.

# SENDER account (app, 111122223333)

# 1. the role EventBridge will assume
cat > trust.json <<'EOF'
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow",
  "Principal": { "Service": "events.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }
EOF
aws iam create-role --role-name eventbridge-to-reporting --assume-role-policy-document file://trust.json

cat > putevents.json <<'EOF'
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "events:PutEvents",
  "Resource": "arn:aws:events:us-east-1:222233334444:event-bus/default" } ] }
EOF
aws iam put-role-policy --role-name eventbridge-to-reporting --policy-name put-events-on-reporting-bus --policy-document file://putevents.json

# 2. the rule that picks the events to forward
aws events put-rule --name booking-paid-to-reporting --event-bus-name default \
  --event-pattern '{"source":["shop.bookings"],"detail-type":["Booking Paid"]}'

# 3. the target: the receiver's bus, with the role
aws events put-targets --rule booking-paid-to-reporting --event-bus-name default --targets \
  '[{"Id":"reporting-bus","Arn":"arn:aws:events:us-east-1:222233334444:event-bus/default","RoleArn":"arn:aws:iam::111122223333:role/eventbridge-to-reporting"}]'

Check your existing target for the role, since this is where "it worked in the console but not from Terraform" lives:

aws events list-targets-by-rule --rule booking-paid-to-reporting --event-bus-name default \
  --query "Targets[].[Id, Arn, RoleArn]" --output table

An empty RoleArn on a cross-account bus target means every event fails. Two more role mistakes: a role whose trust policy names a different service (copied from a Lambda role, so it trusts lambda.amazonaws.com), and a role whose policy allows events:PutEvents on the sender's own bus ARN instead of the receiver's. The Resource must be the receiver's bus. If the role looks right and the sender's rule still fails, confirm the Region's STS endpoint is active in the sender account; EventBridge needs it to assume the role.

"So the sending side needs a key to the other shop's letterbox," Jake said, "and the other shop has to have unlocked that letterbox for us." "And then someone there has to open the letter," said Ethan. "That is checkpoint three."

Checkpoint 3: the receiver needs its own rule

This is the gap in most "sender shows invocations, receiver shows nothing" cases. A forwarded event lands on the receiver's bus and then behaves like any other event there: it is only acted on if a rule on that bus matches it. The sender's rule does not reach into the receiver account; it only delivers. In the receiver account:

1. Open the right bus. In the EventBridge console choose Rules, then pick the bus the sender targets from the bus selector; it defaults to default.
2. Create a rule whose pattern matches the forwarded event's source and detail-type, with the sender's account ID in account.
3. Add the target (your queue, function or topic) and let the console add its permission, or add it yourself if you deploy from code.
4. Send one test event from the sender and watch this rule's TriggeredRules move from 0 to 1.

# RECEIVER account: match the forwarded events and send them to a queue
aws events put-rule --name booking-paid-to-invoices --event-bus-name default \
  --event-pattern '{"source":["shop.bookings"],"detail-type":["Booking Paid"],"account":["111122223333"]}'

aws events put-targets --rule booking-paid-to-invoices --event-bus-name default --targets \
  '[{"Id":"invoice-queue","Arn":"arn:aws:sqs:us-east-1:222233334444:invoice-jobs"}]'

Three details about your receiver pattern that cause silent non-matches:

• The bus. The rule must be on the same bus the sender targets. A rule on the default bus never sees events delivered to invoices-bus, and the console's rule list defaults to the default bus, which hides the problem.
• The account field. Forwarded events keep the sender's account ID in account. If your pattern says "account": ["222233334444"] (the receiver's own ID, often copied from a same-account rule), forwarded events do not match. Use the sender's ID, or leave account out. Never write "account": ["*"]; the literal * never appears in an event, so that rule matches nothing.
• Everything else is exact. source and detail-type are case-sensitive, and ARNs in patterns must match colon for colon and slash for slash.

Test the receiver's pattern against a copy of the real event before you blame anything else. Take an event from the sender (CloudTrail, your producer's logs, or a test put-events) and run:

aws events test-event-pattern \
  --event-pattern '{"source":["shop.bookings"],"detail-type":["Booking Paid"],"account":["111122223333"]}' \
  --event '{"id":"1","detail-type":"Booking Paid","source":"shop.bookings","account":"111122223333","time":"2026-10-17T10:00:00Z","region":"us-east-1","resources":[],"detail":{"bookingId":"B-1042"}}'
# true = matches

The reverse problem exists too. If your receiver bus accepts events from several accounts (or from a whole organization), every existing rule on that bus with no account field now matches the forwarded events as well. A rule that was meant for the receiver's own events starts firing on other accounts' events the day the bus policy opens. Add account with your own ID to rules that should stay local.

Checkpoint 4: the receiver's target refuses the event

When your receiver rule triggers and its own FailedInvocations climb, the event is in the right account on the right rule; your target is saying no. The fix depends on the target:

• SQS queue: the queue policy must allow sqs:SendMessage from events.amazonaws.com for this rule's ARN. The console adds it when you pick the queue; CloudFormation, CDK and Terraform often do not. If the queue is encrypted with a customer-managed KMS key, the key policy also needs a statement allowing kms:Decrypt and kms:GenerateDataKey to events.amazonaws.com, or every delivery fails with no message anywhere but the metric. Our SQS queue policy guide shows the statement.
• Lambda function: the function's resource policy must allow lambda:InvokeFunction from events.amazonaws.com with the rule ARN as SourceArn. Check with aws lambda get-policy --function-name NAME; add it with aws lambda add-permission --principal events.amazonaws.com --source-arn arn:aws:events:REGION:ACCOUNT:rule/RULE. A SourceAccount condition in that statement blocks EventBridge; remove it.
• SNS topic: the topic policy needs sns:Publish for events.amazonaws.com, and an encrypted topic needs the same KMS statement as the queue.
• A target in yet another account (the receiver's rule pointing at a queue in account C): the target's resource policy must allow EventBridge from the receiver account, and the rule needs a role. Remember that a bus in account C as a target does not work for forwarded events (next section), but a queue or Lambda in account C can.

Your deliveries are retried for up to 24 hours before they count as failed, so a target that was briefly broken can still catch up. For anything that matters, give the receiver's rule a dead-letter queue (DeadLetterConfig on the target) so undeliverable events are kept instead of dropped; our dead-letter queue guide covers draining it.

No chaining: a forwarded event is never forwarded again

EventBridge delivers your cross-account event exactly one hop. If account A sends an event to account B's bus, and B has a rule that targets account C's bus, C never receives it. The same limit applies inside one account: a rule on bus 1 forwarding to bus 2, and a rule on bus 2 forwarding to bus 3, stops at bus 2. There is no error; the second hop is silently not made, which is why this one costs people days.

Designs you can use instead:

• Fan out from the source. Give account A two rules (or one rule with two targets): one to B's bus, one to C's bus. Each account's bus policy allows A.
• Re-publish in the middle. If B must transform or enrich the event, have B's rule invoke a Lambda function that calls PutEvents on C's bus with its own credentials. A fresh PutEvents is a new event, so it travels a fresh hop.
• Target the resource, not the bus. B's rule can target a queue, a Lambda function or an SNS topic in C directly, with the right resource policy and role; only a bus in C is off limits for a forwarded event.

Jake's bookkeeper later asked for the same events in an accountant's third account. Ethan did not chain it through reporting; he added a second target to the app account's rule.

Granting a whole organization

If both of your accounts are in the same AWS Organization, the receiver can allow every account in it with one statement instead of listing IDs, using the organization ID (o-xxxxxxxxxx, from AWS Organizations):

aws events put-permission --event-bus-name default --action events:PutEvents \
  --principal "*" --statement-id AllowWholeOrg \
  --condition '{"Type":"StringEquals","Key":"aws:PrincipalOrgID","Value":"o-a1b2c3d4e5"}'

Two things change when you do this. The sender still needs the IAM role on its rule target; organization membership grants the permission, the role still makes the call. And because the bus now accepts events from many accounts, put an account field on every rule in the receiver that should not react to the whole organization. Our Organizations guide explains where to find the organization ID and how SCPs can also block events:PutEvents at the boundary, which shows up as FailedInvocations on the sender with a perfect bus policy.

Cross-Region, and cross-account plus cross-Region

Your rule can target a bus in another Region, in the same account or a different one, as long as the destination Region is one of EventBridge's supported cross-Region destinations. The target is still the bus ARN, the role is still required, and the receiver still needs its own rule. What changes is where you have to look: the sender's metrics are in the sender's Region, the receiver's are in the receiver's Region, and a bus policy added in the wrong Region (the console was set to the sender's Region while you were "in" the receiver account) is a very common cause of a refused PutEvents. Check the Region selector before every step, and put the Region in every CLI command with --region.

The alarm, and keeping it fixed

Put an alarm on FailedInvocations for your sender rule and your receiver rule, Sum over 5 minutes, at 1 or more for two periods, sending to an SNS topic you read. That one alarm catches a revoked bus policy, a deleted role, a changed queue policy and an expired KMS grant, which are the four ways this breaks after it once worked.

aws cloudwatch put-metric-alarm --alarm-name eb-booking-paid-to-reporting-failed \
  --namespace AWS/Events --metric-name FailedInvocations --dimensions Name=RuleName,Value=booking-paid-to-reporting \
  --statistic Sum --period 300 --evaluation-periods 2 --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:us-east-1:111122223333:ops-alerts

And a quiet-failure check for the receiver: if the sender's Invocations are steady but the receiver's TriggeredRules drop to zero, someone changed the receiver's pattern or moved the rule to another bus. A simple way is a second alarm on the receiver rule's TriggeredRules with a "less than 1 for an hour" condition during business hours.

For IT admins: a template that avoids every gap

• Use a custom bus per purpose in the receiver (invoices-bus, not default), so cross-account traffic cannot trip the receiver's existing default-bus rules.
• Grant by organization ID where you can, and still list the sender account in the receiver rule's account field.
• Always set RoleArn on bus targets in infrastructure code; the console hides this requirement by creating the role for you.
• Dead-letter queues on both rules, and the FailedInvocations alarm on both.
• Document the three checkpoints next to the code: bus policy (receiver), rule plus role (sender), rule plus target permission (receiver). Every cross-account incident is one of them.

Frequently asked questions

The reporting account's first invoice generated itself on Tuesday, eight days after the sending rule went live, about three minutes after Ethan added the receiver's rule. Jake looked at the two consoles side by side. "So the whole time, the letter was sitting in their letterbox." "In their letterbox," Ethan said, "with nobody told to check it."

Revision note. Written October 17, 2026. "It takes two to tango," the proverb says; with EventBridge it takes two accounts, and both have to know the steps.