EventBridgeのイベントバスは、AWSサービスのイベントが流れ込むデフォルトバスと、自分で作るカスタムバスの2系統で役割が分かれます。別のアカウントや別のリージョンへイベントを渡すには、受信側バスのリソースポリシー、送信側のIAMロール、両側のルールの3つを揃える必要があります。本記事では、バスの選び方からリソースポリシーの書き分け、put-targetsでの登録、1ホップ制限を踏まえた集約構成の判断までを、AWS CLIの設定例で整理しました。EventBridge全体の仕組みはAmazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順で扱っています。仕様と上限値は2026年10月時点の公式ドキュメントの記載です。
まとめ：バスは発生源で分け、他アカウントへは受信側のポリシーで開く
AWSサービスのイベントはデフォルトバスで受け、自社アプリのイベントは業務ドメインごとのカスタムバスに分けます。デフォルトバスは削除できず、ほかのアカウントからのイベントも最初は受け付けません。新しく作るアプリなら、2026年9月に加わった新しいCustom Event Busを先に検討するよう公式は案内しています。
アカウントをまたぐ送信は、受信側バスのリソースポリシーで送り手を許可し、送信側ではIAMロール付きのルールで相手のバスARNをターゲットにします。2023年3月2日以降に作ったバス宛てのターゲットはロールが必須です。受信側から第3のアカウントへは再転送されないため、集約は送り手から中央のバスへ1回で届ける形に組みます。複数チームが同じバスを購読する構成なら、Classicのポリシーを書き足すよりAWS RAMで共有する新しいバスのほうが管理しやすくなります。
イベントバスの種類と選び方｜デフォルト・Classic・新バスの役割分担
まず、どのイベントをどのバスで受けるかを決めます。ここが決まらないと、権限の設計に進めません。
デフォルトバスはAWSサービスのイベントの受け口で削除できない入口
デフォルトバスは各アカウントの各リージョンに最初からあるバスで、EC2の状態変化やS3の通知といったAWSサービスのイベントはここへ届きます。イベントバスの削除の項によると、カスタムバスとパートナーバスは削除できますが、デフォルトバスは削除できません。バスを削除すると、そのバスに関連付いたルールも一緒に消えます。
イベントバスのアクセス許可の項は、デフォルトバスが受け付けるのは1つのアカウントからのイベントだけだと書いています。自社アプリのPutEventsもデフォルトバスへ送れますが、AWSサービスのイベントと混ざるため、ルールのパターンで発生源を毎回絞ることになります。
自社アプリのイベントはドメインごとのカスタムバスへ分け100本の枠で設計
カスタムバスは、自作アプリのイベントを受けるために作るバスです。EventBridgeのクォータでは、Classicのイベントバスは1アカウント・1リージョンあたり100本、ルールは1バスあたり300本が既定値で、どちらも引き上げを申請できます。東京リージョンのPutEventsは毎秒1,200件です。
分け方の目安は、受注・在庫・会員のような業務ドメイン単位です。バスを分けると、リソースポリシーで「どのアカウントに何を送らせるか」をバスごとに書けます。逆に、マイクロサービス1つにつき1本といった細かい分け方は、ポリシーとルールの管理箇所が増えるだけで得るものが少なくなります。
2026年9月の新Custom Event BusはRAM共有と購読者で他チームへ開く
2026年9月から、カスタムバスは2系統になりました。ルールとターゲットで振り分ける従来のバスは「Custom Event Bus – Classic」と表示され、新しいCustom Event Busでは、利用する側のアカウントが自分で「サブスクライバー」を作ってフィルタと届け先を持ちます。新しいバスのARNはevent-busv2を含む形で、末尾にEventBridgeが生成した識別子が付きます。
アカウントをまたぐ方法も違います。Classicはバスのリソースポリシーで相手を許可し、新しいバスはAWS RAMで共有します。新しいバスの既定の上限は1アカウント・1リージョンあたり5本と少なめです。保持・順序・リプレイといった新旧の機能比較はAmazon EventBridgeとはの新旧バス比較表にまとめてあるので、本記事では権限の持ち方の違いに絞って扱います。
受信側の設定｜カスタムバスを作りリソースポリシーで送信元を許可する
ここからはClassicのバスで、ワークロード用のアカウント111122223333から、運用集約用のアカウント444455556666にある東京リージョンのバスops-centralへイベントを集める構成を組みます。
create-event-busで作成しput-permissionでポリシー文書を設定
受信側のアカウントで、バスを作ってからポリシーを付けます。公式のポリシー例と同じく、送信側アカウントにevents:PutEventsだけを許可します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowWorkloadAccountPutEvents",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::111122223333:root" },
"Action": "events:PutEvents",
"Resource": "arn:aws:events:ap-northeast-1:444455556666:event-bus/ops-central"
}
]
}aws events create-event-bus --name ops-central --region ap-northeast-1
aws events put-permission --event-bus-name ops-central --policy file://bus-policy.json --region ap-northeast-1
aws events describe-event-bus --name ops-central --region ap-northeast-1put-permissionのリファレンスでは、--policyにポリシー文書を渡す方法と、--statement-id・--action・--principalを1件ずつ指定する方法のどちらかを選びます。後者で足したステートメントは、同じIDをremove-permissionに渡すことで取り消しが可能です。付いたポリシーはdescribe-event-busのPolicyで確かめます。ポリシーの上限は10,240字で、許可するアカウントを足すたびに増えていきます。同じポリシーをTerraformのaws_cloudwatch_event_bus_policyで書く方法はTerraform EventBridgeの実装手順：ルール・ターゲット・Schedulerと権限のHCL例で扱っています。
アカウントID指定と組織ID指定の書き分けとaws:PrincipalOrgIDの条件
送り手がAWS Organizationsの同じ組織にいるなら、アカウントを1件ずつ並べるより組織IDで許可するほうがポリシーが伸びません。Principalを"*"にし、aws:PrincipalOrgIDの条件で組織内に限定します。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowOrgPutEvents",
"Effect": "Allow",
"Principal": "*",
"Action": "events:PutEvents",
"Resource": "arn:aws:events:ap-northeast-1:444455556666:event-bus/ops-central",
"Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-a1b2c3d4e5" } }
}
]
}組織IDで許可した場合、送信側はルールのターゲットにRoleArnを必ず指定する、とリファレンスに明記されています。条件を付けずに"*"だけを書くと、すべてのAWSアカウントからのイベントを受け付けるバスになる仕様です。組織の構成と組織IDの確かめ方はAWS Organizationsとはで扱っています。
aws:SourceArnで送信元のリージョンとルールに絞る条件の書き方
アカウント単位の許可だけでは、送信側のどのルールからでもイベントを入れられます。公式の例のようにaws:SourceArnに送信側ルールのARNを並べると、決めたルールから来たイベントだけを通せます。
"Condition": {
"ArnEquals": {
"aws:SourceArn": [
"arn:aws:events:ap-northeast-1:111122223333:rule/forward-ec2-state",
"arn:aws:events:ap-northeast-3:111122223333:rule/forward-ec2-state"
]
}
}デフォルトバス上のルールのARNはrule/ルール名、カスタムバス上のルールはrule/バス名/ルール名の形になります。リージョンの部分をarn:aws:events:ap-northeast-3:*:*のようにワイルドカードで書けば、特定リージョンで発生したイベントだけを許す条件にもなります。大阪をDR用のリージョンにしている構成で、東京と大阪以外からの送信を拒みたいときに使える書き方です。
送信側の設定｜IAMロールとput-targetsで別アカウントのバスへ送る
受信側の準備が済んだら、送信側のアカウントでロールとルールを作ります。
2023年3月以降に必須となった送信側IAMロールの信頼と許可の設定
クロスアカウントの項によると、2023年3月2日以降に作成した別アカウントのバス宛てターゲットには、IAMロールが必須です。それ以前にロールなしで作ったターゲットは動き続けますが、SCPによる組織の境界を効かせるためにロールを付けるよう推奨されています。コンソールでルールを作るとロールは自動で作られ、CLIでは自分で作ります。
# trust.json（EventBridgeがロールを引き受けるための信頼ポリシー）
{
"Version": "2012-10-17",
"Statement": [
{ "Effect": "Allow", "Principal": { "Service": "events.amazonaws.com" }, "Action": "sts:AssumeRole" }
]
}
# put-central.json（受信側バスへのPutEventsだけを許す）
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "events:PutEvents",
"Resource": "arn:aws:events:ap-northeast-1:444455556666:event-bus/ops-central"
}
]
}aws iam create-role --role-name eventbridge-forward-to-central --assume-role-policy-document file://trust.json
aws iam put-role-policy --role-name eventbridge-forward-to-central --policy-name put-central --policy-document file://put-central.json許可ポリシーのResourceは相手のバスARNに限定します。"*"にすると、このロールを使うルールが組織外のバスへも送れる状態になるため注意が必要です。信頼ポリシーと許可ポリシーの違いはAWS IAMとはで整理しています。
put-ruleとput-targetsで受信側のバスARNを登録し入力変換は外す
送信側のデフォルトバスに、EC2の状態変化を拾うルールを作り、ターゲットに受信側のバスARNとロールを指定します。
{
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"]
}aws events put-rule --name forward-ec2-state --event-pattern file://pattern.json --region ap-northeast-1
aws events put-targets --rule forward-ec2-state --region ap-northeast-1 --targets \
Id=opsCentral,Arn=arn:aws:events:ap-northeast-1:444455556666:event-bus/ops-central,RoleArn=arn:aws:iam::111122223333:role/eventbridge-forward-to-central応答のFailedEntryCountが0であることを確かめます。put-targetsのリファレンスによると、別アカウントのバスがターゲットのときはInput・InputPath・InputTransformerを指定できません。通知文に整えたい場合は、受信側のルールで入力トランスフォーマーを掛けます。同じIdとArnでRoleArnを省いてput-targetsを打ち直しても、設定済みのロールは外れません。
受信側ルールのパターンにaccountを入れ外部のイベントを絞る理由
受信側のルールは、自分のアカウントのイベントと他アカウントから届いたイベントを区別しません。accountをパターンに書かない既存のルールは、届いたイベントにも反応します。受信側では送り手のアカウントIDを並べたルールを作り、SQSなどへ渡します。
{
"account": ["111122223333", "222233334444"],
"source": ["aws.ec2"],
"detail-type": ["EC2 Instance State-change Notification"]
}公式は、すべてのアカウントからの受信を許可したバスでは、全ルールにaccountを入れるよう強く勧めています。accountに"*"を書くと、どのイベントにも一致しなくなる点も落とし穴です。許可したアカウント全部を対象にしたいなら、account自体を省きます。パターンの演算子はEventBridge イベントパターンの書き方にまとめています。
課金は送る側に付きます。別アカウントへ送ったイベントは送信側でカスタムイベントとして課金され、受信側には料金がかかりません。同じアカウント内のバス間転送もカスタムイベント扱いです。単価の考え方はAmazon EventBridgeの料金で解説しています。
リージョンをまたぐ送信と別アカウントのSQS・Lambdaへの直接配信
バスからバスへ送る形のほかに、リージョンを変える送信と、相手アカウントのサービスへ直接届ける送信があります。
クロスリージョン送信はバスARNのリージョンを変え、転送料は別に発生
別リージョンへの送信も、クロスリージョンの項のとおり、ターゲットに相手リージョンのバスARNを指定するだけです。先のput-targetsを大阪（ap-northeast-3）で打ち、ARNは東京のバスのまま渡せば、大阪で発生したイベントが東京のops-centralへ届きます。
送信先として使えるリージョンは、2021年11月22日の発表でAWS GovCloud（US）と中国を除く全リージョンに広がり、東京と大阪も含まれています。クロスリージョンの呼び出しはカスタムイベントの料金で、料金ページによるとリージョン間のデータ転送料が別にかかる場合があります。
別アカウントのSQS・SNS・Lambdaへ同一リージョンで直接届ける条件
相手のアカウントでもルールを書くのが手間なら、相手のサービスへ直接送る方法があります。別アカウントのAWSサービスへの送信の対象は、API Gateway・Kinesis Data Streams・Lambda・SNS・SQSの5つで、送信先は同じリージョンにあるサービスに限定される仕様です。実行ロールはバスと同じアカウントに置き、受け側のキューやトピックのリソースポリシーで送信元アカウントを許可します。キューポリシーとDLQの置き方はEventBridgeとSQS・Lambdaの非同期構成で扱っています。
文書どうしで記載がずれている点にも注意してください。put-targetsのリファレンスは別アカウントのバスを「同じリージョンにあり権限を付与されている場合」に送れると書いていますが、ユーザーガイドは対応リージョンであれば別リージョンのバスへも送れるとしています。サービスへの直接配信が同一リージョン限定、バス宛てはリージョンをまたげる、と読み分けると両方の記載に沿います。
集約構成の判断｜1ホップ制限と新旧バスの選び分けで経路を決める基準
権限の書き方が分かったところで、組織全体のイベントをどう集めるかを決めます。
受信側から第3のアカウントへは再転送されない1ホップ制限と設計
Classicのバスには、転送が1回で止まる制限があります。受信側のアカウントが、届いたイベントをさらに第3のアカウントへ送るルールを作っても、イベントは届きません。同じアカウント内でも、1本目のバスのルールで2本目のバスから来たイベントを3本目へ回す構成は動きません。
このため、「各アカウント→部門の中継アカウント→全社の集約アカウント」という多段の経路は組めません。送り手の各アカウントから、最終的に処理する集約アカウントのバスへ直接送り、部門ごとの振り分けは集約側のルールで行います。集約先が2か所あるなら、送信側のルールにターゲットを2つ並べます（1ルールあたり5つまで）。
Classicのポリシーで組む条件と新バスのRAM共有へ寄せる条件
Classicのリソースポリシーで組んでよいのは、集約先が1〜2アカウントで、ルールを書くのが集約側のチームだけの構成です。組織ID指定のステートメント1つで送り手を許可でき、既存のルールや資料もそのまま使えます。
購読する側のチームが複数あり、それぞれが自分の届け先を持ちたい構成なら、新しいCustom Event BusとAWS RAMの共有へ寄せます。共有の項では、自分で書くポリシーよりRAMを勧めており、共有自体に料金はかかりません。
aws ram create-resource-share \
--name orders-bus-share \
--resource-arns arn:aws:events:us-east-1:111122223333:event-busv2/orders/EXAMPLE1234567890abcdef \
--principals 444455556666 \
--permission-arns arn:aws:ram::aws:permission/AWSRAMEventBridgeEventBusV2SubscribeOnly上は公式の例で、購読だけを許すマネージド許可を付けています。マネージド許可は発行のみ・購読のみ・イベントソースの接続・フルアクセスの4種類です。共有を外しても、共有中に作られたサブスクライバーは配信を続けるため、止めるにはRevokeResourceを使います。バスとサブスクライバーは同じリージョンに置く必要があり、リージョンをまたぐならバス宛てのサブスクライバーで転送します。RAMの共有の仕組みはAWS RAMとはを参照してください。
クロスアカウント転送を見送り各アカウント内で処理を完結させる場面
次のどれかに当たるなら、アカウントをまたいでイベントを集めず、各アカウントの中で処理を閉じます。
- 集約先で受けたイベントを、さらに別アカウントへ回す前提になっている（1ホップ制限で届かない）
- 集約側で入力トランスフォーマーや条件分岐を掛けたいが、運用するチームが集約アカウントに権限を持てない
- 送り手が組織外のアカウントで、相手側でのロール作成やルール管理を依頼できない
この場合は、各アカウントのルールで通知や処理まで済ませ、集めたいのは監査用の記録だけ、と範囲を絞るほうが運用で見る箇所を減らせます。マルチアカウントでのイベント経路の設計や、既存のClassic構成の見直しはインフラ構築（AWS・Google Cloud・Azure）でご相談いただけます。
よくある質問
イベントバスの設定でよく出る疑問に、公式ドキュメントの記載をもとに答えます。
自社アプリのイベントをデフォルトバスに送ってもよいですか？
自社アプリのイベントも送信可能です。デフォルトバスはAWSサービスのイベントに加えてPutEventsの呼び出しも受け付けます。ただし、AWSサービスのイベントと同じバスに入るため、ルールのパターンでsourceを毎回絞る必要があり、他アカウントへ開くときも同じポリシーで両方を扱う必要がある構成です。アプリのイベントが継続して増える見込みなら、最初から業務ドメインごとのカスタムバスに分けておくほうが、権限とルールの見通しを保てます。
イベントバスを削除すると何が消えますか？
カスタムバスとパートナーバスは削除でき、そのバスに関連付いたルールも一緒に削除されます。デフォルトバスは削除できません。他アカウントから送られてくるバスを消すと、送信側のルールは宛先を失ったまま残ります。集約用のバスを作り直す場合は、送信側のターゲットを先に外してから削除し、同じ名前で作り直したあとにポリシーを付け直してください。新しいCustom Event BusはARNの末尾が作成ごとに変わるため、名前ではなくARN全体を保存するよう公式は案内しています。
別アカウントのバスへ送るイベントの形を変えられますか？
送信側では変えられません。別アカウントのバスがターゲットのとき、put-targetsでInput・InputPath・InputTransformerは使えない仕様です。イベントは元の形のまま受信側に届くため、形を変えたい場合は受信側のルールのターゲットに入力トランスフォーマーを設定します。送信元によって通知の文面を変えたいなら、受信側でaccountごとにルールを分け、それぞれに別のテンプレートを付ける方法があります。
すべてのAWSアカウントからイベントを受け付けるとどうなりますか？
リソースポリシーでPrincipalを"*"にし条件を付けなければ、どのアカウントからでもPutEventsできるバスになります。その場合、accountを書いていない受信側のルールは、知らないアカウントから届いたイベントも処理の対象です。公式は全ルールにaccountを入れるよう強く勧めています。組織内に限りたいならaws:PrincipalOrgIDの条件を付けてください。新しいCustom Event Busでは、条件なしで公開になるポリシーはPublicPolicyExceptionで拒否されます。
新しいCustom Event BusとClassicの間でイベントを転送できますか？
できます。新しいバスのサブスクライバーは、ターゲットに別のCustom Event BusかClassicのバスを指定でき、自アカウント・別アカウント、同一リージョン・別リージョンのどれでも構いません。Classicのルールも新しいバスをターゲットにできるため、移行中は両方向に流せます。転送先のバスでは新しいイベントIDと受信時刻が付き、別アカウント宛てには転送先のポリシーかRAM共有での許可が要ります。ロールにはevents:PutEventsとevents:PutRawEventsの両方を付けておくと、発行方法の違うイベントが混ざっても拒否されません。
関連記事
- Amazon EventBridgeとは？仕組み・料金とCLI・Pythonでの実装手順、新Custom Event Busとの違いを解説【2026年版】：バス・ルール・ターゲットの全体像と新旧バスの比較表。
- EventBridge イベントパターンの書き方：演算子一覧とtest-event-patternでの検証：受信側ルールでaccountやsourceを絞るパターンの書き方。
- EventBridge 入力トランスフォーマーの使い方：InputTemplateでSNS・Slack通知を整形する：受信側で集めたイベントを通知文に整える手順。
- AWS Organizationsとは？マルチアカウント管理・SCP/RCP・一括請求の仕組みと設計判断を実装者目線で解説：組織ID指定のポリシーとSCPによる境界の前提。
- AWS Resource Access Manager（RAM）とは？共有の仕組みとCLIで共有する手順・共有できるリソースの見分け方：新しいCustom Event Busを共有するときの仕組み。
