AWS認定資格 WEB問題集＆徹底解説
ソリューションアーキテクト-プロフェッショナル
問題文と選択肢
• Elastic IP アドレスを持つ単一の Amazon EC2 インスタンスでホストされているウェブ層
• Application Load Balancer (ALB) の背後で実行される複数の EC2 インスタンスでホストされるアプリケーション層
• 単一の EC2 インスタンスで実行される MySQL データベース
運用チームの分析により、データベースが CPU 使用率のスパイクによりボトルネックとなっていることが判明しました。また、ワークロードは日中にトラフィックが集中し、夜間はほぼアイドル状態です。企業は、データベースのパフォーマンスを向上させ、運用オーバーヘッドを削減しつつ、コストを最適化したいと考えています。
これらの要件を最も効果的に満たすソリューションはどれですか？
- MySQL データベースを Multi-AZ 構成の Amazon RDS for MySQL に移行し、リードレプリカを追加する
- ウェブ層を Auto Scaling グループと ALB の背後に配置し、可用性を向上させる
- MySQL データベースを Amazon Aurora Serverless v2 に移行し、自動スケーリングを構成する
- すべての EC2 インスタンスを最新世代の Graviton3 インスタンスタイプに移行する
A. MySQL データベースを Multi-AZ 構成の Amazon RDS for MySQL に移行し、リードレプリカを追加する
Amazon RDS for MySQL への移行はマネージド化として正しく、Multi-AZ で可用性も上がる。しかし RDS はインスタンスクラスを固定でプロビジョニングするため、夜間のアイドル時間帯もピークに合わせた容量に課金され続ける。
負荷変動に追随するにはインスタンスクラスの手動変更（またはスケジュールによる自動化）が必要で、コスト最適化の要件を満たしきれない。
またリードレプリカは読み取り負荷の分散には効くが、書き込みを含む CPU スパイクへの根本対策にはならない。要件は満たすが最適ではない典型的な次点の選択肢。
B. ウェブ層を Auto Scaling グループと ALB の背後に配置し、可用性を向上させる
ウェブ層を Auto Scaling グループと ALB の背後に置く構成は、単一 EC2 という単一障害点の解消としては正しい改善である。
しかし本問で運用チームが特定したボトルネックはデータベースの CPU スパイクであり、ウェブ層を冗長化してもデータベースの性能は 1 ミリも改善しない。
「データベースのパフォーマンスを向上させる」という主要件に応えていないため不正解。
C. MySQL データベースを Amazon Aurora Serverless v2 に移行し、自動スケーリングを構成する
Amazon Aurora Serverless v2 は、負荷に応じて ACU（Aurora Capacity Unit）を秒単位で細かく自動スケールする。日中のトラフィック集中時には容量を増やして CPU スパイクを吸収し、夜間のアイドル時には最小容量まで縮小するため、ピークに合わせた常時プロビジョニングが不要になりコストを最適化できる。
フルマネージドであるためパッチ適用・バックアップ・フェイルオーバーが自動化され、EC2 上で MySQL を自前運用する運用オーバーヘッドが解消される。
MySQL 互換であるためアプリケーションの変更を抑えて移行でき、パフォーマンス向上・運用負荷削減・コスト最適化の 3 要件すべてを同時に満たす唯一の選択肢。
D. すべての EC2 インスタンスを最新世代の Graviton3 インスタンスタイプに移行する
Graviton ベースのインスタンスへの移行はコストパフォーマンスの改善策として有効な場面もあるが、MySQL を EC2 上で自前運用し続ける構図は変わらないため、パッチ適用・バックアップ・フェイルオーバーといった運用オーバーヘッドは削減されない。
インスタンスサイズは固定のままなので、夜間アイドル時の無駄なコストもそのまま残る。
さらに ARM アーキテクチャへの移行にはアプリケーションの互換性検証が必要で、要件に対して得られる効果が小さい。
変動の大きい DB は Aurora Serverless v2。秒単位で ACU が伸縮し、アイドル時は縮む。EC2 上の MySQL 自前運用は真っ先に卒業する。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| データベースが CPU 使用率のスパイクでボトルネックになっている | 対策はデータベース層に打つ必要がある。ウェブ層の冗長化では解決しない →選択肢（B）を消す |
| 日中はトラフィック集中、夜間はほぼアイドル（大きな負荷変動） | 容量を自動で伸縮できる Aurora Serverless v2 が最適。固定サイズのインスタンスではピークに合わせた課金が続く →選択肢（C）が正解 |
| 運用オーバーヘッドを削減したい | EC2 上の自前 MySQL はマネージドサービスへ移行する。インスタンスタイプを変えるだけでは運用負荷は減らない →選択肢（D）を消す |
| コストを最適化したい | RDS Multi-AZ ＋リードレプリカは常時稼働インスタンスの課金が続き、アイドル時間帯の無駄が残る →選択肢（A）は候補だが劣後 |
ひっかけポイント
- 選択肢 A（RDS Multi-AZ ＋リードレプリカ）はマネージド化・可用性向上として正しいため強力な引っかけ。しかし「夜間はほぼアイドル」という記述に応えられるのは、容量が縮む Serverless v2 だけ
- リードレプリカは読み取り負荷の分散にしか効かない。問題文は「CPU 使用率のスパイク」としか書いておらず、書き込み由来なら効果が無い
- 選択肢 B は「単一 EC2 のウェブ層＋Elastic IP」といういかにも直したくなる構成を突いてくる。改善自体は正しいが、設問が求めた要件（DB 性能）ではない
- 「最新世代の Graviton に移行すればコスト効率が上がる」は一般論として正しく聞こえるが、自前運用の DB を EC2 に残したままでは運用オーバーヘッド削減の要件を満たせない
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「負荷は一定で予測可能。コストを最小化したい」 | プロビジョンド（Aurora / RDS）＋リザーブドインスタンスが正解軸に。Serverless は割高になり得る。 |
| 「読み取りクエリが大半で、レポート用の負荷が本番を圧迫している」 | リードレプリカ（Aurora レプリカ）への読み取りオフロードが正解に浮上する。 |
| 「数分〜数時間まったくアクセスが無い開発環境のコストを削減したい」 | Aurora Serverless v2 のゼロ ACU への自動停止や、RDS の停止／スケジュール起動が正解軸に。 |
| 「データベースの可用性（フェイルオーバー）が主要件」 | Multi-AZ 構成（RDS Multi-AZ / Aurora のマルチ AZ レプリカ）が正解軸に。 |
| 「アプリケーションが大量の短命コネクションを張って DB を圧迫している」 | Amazon RDS Proxy によるコネクションプーリングが正解軸に。 |
• Elastic IP アドレスを持つ単一の Amazon EC2 インスタンスでホストされているウェブ層
• Application Load Balancer (ALB) の背後で実行される複数の EC2 インスタンスでホストされるアプリケーション層
• 単一の EC2 インスタンスで実行される MySQL データベース
運用チームの分析により、データベースが CPU 使用率のスパイクによりボトルネックとなっていることが判明しました。また、ワークロードは日中にトラフィックが集中し、夜間はほぼアイドル状態です。企業は、データベースのパフォーマンスを向上させ、運用オーバーヘッドを削減しつつ、コストを最適化したいと考えています。
これらの要件を最も効果的に満たすソリューションはどれですか？
- MySQL データベースを Multi-AZ 構成の Amazon RDS for MySQL に移行し、リードレプリカを追加する
- ウェブ層を Auto Scaling グループと ALB の背後に配置し、可用性を向上させる
- MySQL データベースを Amazon Aurora Serverless v2 に移行し、自動スケーリングを構成する
- すべての EC2 インスタンスを最新世代の Graviton3 インスタンスタイプに移行する