EventBridgeはデフォルトバスでも別アカウントから受信できる？集約時の権限と選び方

2026年10月27日

複数のAWSアカウントで発生するイベントを1か所へ集約するとき、「受信先はカスタムイベントバスを作らないといけないのか」と迷うことがあります。

EventBridgeのデフォルトイベントバスでも、リソースベースポリシーで許可すれば、別アカウントのイベントを受信できます。カスタムバスでなければ受信権限を制御できない、という違いではありません。

この記事は、イベントバスにルールとターゲットを設定する構成を対象にします。現在の公式資料では、従来のカスタムバスは「Custom Event Bus – Classic」と区別されています。サブスクライバーを使う新しいCustom Event Busとは設計を混同しないようにしてください。

集約には「受信許可」と「転送」と「受信後のルール」が必要

受信先のバスを選ぶ前に、イベントが届く流れを整理します。

ポリシーで許可しただけでは、送信元のイベントが自動で転送されるわけではありません。また、バスへ届いても、受信後のルールが一致しなければターゲットへ送られません。

デフォルトバスは、初期状態では自分のアカウントからのイベントを受け取る構成です。必要な許可を追加することで、別アカウントからの PutEvents などを認められます。

ポリシーでは、受信を許可するアカウントやOrganizationsの組織を指定できます。イベントを送る権限と、ルール・ターゲットを管理する権限は別なので、集約に必要な範囲を選びます。詳細はイベントバスのアクセス許可を参照してください。

観点	デフォルトバスを使う場合	専用のClassicバスを作る場合
ルールの置き場所	自アカウントのAWSサービスイベントと同じバスで管理	集約イベント用のルールを分けて管理
受信ポリシー	デフォルトバスのポリシーに必要な許可を追加	集約用途のバスへポリシーを設定
既存構成への影響	既存ルールが他アカウントのイベントにも一致しないか確認	受信後のルールや監視を新しく準備

たとえば既存の通知処理に少数の送信元を加えるなら、デフォルトバスを使う構成も考えられます。一方、共通監視や特定システムの集約を別の担当範囲として管理したいなら、専用バスに分けると構成を追いやすくなります。

ただし、バスを追加するだけでアカウント単位のサービスクォータが独立したり、容量が自動で増えたりすると判断してはいけません。対象クォータの適用単位は別途確認します。

新しいアプリケーションでバスの方式自体を選ぶ場合は、現在のイベントバスの公式概要から、新しいCustom Event Busを含めた機能差も確認してください。

送信ルールのターゲットには、受信先イベントバスのARNを指定します。デフォルトバスも、専用バスも、バス名を含むARNまで照合します。

新しく作成するクロスアカウントのイベントバスターゲットには、IAM実行ロールが必要です。受信側のポリシーだけで完了とせず、送信側のロールに必要な送信権限があるか、EventBridgeがそのロールを引き受けられるかを確認します。

受信側と送信側の設定手順はAWSアカウント間でのイベント送受信に記載されています。リージョンをまたぐ場合は、転送先リージョンの対応条件も確認します。

デフォルトバスで他アカウントのイベントを受け取り始めると、既存ルールのイベントパターンにも一致する場合があります。自アカウントのイベントだけを処理したいルールなら、イベントの account を条件へ含めます。

たとえば、特定アカウントのEC2状態変更を対象にするパターンの例です。アカウントIDは説明用です。

{
  "account": ["111122223333"],
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"]
}

受信ポリシーは「バスへ送ってよいか」、イベントパターンは「届いたイベントをこの処理へ流すか」を決めます。片方だけで、もう片方の設計を置き換えないようにします。

ルールは関連付けたバスに届くイベントへ適用されます。専用バスへ送ったのに、受信ルールをデフォルトバスに作っていた、といった配置の食い違いも確認してください。