Amazon EventBridge

は、AWS サービス、独自アプリケーション、などから発生したイベントを受け取り、条件に合うターゲットへ配信するのイベント連携サービスです。イベントを使ってアプリケーション同士をにし、発生した出来事に応じて、、、、タスク、別アカウントのイベントバスなどを起動できます。

SAA では、EventBridge は「アーキテクチャ」「AWS サービスの状態変化をきっかけに処理」「複数サービスを疎結合に連携」「スケジュール実行」「SQS や SNS との使い分け」という文脈で出ます。単なる通知サービスではなく、イベントをフィルタリングし、必要な処理へルーティングする設計部品として理解します。

Point

Event は「出来事」です。
EventBridge は、出来事を橋渡しするサービスと考えると覚えやすいです。
たとえば「EC2 が起動した」「S3 にオブジェクトが作成された」「アプリケーションが注文イベントを出した」といった出来事を処理へつなぎます。
和訳
- Event: 出来事、イベント
- Bridge: 橋、橋渡し
- Weblio英和辞書「event」

概要

は、イベントの送信元と処理先を直接結合しないためのサービスです。イベントソースがイベントバスへイベントを送ると、イベントバスに紐づくルールがイベントの内容を評価し、条件に一致したイベントだけをターゲットへ配信します。

EventBridge には大きく、イベントバス、Pipes、Scheduler があります。イベントバスは多対多のイベントルーティング、Pipes は 1 つのソースから 1 つのターゲットへつなぐポイントツーポイント連携、Scheduler は cron や rate、単発スケジュールでターゲットを呼び出す機能です。

機能	主な用途	SAA での見方
Event bus	複数ソースから複数ターゲットへイベントを配信	設計の中心です。
Rule	イベントパターンやスケジュールでターゲットを起動	条件一致とルーティングを担当します。
Pipes	1 つのソースから 1 つのターゲットへ連携	やなどから処理先へつなぐ用途です。
Scheduler	時刻や周期でターゲットを起動	定期実行や単発予約実行で使います。
destinations	外部を呼び出し	や外部 API 連携で使います。

SAA では、イベントを失わない設計や、処理失敗時の再試行、、権限、SQS によるバッファリングも重要です。EventBridge はイベントをルーティングしますが、長時間処理や複雑なワークフローそのものを実行するサービスではありません。複数ステップの状態管理が必要なら、メッセージを蓄積してワーカーに処理させるなら SQS と組み合わせます。

主要技術

①イベント、イベントバス、ルール

の基本単位はイベントです。イベントには、発生元を示す source、イベントの種類を示す detail-type、詳細データを入れる detail などが含まれます。イベントバスはイベントを受け取るルーターで、ルールは届いたイベントが条件に合うかを判定します。

用語	役割	試験での判断
Event	発生した出来事のデータ	状態変化やアプリイベントを表します。
Event source	イベントの発生元	AWS サービス、独自アプリ、などです。
Event bus	イベントを受け取ってルールへ渡す場所	多対多ルーティングの中心です。
Rule	イベントパターンに一致したイベントをターゲットへ送る設定	条件分岐とルーティングを担当します。
Target	イベントを受け取る処理先	、、、などです。

イベントバスには、AWS サービスのイベントを自動的に受け取るデフォルトイベントバス、独自アプリケーション向けのカスタムイベントバス、SaaS 連携用のパートナーイベントバスがあります。アプリケーション間の境界を明確にしたい場合は、カスタムイベントバスを作って用途ごとに分けます。

1 つのイベントが複数のルールに一致すると、それぞれのターゲットへ配信されます。1 つのルールに複数ターゲットを設定し、並列に処理させる設計もできます。ただし、ターゲット側の権限や失敗時の扱いを個別に設計します。

⚠️ 頻出: 「AWS サービスの状態変化を検知して Lambda を起動」「独自アプリのイベントを複数処理へ分配」「発生元と処理先をにしたい」は EventBridge のイベントバスとルールを疑います。

②イベントパターン、入力変換、ターゲット

イベントパターンは、イベントのどのフィールドに一致したらルールを発火するかを定義する条件です。たとえばの状態変化イベントで、running になった場合だけを起動する、といった使い方をします。

設定	目的	注意点
Event pattern	イベント内容に基づいて一致判定	`source`、`detail-type`、`detail` をよく見ます。
Target	一致したイベントの配信先	サービスごとに必要な権限が異なります。
Input transformer	ターゲットへ渡す入力を整形	ターゲットが期待する形式に合わせます。
Retry policy	配信失敗時の再試行	一時的な失敗に備えます。
	配信できなかったイベントの退避先	後から原因調査と再処理を行います。

ターゲットには Lambda、、、、、タスク、 Run Command、 destinations、別イベントバスなど、多くの AWS サービスや外部を指定できます。ターゲットへイベントを届けるには、が対象リソースへアクセスできるロールやリソースポリシーが必要です。

DLQ は、ターゲットへ配信できなかったイベントを SQS 標準キューへ退避するために使います。権限不足、ターゲット削除、到達不能などの失敗では、再試行されずに DLQ へ送られる場合があります。SAA では「失敗イベントを後で再処理したい」「ターゲット障害時にイベントを失いたくない」という要件で DLQ を選びます。

Point

DLQ = Dead Letter Queue の略です。
処理に失敗したメッセージやイベントを、後で確認するために置くキューです。
EventBridge のターゲット DLQ は SQS 標準キューを使います。
和訳
- Dead letter: 配達不能郵便
- Queue: 待ち行列
- Weblio英和辞書「queue」

イベントバスにはを作成でき、バスに届いたイベントを、イベントパターンで絞ったうえで指定した期間（無期限も可）保存できます。保存したイベントは、期間を指定して同じイベントバスへリプレイ（再送）できるため、新しく追加したサービスに過去のイベントを流して検証したり、障害の復旧後に処理をやり直したりできます。アーカイブは作成した時点以降のイベントだけを保存するので、後から流し直したい場合は先に作っておきます。

⚠️ 頻出: EventBridge で「ルールは作ったのにターゲットが動かない」場合、イベントパターン不一致、ターゲット権限不足、キー権限不足、リソースポリシー不足、ターゲットのやアカウント設定を確認します。

③イベントバスの種類とクロスアカウント連携

は、複数アカウントや複数アプリケーションをまたぐイベント連携に向いています。イベントバスをターゲットにできるため、あるアカウントのイベントを別アカウントのイベントバスへ送る設計ができます。

イベントバス	主な用途	判断ポイント
Default event bus	AWS サービスイベントの受け取り	、経由の AWS イベントなどを扱います。
Custom event bus	独自アプリケーションイベント	ドメインやアプリ境界ごとに分けられます。
Partner event bus	パートナーイベント	外部 SaaS からのイベントを受け取る用途です。
Cross-account event bus	別アカウントへのイベント送信	マルチアカウント設計で使います。

マルチアカウント環境では、ワークロードアカウントのイベントを監査アカウントや運用アカウントへ集約したい場合があります。このとき、イベントバスので、どのアカウントやからイベントを受け入れるかを制御します。

イベント連携は便利ですが、すべてを中央に集めるとイベントの所有責任や障害影響が見えにくくなることがあります。SAA では、、アカウント分離、セキュリティ境界、権限管理をセットで考えます。

⚠️ 頻出: 「複数アカウントのイベントを中央アカウントで処理」「アプリケーションチーム間を疎結合に連携」「SaaS イベントを AWS 側の処理につなぐ」は EventBridge のイベントバスとリソースポリシーを検討します。

④EventBridge Pipes

Pipes は、1 つのソースから 1 つのターゲットへイベントを流すポイントツーポイント連携です。ソースを選び、必要ならフィルタリングし、必要ならエンリッチメントで情報を追加し、ターゲットへ送ります。

要素	役割	例
Source	イベントの入力元	、、 Streams など
Filter	処理対象イベントの絞り込み	条件に合わないイベントを除外します。
Enrichment	ターゲット前の追加処理	や destinations で情報を補います。
Target	最終的な配信先	、Lambda、Event bus など

イベントバスは、多くのソースから多くのターゲットへルーティングするのに向いています。一方、Pipes は「このキューからこの Step Functions へ」「このストリームからこの Lambda へ」のような 1 対 1 の連携に向いています。統合コードを減らし、フィルタや入力変換をマネージドにできます。

Pipes とイベントバスは併用できます。たとえば DynamoDB Streams を Pipes で受け、加工してカスタムイベントバスへ送れば、その後は複数ルールで複数ターゲットへ配信できます。

⚠️ 頻出: 「1 つのソースを 1 つのターゲットへつなぎたい」「キューやストリームから取り出してフィルタ・加工して送る」は Pipes です。「複数ターゲットへイベントを分配したい」はイベントバスとルールを選びます。

⑤EventBridge Scheduler とスケジュール実行

Scheduler は、時刻や周期に基づいてターゲットを起動するスケジューラです。cron 式、rate 式、単発実行を使えます。柔軟な時間枠、再試行、失敗時の保持期間なども設定できます。

スケジュール要件	選ぶ機能	判断ポイント
毎時、毎日、毎週の定期実行	EventBridge Scheduler	cron / rate で指定します。
1 回だけ将来に実行	EventBridge Scheduler	単発の予約実行に向きます。
イベント内容で発火	EventBridge Rule	スケジュールではなくイベントパターンです。
複数ステップの処理		Scheduler は起動役、処理本体は別サービスです。

Scheduler の cron 式はタイムゾーンを指定でき、夏時間のある地域では現地時刻に合わせて実行時刻が自動で調整されます。従来のスケジュールルールは UTC だけで評価されます。

従来の EventBridge ルールにもスケジュール実行がありますが、公式ドキュメントではスケジュールルールはレガシー機能として扱われ、EventBridge Scheduler の利用が推奨されています。SAA では「定期的にを起動」「指定時刻にへメッセージ」「一度だけ将来にを呼ぶ」といった要件で Scheduler を考えます。

Scheduler は実行タイミングを管理しますが、ワークフローの分岐、待機、リトライ状態管理、承認などを複雑に扱う用途では Step Functions を組み合わせます。単純な定期起動なら Scheduler、複雑な状態管理なら Step Functions と切り分けます。

⚠️ 頻出: 「cron で Lambda を実行」は EventBridge Scheduler です。「イベントに反応して Lambda を実行」は EventBridge ルールです。似ていますが、発火条件が時間かイベント内容かで判断します。

⑥SNS、SQS、Step Functions との使い分け

はイベントルーティング、は Pub/Sub 通知、はキューイング、はワークフロー管理です。SAA では、この違いがよく問われます。

サービス	主な役割	選ぶ場面
EventBridge	イベントを条件でルーティング	AWS サービスイベント、、アプリイベントをに連携します。
SNS	複数購読者への通知配信	通知、メール、SMS、、SQS への配信などです。
SQS	メッセージを蓄積して非同期処理	ワーカーの負荷平準化、リトライ、バッファリングに使います。
Step Functions	複数ステップの状態管理	分岐、待機、並列、エラー処理を含むワークフローに使います。
	イベントに応じた短時間処理	EventBridge や SQS から起動される処理実体です。

EventBridge は「誰に通知するか」だけでなく、「どのイベントを、どの条件で、どのターゲットへ送るか」を管理します。AWS サービスの状態変化を自然に扱える点、SaaS やカスタムイベントを同じ形で扱える点、やイベントバス連携ができる点が強みです。

EventBridge と SQS は組み合わせることが多いです。EventBridge でイベントをフィルタし、SQS に入れてワーカーが自分のペースで処理すれば、ターゲット障害や負荷急増に強くなります。厳密な順序や重複排除が必要な場合は、SQS などターゲット側の特性も確認します。

⚠️ 頻出: 「AWS サービスのイベントで処理を起動」は EventBridge、「処理を平準化したい」は SQS、「複数購読者へ通知」は SNS、「承認や分岐を含む業務フロー」は Step Functions と切り分けます。

試験対策

SAA では、は、、の選択肢として出ます。問題文に「状態変化を検知」「イベントに応じて処理」「連携」「イベント」「スケジュール実行」「複数ターゲットへルーティング」とあれば EventBridge を候補にします。

問題文のキーワード	優先して考える機能	理由
AWS サービスの状態変化	EventBridge ルール	、、経由のイベントなどを扱えます。
独自アプリのイベント配信	カスタムイベントバス	アプリ間を疎結合にできます。
複数アカウントへイベント連携	イベントバス + リソースポリシー	マルチアカウントの境界を保ちながら連携できます。
1 ソースから 1 ターゲットへ加工して送信	EventBridge Pipes	フィルタ、変換、エンリッチメントを組み込めます。
定期実行、単発予約	EventBridge Scheduler	時間条件でターゲットを呼び出します。
配信失敗を後で処理		標準キューに退避して再処理できます。
外部 API を呼ぶ	API destinations	SaaS や外部 API へのイベント連携に向きます。

よくある誤答は、EventBridge とを同じものとして扱うことです。SNS は通知のに強く、EventBridge はイベント内容に基づくルーティングと AWS/SaaS/カスタムイベントの統合に強いです。問題文に詳細なイベントパターン、AWS サービス状態変化、SaaS イベント、クロスアカウントイベントバスが出る場合は EventBridge が自然です。

EventBridge と SQS の違いも重要です。EventBridge はイベントを配送するルーターであり、ワーカー負荷を平準化するキューではありません。ターゲットが処理しきれない可能性があるなら、EventBridge のターゲットに SQS を置いて、ワーカーが SQS から処理する設計にします。

スケジュール実行では、現在は EventBridge Scheduler を優先して考えます。従来のスケジュールルールもありますが、公式ドキュメントではレガシーとして扱われ、Scheduler がより柔軟な機能として推奨されています。問題文が「定期的にを実行」なら Scheduler、「イベントが届いたら Lambda を実行」ならイベントパターンのルールです。

最後に、信頼性設計として DLQ、再試行、、CloudTrail、ターゲット権限を確認します。イベントが届かない問題では、ルールのイベントパターンだけでなく、EventBridge がターゲットを呼び出すためのロール、SQS や Lambda のリソースポリシー、キー権限も確認します。