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

会員登録/ログイン

正解

A. ターゲット追跡スケーリングポリシー（Target Tracking Scaling Policy）を使用し、集約CPU使用率の目標値を60%に設定する

ターゲット追跡スケーリングポリシーは、維持したいメトリクスの目標値（ここでは平均 CPU 使用率 60%）を指定するだけで、ASG が実測値を目標値に近づけるようインスタンス数を自動で増減させる。
必要な CloudWatch アラームはポリシー作成時に自動生成・自動管理され、スケールアウト／スケールインの量も AWS 側が算出するため、運用者が閾値やステップを設計する必要がない。
「常に60%前後に維持したい」「最もシンプルかつ効率的に」という本問の要件にそのまま対応する、唯一の選択肢。

B. ステップスケーリングポリシー（Step Scaling Policy）を使用し、CPU使用率が60%を超えたときにインスタンスを段階的に追加・削除するアラームを構成する

ステップスケーリングポリシーは、アラームの超過幅に応じて「何台増やすか」を段階（ステップ）として自分で定義する方式。細やかな制御はできるが、閾値・ステップ調整量・ウォームアップ時間をすべて設計・チューニングする必要がある。
そもそもこの方式は「目標値に収束させる」仕組みを持たず、60%を維持するという要件を満たすには利用者側でロジックを作り込むことになる。
要件の「最もシンプル」に反するため、より単純なターゲット追跡が存在する本問では最適解にならない。

C. スケジュールスケーリングポリシー（Scheduled Scaling Policy）を使用し、ピーク時間帯に合わせてインスタンス数を事前に増減するスケジュールを設定する

スケジュールスケーリングは、あらかじめ決めた日時にインスタンス数（希望容量・最小／最大）を変更するもので、負荷の増減が時間帯で予測できる場合に有効。
本問は SQS キューに届く受注データの量に応じて負荷が変動する予測困難なワークロードであり、時刻ベースでは CPU 使用率を60%前後に維持できない。
メトリクスを一切見ないため、要件そのものに合致しない。

D. シンプルスケーリングポリシー（Simple Scaling Policy）を使用し、CloudWatchアラームのトリガーごとに固定数のインスタンスを追加または削除する

シンプルスケーリングポリシーは、CloudWatch アラームの発報ごとに固定数（または固定割合）のインスタンスを増減し、クールダウン期間が終わるまで次のスケーリングを行わないという古い方式。
目標値へ収束させる仕組みがなく、増減量も一定のため60%を狙って維持することはできない。
クールダウン中は追加の負荷変動に反応できず応答も遅れるため、AWS も現在はターゲット追跡またはステップスケーリングの利用を推奨している。

正解への思考ルート

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

要件	判断ポイント
CPU 使用率を常に60%前後に「維持」したい	目標値を維持する仕組みを持つのはターゲット追跡だけ。他は増減の「操作」を定義する方式 →選択肢（A）が正解
最もシンプルに実現したい（設定・運用負荷が小さい）	ターゲット追跡は目標値を1つ指定するだけでアラームも自動生成。ステップスケーリングは閾値・ステップの設計が必要 →選択肢（B）を消す
ワークロードの変動に応じて自動調整（SQS の受注量は変動する）	時刻ベースのスケジュールでは予測できない負荷変動に追随できない →選択肢（C）を消す
目標値への収束と応答性	固定数を増減するだけの方式はクールダウンで待たされ、目標値に収束させられない →選択肢（D）を消す

ひっかけポイント

• 「CPU 使用率が60%を超えたらアラーム」（選択肢 B）は一見要件に合うが、60%は"超えたら動く閾値"であって"維持する目標値"ではない。設問の「60%前後に維持」がターゲット追跡を指すキーワード
• 問題文の SQS に引っ張られてキュー長ベースのスケーリングを探しがちだが、本問が維持したいメトリクスはCPU 使用率と明記されている。惑わされないこと
• シンプルスケーリング（選択肢 D）は名前が「シンプル」なので「最もシンプル」の要件に合いそうに見えるが、これはレガシー方式で、AWS はターゲット追跡／ステップスケーリングを推奨している
• ターゲット追跡ではCloudWatch アラームを手動作成しない（ポリシーが自動生成・自動管理する）。「アラームを構成する」と書かれた選択肢は、その時点でターゲット追跡ではない

出題バリエーション

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

問題文がこう変わったら	正解はこう変わる
「SQS のキュー内メッセージ数に応じて、1インスタンスあたりの処理件数を一定に保ちたい」	バックログ／インスタンス数のカスタムメトリクスを作り、それを対象にしたターゲット追跡が正解軸に。
「負荷が毎日決まった時間帯に急増することが分かっている」	スケジュールスケーリング（＋ターゲット追跡の併用）が正解に浮上。
「CPU が閾値をどれだけ超えたかで追加台数を変えたい（80%超なら+4台、60%超なら+1台）」	ステップスケーリングが正解に入れ替わる。
「スケールイン時に処理中のメッセージを取りこぼしたくない」	ライフサイクルフックや終了保護、スケールイン保護が論点に変わる。
「EC2 ではなく Lambda で SQS を処理したい」	ASG は不要。SQS イベントソースマッピングの同時実行スケーリングが論点に。

関連サービスの解説

Amazon CloudWatch
Amazon EC2
Amazon Simple Queue Service (Amazon SQS)