AWS認定資格 WEB問題集＆徹底解説
CloudOpsエンジニア -アソシエイト
問題文と選択肢
この要件を満たすために、CloudOps 管理者はどのアクションを実行する必要がありますか？
- ピーク時に必要な容量を満たすために、Auto Scaling グループのインスタンスの最大数を増やす。
- ピーク時に必要な容量を満たすために、Auto Scaling グループのインスタンスの最小数を増やす。
- Auto Scaling グループを更新して、同じ AWS リージョン内の 2 つ目のアベイラビリティーゾーンでも新しいインスタンスを起動できるようにする。
- Auto Scaling グループを更新して、2 つ目の AWS リージョンのアベイラビリティーゾーンで新しいインスタンスを起動する。
A. ピーク時に必要な容量を満たすために、Auto Scaling グループのインスタンスの最大数を増やす。
最大インスタンス数はスケールアウトの上限を決めるだけで、インスタンスの配置先 AZ は変わらない。
単一 AZ に何台並べても、そのアベイラビリティーゾーンに障害が発生すれば全インスタンスが同時に失われる（単一障害点のまま）。
ピーク時の容量（スケーラビリティ）の話であって、高可用性の要件には応えていない。
B. ピーク時に必要な容量を満たすために、Auto Scaling グループのインスタンスの最小数を増やす。
最小インスタンス数を増やすと常時稼働台数が増えるためコストは上がるが、やはり全台が同じ AZ 内にとどまる。
AZ 障害時にはまとめて停止し、Auto Scaling が代替インスタンスを起動しようとしても起動先の AZ が 1 つしかないため復旧できない。
台数（冗長性）と配置の分散（可用性）は別の概念であり、要件を満たさない。
C. Auto Scaling グループを更新して、同じ AWS リージョン内の 2 つ目のアベイラビリティーゾーンでも新しいインスタンスを起動できるようにする。
Auto Scaling グループに同一リージョン内の 2 つ目のアベイラビリティーゾーン（のサブネット）を追加すると、Auto Scaling はインスタンスを AZ 間で自動的に均等配置し、Application Load Balancer も複数 AZ のターゲットへトラフィックを分散する。
片方の AZ が障害を起こしても、もう一方の AZ のインスタンスがリクエストを処理し続け、Auto Scaling が正常な AZ で代替インスタンスを補充する。
ALB は複数の AZ にサブネットを持たせる構成が前提であり、追加コストもほぼ無く高可用性を実現できるため、これが正解。
D. Auto Scaling グループを更新して、2 つ目の AWS リージョンのアベイラビリティーゾーンで新しいインスタンスを起動する。
Amazon EC2 Auto Scaling グループは単一のリージョン内でしか動作せず、複数リージョンにまたがるグループは作成できない（AZ は同一リージョン内のものしか指定できない）。
また Application Load Balancer もリージョン内のリソースであり、そもそも設定として成立しない。
リージョン障害への備え（ディザスタリカバリ）は、別リージョンに構成一式を用意し Route 53 でフェイルオーバーさせるなど別のアーキテクチャで行うもので、本問の「高可用性にする」最小の対応としては過剰かつ実現不能。
高可用性＝マルチ AZ。台数を増やしても同じ AZ が落ちれば全滅。リージョンをまたぐのは DR の話。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 現状は単一のアベイラビリティーゾーンで稼働している | AZ 障害が単一障害点。解決には配置の分散が必要で、台数調整では解消しない →選択肢（A・B）を消す |
| 「高可用性にする」ことが要件（容量不足の話ではない） | 最大数・最小数はスケーラビリティとコストの調整項目であり、可用性の指標ではない →選択肢（A・B）を消す |
| Application Load Balancer の背後で稼働している | ALB は複数 AZ のターゲットへ自動的に分散できるため、AZ を増やすだけで冗長化が完成する →選択肢（C）が正解 |
| Amazon EC2 Auto Scaling グループを使用している | Auto Scaling グループは単一リージョン内の複数 AZにまたがれるが、リージョンはまたげない →選択肢（D）を消す |
ひっかけポイント
- 選択肢 A・B はどちらも「ピーク時に必要な容量を満たすために」と問題文にない目的を語っている。要件は容量ではなく可用性で、要件のすり替えがひっかけ
- 最小台数を増やす（B）は「常に複数台動いているから安心」に見えるが、同じ AZ に並べた冗長化は AZ 障害で無意味
- 選択肢 D の「2 つ目の AWS リージョンの AZ」は、1 つの Auto Scaling グループでは設定できない。マルチリージョンは高可用性ではなく DR の論点
- 高可用性（複数 AZ）とディザスタリカバリ（複数リージョン）は別レイヤーの対策。設問がどちらを求めているかを読み分ける
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「リージョン全体の障害にも耐えられるようにしたい」 | 別リージョンに環境を構築し、Route 53 のフェイルオーバールーティングで切り替える構成が正解軸に。 |
| 「アクセス増加時に自動的に台数を増やしたい」 | ターゲット追跡スケーリングポリシーや最大数の引き上げが正解に。 |
| 「AZ 間でインスタンス数に偏りが生じている」 | Auto Scaling のAZ リバランス（キャパシティのリバランス）の挙動が問われる。 |
| 「ステートフルなセッション情報が失われる」 | ALB のスティッキーセッションではなく、ElastiCache などへのセッション外出しが正解軸に。 |
| 「データベースも単一 AZで動いている」 | Amazon RDS のマルチ AZ 配置への変更が正解に。 |
この要件を満たすために、CloudOps 管理者はどのアクションを実行する必要がありますか？
- ピーク時に必要な容量を満たすために、Auto Scaling グループのインスタンスの最大数を増やす。
- ピーク時に必要な容量を満たすために、Auto Scaling グループのインスタンスの最小数を増やす。
- Auto Scaling グループを更新して、同じ AWS リージョン内の 2 つ目のアベイラビリティーゾーンでも新しいインスタンスを起動できるようにする。
- Auto Scaling グループを更新して、2 つ目の AWS リージョンのアベイラビリティーゾーンで新しいインスタンスを起動する。