ひとことで言うと
イベントを受け取り、ルールに従って複数の送り先へ配る、疎結合のためのイベントバスです。GenAI固有の機能は持ちませんが、「何かが起きたらエージェントを起動する」「SaaS側の変更をGenAI処理に流し込む」というきっかけの部分をここが担います。
要するに、宛先ごとに仕分けしてくれる郵便局です。SNSのfan-outが「同じ手紙を全員に配る」のに対し、EventBridgeは中身（イベントパターン）を見て宛先を振り分けます。「Salesforceで商談が更新されたときだけLambdaを起動する」のような条件付き配送が主戦場です。
なぜ生まれたか
エンタープライズ統合（D2の2.3）で、レガシーシステムやSaaSとGenAIアプリをつなぐときに、点対点の直結を避けるために使われます。
| 摩擦 | EventBridge 側の受け皿 |
|---|---|
| SaaS（Salesforceなど）の変更を都度ポーリングしたくない | AppFlowがSaaSイベントをEventBridgeのパートナーイベントバスへ発行し、ルールで振り分け |
| 複数のサブシステムに同じイベントを条件分岐で配りたい | イベントバス＋ルール（イベントパターンでマッチング） |
| 単一の送信元から単一の送信先への変換・エンリッチが要る | EventBridge Pipes（DynamoDB Streamsなどのソースを1つのターゲットへ、変換を挟んで接続） |
| 定期実行・遅延実行のトリガーが要る | EventBridge Scheduler（cron/rate式、1回限りの実行にも対応） |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| SaaSの変更でGenAI処理を起動 | AppFlowがSalesforceのCDC/プラットフォームイベントをEventBridgeへ発行→ルールでLambda/Step Functionsへ | D2 |
| レガシー連携のイベント駆動化 | API Gateway・Lambda・EventBridgeを組み合わせた疎結合構成 | D2 |
| 定期バッチ的な生成処理 | EventBridge Schedulerでcron実行 | D2, D4 |
| DynamoDB Streamsなど単一ソースの変換配信 | EventBridge Pipes | D2 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| SaaSのレコード更新をトリガーにGenAI要約を走らせたい | AppFlowでイベントを取り込み、EventBridgeのルールで対象を絞ってLambda/Step Functionsへ | SaaS側をポーリングするLambdaを定期実行する案（レイテンシとコストが悪化） |
| 同じイベントを条件によって異なる処理系へ振り分けたい | EventBridgeのイベントパターンでルールを複数作る | SNSのfan-outで全購読者に配ってから各自でフィルタさせる案（振り分けの責務が下流に漏れる） |
| 単一ソースから単一ターゲットへの変換だけで十分 | EventBridge Pipes（バスを介さない軽量な点対点） | イベントバス＋ルール1本で代用する（オーバースペック） |
| 決まった時刻にバッチ推論を起動したい | EventBridge Scheduler | Lambdaの中に自前のsleepループを書く案 |
「イベント駆動＝疎結合＝常に正解」ではありません。単一の送信元から単一の送信先へ、変換だけ挟んで渡したい場合は、イベントバスとルールを組むよりPipesの方が単純です。試験のシナリオで「複数の送り先に条件分岐で配る」要件が無いなら、イベントバスを持ち出すのは過剰設計という判断になります。
実務でどう使うか
- PutEventsのスループットはリージョンで大きく差があります。 us-east-1などの主要リージョンは高いTPSを既定で持ちますが、その他のリージョンは既定が低く、急増するSaaSイベントを流し込むと事前のクォータ引き上げ申請が要ります
- 1ルールに対して既定のターゲット数は5個までです。 多数の下流にファンアウトしたい場合、ターゲット数の引き上げ申請か、SNS/SQSを間に挟む設計を検討します
- イベントパターンのサイズには上限があります。 複雑な条件を1つのルールに詰め込みすぎると、パターン自体が上限に当たってルールの分割が必要になります
1ルールあたりのターゲット数は既定5個です。多段のGenAIパイプラインを1つのルールにぶら下げすぎると、この上限に当たって設計をやり直す羽目になります。ターゲットを増やすより、EventBridgeの先にSNS/SQSを挟んでfan-outさせる設計の方が拡張しやすいことが多いです。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon SNS | SNSは登録された購読者全員に同じメッセージを配るfan-out。EventBridgeはイベントの中身を見てルールでルーティングする |
| Amazon SQS | SQSは1対1（またはfan-outの先）でメッセージを溜めるキュー。EventBridgeは配送のルーティング層で、キューイングそのものはしない |
| EventBridge Pipes | 同じEventBridgeの機能だが、単一ソース→単一ターゲットの点対点接続に特化。バスとルールを介さない分シンプル |
想起チェック
Q1. SaaSのレコード更新をトリガーにGenAI処理を起動したい。何を組み合わせる？
AppFlowでSaaSのイベント（プラットフォームイベント・CDC）をEventBridgeのパートナーイベントバスへ発行し、EventBridgeのルールで対象イベントだけをLambdaやStep Functionsへ振り分けます。
Q2. 単一ソースから単一ターゲットへ、変換を挟んで渡したいだけならどの機能？
EventBridge Pipesです。イベントバスとルールを介さない分、点対点の用途ではシンプルに済みます。