あるプラットフォームチームは、月次メンテナンスとして複数の AWS アカウントの EC2 インスタンスに対し、以下の順序で処理を自動化したいと考えています。 ・EBS スナップショット取得 → アプリケーションの graceful shutdown（SSM Run Command で実施） → OS パッチ適用 → インスタンス再起動 → HTTP ヘルスチェックで起動確認（ステータスコード 200 の確認） → 失敗時は担当者承認後にスナップショットからリストア。 各ステップは前のステップの成否を確認してから進む必要があり、ステップ⑥では人間の承認フローが必要です。最も効率的に実装する方法はどれですか？
Systems Manager Automation ドキュメント（Runbook）は、AWS インフラ操作に特化したワークフローを YAML/JSON で定義する機能です。aws:createSnapshot（EBS スナップショット取得）、aws:runCommand（Run Command 実行）、aws:waitForAwsResourceProperty（リソース状態待機）、aws:approve（人間の承認フロー、SNS 通知連携可能）など、追加コードなしで一般的なインフラ運用タスクを実行できる豊富なアクションタイプを標準で提供します。SSM メンテナンスウィンドウとの統合で月次実行スケジュールも容易に設定できます。 選択肢A の AWS Step Functions ステートマシンで各ステップを Lambda 関数タスクとして定義し、.waitForTaskToken を使った人間承認フローと Choice ステートによる条件分岐を実装するアプローチは汎用ワークフローとして機能しますが、EBS スナップショット・Run Command 実行など各 AWS インフラ操作ごとに Lambda 関数の実装・テスト・IAM 権限設定が必要で、SSM Automation の組み込みアクションに比べて実装コストが高くなります。 選択肢C の CodePipeline でステージを順次定義し、各ステップを Lambda アクションで実装する。手動承認ステージ（Manual Approval）でステップ⑥の承認フローを実現するアプローチは CI/CD パイプライン（コード→ビルド→テスト→デプロイ）に最適化されており、EBS スナップショット取得や OS パッチ適用といったインフラ運用タスクのオーケストレーションには設計的に適していません。 選択肢D の AWS Lambda 関数内でステップを順次実行するロジックを実装し、15 分のタイムアウト制約に対応するために非同期呼び出しと SQS キューで後続ステップを連鎖させるアプローチは 15 分のタイムアウト制約があり、長時間のパッチ適用や人間の承認待機には対応できません。SQS を使った連鎖も状態管理が複雑になります。