SAA-043
5つのLambda関数を順番に実行するバッチ処理があり、現在は各関数が次の関数を直接呼び出す形で連鎖しています。途中で失敗した際に、どのステップで失敗したかの追跡と、失敗したステップだけの再実行が難しくなっています。最も適した改善策はどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：A. AWS Step Functionsのステートマシンでワークフローを定義し、各ステートにRetryとCatchを設定する
解説
AWS Step Functionsはワークフローの各ステップを状態として定義し、実行履歴として可視化します。ステートごとにRetry（バックオフ付き再試行）とCatch（エラー時の分岐）を宣言的に設定できるため、どこで失敗したかの追跡と部分的な再実行が容易になります。
選択肢ごとの解説
A. AWS Step Functionsのステートマシンでワークフローを定義し、各ステートにRetryとCatchを設定する
正解です。実行履歴のグラフから失敗ステートを特定でき、Retry / Catch により一時的な障害の自動回復と失敗時の補償処理を宣言的に書けます。
B. 5つの処理を1つのLambda関数に統合し、関数内でtry-catchによるエラーハンドリングを実装する
1つの関数に統合すると、実行時間の上限（最大15分）に抵触しやすくなり、失敗時は先頭からのやり直しになります。どのステップで失敗したかの可視化も改善しません。
C. 各関数の呼び出しをAmazon SQSキューで連結し、失敗したメッセージは可視性タイムアウト経過後に再配信させる
SQSで連結すれば疎結合にはなりますが、ワークフロー全体としてどこまで進んだかという状態は持てず、分岐や並列実行、ステップ単位の再実行も自前で実装することになります。
D. Amazon EventBridgeのルールで各関数を順に発火させ、失敗イベントをCloudWatch Logsへ出力する
EventBridgeはイベントの配信を担うサービスで、ワークフローの状態管理やステップ単位のリトライ制御は行いません。失敗の記録は残っても、再実行の制御は自作が必要です。
実務での使いどころ
AWS Step Functions は、複数のサービス呼び出しを「ステートマシン」として定義し、その実行状態をサービス側が管理してくれるオーケストレーションサービスである。ステートには Task（Lambda や他サービスの呼び出し）、Choice（条件分岐）、Parallel（並列実行）、Map（配列に対する反復）、Wait（待機）、Fail / Succeed などがあり、Amazon States Language という JSON ベースの定義で記述する。各 Task には Retry（エラー種別ごとの再試行回数・間隔・バックオフ率）と Catch（エラー時の遷移先ステート）を宣言的に書けるため、リトライ処理やロールバック処理をアプリケーションコードから切り離せる。 「Lambda 関数が次の Lambda 関数を直接呼ぶ」という関数チェーンは、小規模なうちは動くが、ステップが増えると急速に扱いづらくなる。全体の進行状況がどこにも保存されないため失敗地点の特定が難しく、途中から再開する仕組みも自作になる。呼び出し元の Lambda は呼び出し先の完了を待つ間も課金され続けるという無駄もある。Step Functions に移すと、実行ごとに履歴が残りコンソールのグラフで失敗ステートを一目で特定でき、入力を差し替えた再実行も容易になる。ワークフロータイプには Standard（最長 1 年、実行ごとの厳密な履歴、状態遷移課金）と Express（最長 5 分、高スループット、実行時間とメモリ課金）の 2 種類があり、長時間の業務ワークフローは Standard、大量の短時間イベント処理は Express を選ぶ。 SAA-C03 では「複数ステップの処理を順序立てて実行したい」「どのステップで失敗したか追跡したい」「リトライやエラー処理を組み込みたい」といった要件で Step Functions が正解になる。誤答には Lambda への統合、SQS による連結、EventBridge による連鎖が並ぶ。SQS や EventBridge は「疎結合なメッセージ配信」が役割であってワークフローの状態管理は行わない、という区別が判断の決め手になる。