AWS認定資格 WEB問題集＆徹底解説

会員登録/ログイン

A. スケジュールされた Amazon EventBridge (Amazon CloudWatch Events) ルールを作成して AWS Lambda 関数を呼び出し、ピーク時間の前に希望する容量を増やす。

EventBridge のスケジュールルールから Lambda 関数を呼び出して容量を変更する構成でも、動作としては要件を満たせる。
しかしAuto Scaling に標準搭載されている機能（スケジュールされたスケーリング）を、Lambda のコードと EventBridge ルール、実行ロールの管理で自作しているにすぎない。関数の保守・障害時の対応というコンポーネントが増えるため、「最も運用効率の高い」ソリューションではない。

正解

B. 繰り返しオプションを使用してスケジュールされたスケーリングアクションを構成し、ピーク時間の前後で希望する容量を変更する。

EC2 Auto Scaling のスケジュールされたスケーリング（scheduled action）は、開始時刻と最小・最大・希望する容量を指定して容量を変更する機能で、cron 形式の繰り返し（recurrence）を指定できる。「毎週末の 18 時に増やし、23 時以降に戻す」といった予測可能な負荷変動にそのまま対応できる。
コードもサーバーも追加サービスも不要で、Auto Scaling グループの設定だけで完結するため、運用効率が最も高い正解。

C. メモリ使用率が 70% を超えた場合にインスタンスを追加するターゲット追跡スケーリングポリシーを作成する。

ターゲット追跡スケーリングはメトリクスがしきい値を超えてから反応する（リアクティブな）方式で、スケールアウトの検知・起動・ヘルスチェック完了までに数分かかる。ピーク開始直後の遅延は避けられず、時刻が分かっている負荷への先回りには向かない。
さらにメモリ使用率は EC2 の標準メトリクスに無く、CloudWatch エージェントの導入とカスタムメトリクスの設定が別途必要で、運用効率の面でも不利。

D. Auto Scaling グループのクールダウン期間を設定して、ピーク時間の前後で希望する容量を変更する。

クールダウン期間は、スケーリングアクティビティの直後に次のスケーリングを行わない待機時間を定義する設定で、容量そのものを変更する機能ではない。
「ピーク時間の前後で希望する容量を変更する」という動作はクールダウンでは実現できず、選択肢の説明自体が機能の役割と食い違っている。

正解への思考ルート

問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。

要件	判断ポイント
遅延が起きる時間帯が「毎週末 18 時〜23 時」と特定できている	負荷が時刻で予測できるなら、リアクティブな監視より時刻ベースの先回り（スケジュール）が適切 →選択肢（C）を消す
ピーク時のパフォーマンスを向上させる（＝ピーク前に容量を確保する）	希望する容量を指定時刻に変更できるのは、スケジュールされたスケーリングか、自作の Lambda →選択肢（A・B）は候補
「最も運用効率の高い」ソリューション	Auto Scaling の標準機能だけで完結する B が勝つ。Lambda ＋ EventBridge は同じことをコードで自作している分だけ負荷が高い →選択肢（B）が正解／選択肢（A）を消す
毎週繰り返す負荷である	スケジュールされたスケーリングは繰り返し（cron 形式の recurrence）を指定でき、毎週末に自動適用される →選択肢（B）が正解
設定の役割を取り違えていないか	クールダウンは「次のスケーリングまでの待機時間」であり、容量を変更する機能ではない →選択肢（D）を消す

ひっかけポイント

• 選択肢 A は「動くけれど運用効率が悪い」タイプの誤答。実現可能性ではなく「最も運用効率の高い」という判断軸で切る（標準機能があるならコードは書かない）
• 選択肢 C のメモリ使用率は EC2 の標準 CloudWatch メトリクスに存在しない（CloudWatch エージェントが必要）。この一点だけでも運用効率で不利
• ターゲット追跡は事後対応（しきい値超過後に増やす）。ピーク開始直後の遅延は解消しきれず、「時刻が読める負荷」には先回りのスケジュールが定石
• 選択肢 D のクールダウン期間は「スケーリングの連打防止」の設定。容量変更のスケジュール機能と混同させるのが罠

出題バリエーション

同じ知識が本番では条件を変えて出題されます。

問題文がこう変わったら	正解はこう変わる
「負荷のピーク時刻が不定期で予測できない」	ターゲット追跡スケーリング（CPU 使用率や ALB のリクエスト数）が正解軸に。
「過去の履歴からAWS に負荷を予測させて先回りスケールさせたい」	予測スケーリング（Predictive Scaling）が正解軸に。
「メモリ使用率を条件にスケールさせたい」	CloudWatch エージェントでカスタムメトリクスを発行することが前提条件として問われる。
「スケールアウト直後に過剰なスケーリングが連発してしまう」	クールダウン期間／ウォームアップ時間の調整が正解軸に（本問の選択肢 D が正解になる場面）。

関連サービスの解説

Amazon EC2
Amazon EC2 Auto Scaling
Amazon EventBridge
AWS Auto Scaling