あるWebアプリケーションはEC2 Auto Scalingグループ（ALB配下）で稼働しています。各インスタンスはカスタムAMIからの起動後、大量のライブラリ展開とキャッシュのウォームアップに約10分を要します。日中に予測不能な突発的トラフィックスパイクが発生すると、スケールアウトしたインスタンスがすぐにトラフィックを処理できず、数分間503エラーが発生します。追加コストを最小限に抑えつつ、スパイク時のスケールアウトを高速化する方法はどれですか。
A
Auto Scalingグループにウォームプールを構成し、あらかじめ初期化を済ませた停止状態のインスタンスをプールに保持しておき、スケールアウト時に即座に起動して投入する
Auto Scalingのウォームプールは、初期化（AMI展開・キャッシュウォームアップ等）を済ませたインスタンスを停止（Stopped）状態でプールに保持しておく機能です。スケールアウト時にはこの初期化済みインスタンスを起動するだけでよいため、ブートストラップに時間がかかるアプリでもスケールアウトのレイテンシを大幅に短縮できます。停止状態のインスタンスにはEBS等のストレージ料金のみが発生し、実行中インスタンスを余分に持つよりコストを抑えられます。
選択肢Bの最小キャパシティ引き上げは即応性は得られますが、常時稼働インスタンスが増えるためコストが大きく増加します。
選択肢Cの予測スケーリングは規則的・周期的な負荷には有効ですが、予測不能な突発スパイクには対応できません。
選択肢Dのクールダウンや猶予期間の短縮は、インスタンス自体のブートストラップに要する10分を短縮できないため、根本的な遅延は解消しません。