EventBridge と Step Functions

Amazon EventBridge は「何かが起きた」という知らせ（イベント）を受け取り、ルールに合う宛先へ振り分けるサービスです。AWS Step Functions は、複数の処理の順番・分岐・エラー時の対応をワークフローとして組み立てるサービスです。SAA では、イベント駆動型アーキテクチャとワークフローのオーケストレーションで問われます。

ひとことで言うと: EventBridge は「イベントの仕分け係」、Step Functions は「処理の段取り表を実行する現場監督」です。

たとえるなら、EventBridge は郵便の仕分け場で、届いた郵便を宛名（ルール）を見て各部署に回します。Step Functions は工程表を持った現場監督で、「A が終わったら B、失敗したら 3 回までやり直し、それでもだめなら C」と段取りどおりに作業を進めます。

このページで押さえる論点

イベント駆動型アーキテクチャの考え方
EventBridge の仕組み（イベントバス、ルール、イベントパターン、ターゲット）
EventBridge の機能（スケジューラ、アーカイブとリプレイ、再試行と DLQ、クロスアカウント、Pipes）
Step Functions の仕組み（ステートマシン、ステートの種類、サービス統合）
Step Functions のエラー処理（Retry と Catch）と人の承認待ち
Standard ワークフローと Express ワークフロー
EventBridge・Step Functions・SNS・SQS の使い分け

イベント駆動型アーキテクチャの考え方

イベントとは「注文が確定した」「S3 にファイルが置かれた」「EC2 インスタンスが停止した」のような、状態の変化を知らせるデータです。イベント駆動型アーキテクチャでは、イベントを発行する側（プロデューサー）は「誰が受け取るか」を知らずにイベントを送り、関心のある側（コンシューマー）がそれを受け取って動きます。送る側と受ける側が互いを知らないので、あとから受け取り手を追加しても送る側は変更不要です。

SAA の試験ガイドでは「要件に基づいてイベント駆動型、マイクロサービス、多層アーキテクチャを設計する」「ワークフローオーケストレーション（AWS Step Functions など）」が挙がっています。イベントを「振り分ける」のが EventBridge、決まった手順で処理を「進める」のが Step Functions です。

EventBridge の仕組み

EventBridge の中心はイベントバス（イベントを受け取る通り道）です。イベントバスに届いたイベントは、ルールで評価され、条件に合えばターゲット（宛先）へ送られます。

イベントバスの種類: AWS サービスのイベントが届くデフォルトイベントバス、自社アプリのイベント用のカスタムイベントバス、提携 SaaS（Zendesk、Datadog など）のイベントを受けるパートナーイベントバスがあります。
イベントパターン: ルールの条件を JSON で書きます。「source が aws.ec2 で、状態が stopped のもの」「注文金額が 10 万円以上のもの」のように、イベントの中身で絞り込めます。
ターゲット: Lambda、Step Functions、SQS、SNS、Kinesis Data Streams、Data Firehose、ECS タスク、API Gateway、別のイベントバスなどを指定できます。1 つのルールに指定できるターゲットは最大 5 つです。

SNS の購読者向けフィルターポリシー（「SQS と SNS」参照）も絞り込みができますが、EventBridge は AWS サービスや SaaS のイベントをそのまま受け取れ、ルールごとに多様な宛先へ振り分けられる点が特徴です。

再生型アニメ図解

イベントがルールで振り分けられる流れ

※簡略化しています: ルール A は「すべての注文確定イベント」、ルール B は「金額 10 万円以上の注文確定イベント」という想定です。配信の失敗と再試行、デッドレターキューは省略しています（「EventBridge の機能」で説明）。

EventBridge の機能

機能	できること	試験での使いどころ
EventBridge スケジューラ	cron 式・rate 式で定期的に、または指定日時に 1 回だけ、ターゲットを呼び出す	「毎晩 2 時にバッチを実行」「EC2 を夜間に停止」。サーバーで cron を動かす必要がない
アーカイブとリプレイ	イベントを保存し（保持期間は既定で無期限、日数を指定可能）、あとから再送信する	障害からの回復、新しい処理の検証のために過去のイベントを流し直す
再試行ポリシーと DLQ	ターゲットへの配信に失敗すると、既定で最大 24 時間・185 回まで再試行。それでも届かないイベントは削除されるため、SQS のデッドレターキューを設定して残す	「配信できなかったイベントを失いたくない」
クロスアカウント・クロスリージョン	別のアカウントや別リージョンのイベントバスをターゲットにする	複数アカウントのイベントを 1 つのアカウントに集めて監視・処理する
EventBridge Pipes	SQS・Kinesis・DynamoDB Streams などのソースから 1 対 1 でターゲットへつなぎ、途中でフィルター・加工できる	ポーリングや連携のコードを書かずにソースとターゲットをつなぐ
スキーマレジストリ	イベントの構造（スキーマ）を記録・検出し、コードのひな形を生成する	開発者がイベントの形式を調べる手間を減らす

AWS サービスの状態変化（EC2 の停止、Auto Scaling のスケールアウト、CodePipeline の失敗など）や、CloudTrail に記録された API 呼び出しも、デフォルトイベントバスにイベントとして届きます。「特定の API が呼ばれたら通知したい」「セキュリティグループが変更されたら自動で元に戻したい」といった要件は、EventBridge のルールで Lambda や SNS を呼び出して実現します。

Step Functions の仕組み

Step Functions では、処理の流れをステートマシン（状態の遷移図）として定義します。定義には Amazon States Language（JSON 形式）を使い、コンソールのドラッグ＆ドロップの画面（Workflow Studio）でも作れます。1 つ 1 つの箱をステートと呼びます。

ステート	役割
Task	処理を実行する（Lambda の呼び出し、DynamoDB への書き込み、ECS タスクの実行、Glue ジョブの開始など）
Choice	条件で次のステートを分岐する（「在庫あり」なら発送、「なし」なら取り寄せ）
Parallel	複数の処理を同時に実行し、すべて終わるのを待つ
Map	配列の各要素に同じ処理を繰り返す。分散モードでは S3 上の大量のファイルを並列処理できる
Wait	指定した時間、または指定した日時まで待つ
Pass / Succeed / Fail	データを加工して次へ渡す／成功で終了／失敗で終了

Task ステートからは、Lambda を挟まずに多くの AWS サービスの API を直接呼び出せます（サービス統合）。「Lambda で SDK を呼ぶだけ」のコードを減らせるため、運用負荷の低い構成として選ばれます。各ステート間で受け渡すデータ（入出力）は最大 256 KiB です。大きなデータは S3 に置き、その場所だけを渡します。

Step Functions のエラー処理と人の承認待ち

複数の処理をつなぐと、途中の 1 つが失敗したときの対応が面倒になります。Step Functions では、エラー処理をコードではなくワークフローの定義に書けます。

Retry: 失敗したら、指定回数まで間隔を空けて（指数バックオフ）自動でやり直します。一時的なエラー（相手のサービスが混雑しているなど）に有効です。
Catch: 再試行しても失敗したら、指定した別のステート（返金、通知、取り消しなど）へ進みます。ワークフロー全体を異常終了させずに後始末ができます。

操作できるシミュレーター

Retry と Catch で結果がどう変わるか

「決済」ステートが最初の何回か失敗する想定です。設定を変えて「▶ 実行」を押してください。

決済が失敗する回数: 2 回 Retry の最大再試行回数: 3 回 Catch を設定する（失敗したら「返金・通知」へ）

※簡略化しています: 再試行の間隔（指数バックオフ）、エラーの種類ごとに Retry・Catch を分ける設定は省略しています。「決済」は Lambda などを呼ぶ Task ステートの想定です。

人の承認を待つ（コールバック）

「上長が承認したら次へ進む」のように、外部の応答を待ちたい場合は、Task ステートに .waitForTaskToken を付けます。Step Functions はタスクトークンを発行して一時停止し、承認メールのリンクなどから SendTaskSuccess（または SendTaskFailure）でトークンが返されると再開します。Standard ワークフローなら最長 1 年待てるため、数日かかる承認フローも扱えます。

Standard ワークフローと Express ワークフロー

項目	Standard	Express
最大実行期間	1 年	5 分
実行のされ方	exactly-once（各ステップは 1 回だけ。Retry を指定した場合を除く）	非同期は at-least-once（重複して実行されうる）、同期は at-most-once
料金の考え方	状態遷移の回数	実行回数・実行時間・メモリ量
実行履歴	Step Functions に保存（90 日間）。コンソールで経過を目で追える。1 回の実行の履歴は最大 25,000 イベント	Step Functions には保存しない。見るには CloudWatch Logs へのログ記録を有効にする
向いている処理	長時間の処理、人の承認待ち、二重実行が許されない処理（決済など）	IoT データの取り込み、ストリーミングデータの変換など、短時間・大量の処理

見分け方: 「5 分を超える」「人の承認を待つ」「二重実行は困る」なら Standard、「短時間の処理を毎秒大量に」「コストを下げたい」なら Express です。

EventBridge・Step Functions・SNS・SQS の使い分け

4 つのサービスの仕組みの比較は「SQS と SNS」ページにまとめています。ここでは、問題文で迷いやすい組み合わせに絞って見分け方を整理します。

迷う組み合わせ	見分け方
EventBridge か SNS か	AWS サービス・SaaS のイベントを受ける、イベントの中身で細かく振り分ける、スケジュール実行やリプレイが必要 → EventBridge。メール・SMS で人に通知、大量の購読者へ一斉配信 → SNS
Step Functions か SQS か	順番・分岐・エラー時の後始末を含む複数ステップを管理 → Step Functions。処理を溜めて平準化するだけ → SQS
Step Functions か Lambda 1 つか	処理が長い（Lambda の実行時間の上限を超える）、途中で待つ、ステップごとに再試行したい → Step Functions で複数の処理に分ける
EventBridge と Step Functions の組み合わせ	「イベントが起きたらワークフローを開始」は、EventBridge のルールのターゲットに Step Functions を指定する

問題文のキーワード → 選ぶべき答え

問題文の言い回し	選ぶべき答えと理由
「EC2 の状態変化や API の呼び出しをきっかけに自動で処理」	EventBridge のルール（デフォルトイベントバス）でターゲットを呼び出す
「SaaS アプリのイベントを AWS で処理」	EventBridge のパートナーイベントバス
「毎日決まった時刻に Lambda を実行」「サーバーの cron をなくしたい」	EventBridge スケジューラ（cron 式・rate 式）
「過去のイベントを再処理したい」	EventBridge のアーカイブとリプレイ
「ターゲットに届かなかったイベントを失いたくない」	ルールのターゲットに DLQ（SQS）を設定（既定の再試行は最大 24 時間・185 回）
「複数の Lambda を順番に実行し、失敗時は再試行や補償処理」	Step Functions（Retry・Catch）
「上長の承認を待ってから処理を続ける」	Step Functions のタスクトークン（.waitForTaskToken）、Standard ワークフロー
「S3 上の数百万件のファイルを並列処理」	Step Functions の分散 Map
「短時間の処理を毎秒大量に、低コストで」	Express ワークフロー（最大 5 分）
「最長で数日かかる」「二重実行してはいけない」	Standard ワークフロー（最大 1 年、exactly-once）
「Lambda を書かずに DynamoDB や SNS を呼び出したい」	Step Functions のサービス統合

引っかけポイント

「EventBridge は処理の順番や途中の失敗を管理できる」→ ✕。EventBridge はイベントを振り分けるだけです。複数ステップの順序・再試行・後始末は Step Functions で管理します。
「定期実行には EC2 で cron を動かす」→ 運用負荷が高い選択肢です。サーバーレスで定期実行するなら EventBridge スケジューラが正解になりやすいです。
「Express ワークフローでも 1 時間かかる処理や承認待ちができる」→ ✕。Express は最大 5 分です。長時間の処理や承認待ちは Standard を使います。
「EventBridge は失敗したイベントをずっと保持する」→ ✕。既定では最大 24 時間・185 回の再試行後に削除されます。残すには DLQ を設定します（アーカイブは配信失敗の救済ではなく、イベントの保存と再送のための機能です）。
「Step Functions のステート間で大きなファイルをそのまま受け渡す」→ ✕。入出力は最大 256 KiB です。S3 に置いて場所だけを渡します。
「1 つのルールにターゲットを何十個も登録できる」→ ✕。1 つのルールのターゲットは最大 5 つです。さらに多くの宛先へ配るなら、ルールを分けるか SNS を経由させます。

まとめ: SAA 試験で押さえるポイント

EventBridge = イベントバス → ルール（イベントパターン）→ ターゲット。送る側と受ける側が互いを知らない疎結合
AWS サービスのイベントはデフォルトイベントバス、SaaS はパートナーイベントバス、自社アプリはカスタムイベントバス
定期実行は EventBridge スケジューラ、過去イベントの再処理はアーカイブとリプレイ、配信失敗の保全は DLQ
Step Functions = 複数の処理をステートマシンで順番・分岐・並列に実行。エラー処理は Retry と Catch で定義
人の承認待ちはタスクトークン、大量ファイルの並列処理は分散 Map、Lambda なしの API 呼び出しはサービス統合
Standard（最大 1 年・exactly-once・状態遷移課金）と Express（最大 5 分・大量・低コスト）

確認問題

参考リンク

AWS 公式ドキュメント（外部サイトが開きます）。本文の数値はこれらで確認しています。