SOAデプロイ、プロビジョニング、および自動化
ある運用チームは CloudFormation テンプレートで Auto Scaling グループを作成し、各 EC2 インスタンスの UserData でアプリケーションのブートストラップ処理を実行します。スタックの作成は、指定台数のインスタンスでアプリの起動が完了するまで「CREATE_COMPLETE」とならないようにし、ブートストラップが失敗した場合はタイムアウトしてスタックをロールバックさせたいと考えています。最も適切な実装はどれですか。
AAuto Scaling グループに CreationPolicy を設定し、UserData から cfn-signal で成功シグナルを送り指定数の受信で完了とする
✓ 正解
CreationPolicy と cfn-signal の組み合わせは、アプリ自身が起動成功を報告し指定数のシグナル受信で完了判定します。Timeout 内に届かなければ自動ロールバックされ、要件を完全に満たすため最適です。
BAuto Scaling グループに DependsOn 属性のみを設定し、依存リソースの作成順序を制御してブートストラップ完了を待機する
DependsOn はリソース間の作成順序を制御するだけで、インスタンス内部のアプリブートストラップ完了は検知できません。起動失敗時のタイムアウトやロールバック判定にも使えないため要件を満たしません。
Cカスタムリソースを作成し、Lambda 関数で固定時間スリープさせてからブートストラップ完了とみなしてスタックを進める
固定時間スリープのカスタムリソースは実際の起動完了を保証しません。ブートストラップが遅延・失敗してもスタックが先へ進み、誤って完了扱いになるリスクがあるため不適切です。
DCloudWatch アラームで各インスタンスの DescribeInstanceStatus を監視し、運用者が手動でスタックの完了を承認する
DescribeInstanceStatus の監視と手動承認は自動化に反し、運用負荷も高くなります。CloudFormation の作成ライフサイクルと連動したタイムアウトや自動ロールバックも実現できないため要件に合いません。
解説
CreationPolicy は、CloudFormation がリソースを作成完了とみなす前に、指定した数の成功シグナルを待機させる属性です。Auto Scaling グループに設定し、UserData の最後で cfn-signal を実行することで、アプリのブートストラップが本当に成功したかをアプリ自身が報告できます。Timeout 内に必要数のシグナルが届かなければ作成は失敗し、スタックは自動でロールバックされます。
選択肢Bの DependsOn はリソースの作成順序を制御するだけで、インスタンス内のアプリ起動完了は検知できません。
選択肢Cの固定時間スリープは実際の完了を保証せず、起動が遅延・失敗してもスタックが進んでしまいます。
選択肢Dの手動承認は自動化に反し、CloudFormation のライフサイクルと連動したロールバックも実現できません。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでSOAを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →