AWS認定資格 WEB問題集＆徹底解説
ソリューションアーキテクト-プロフェッショナル
問題文と選択肢
現在のアプリケーション構成：
- Web 層：ロードバランサーと複数の Linux Apache Web サーバー
- データベース層：MySQL データベースをホストする Linux サーバー
- オンプレミスと AWS 間は既存の AWS Direct Connect 接続が利用可能
- S3 バケットを使用した静的ウェブサイトホスティングと Route 53 DNS フェイルオーバーの設定
- EC2 インスタンスと Auto Scaling を使用した Web 層の AWS への拡張、および Application Load Balancer によるトラフィック分散。データベースはオンプレミスを継続利用
- CloudFront ディストリビューションを設定し、オンプレミス環境をオリジンとして動的・静的コンテンツのキャッシュによりトラフィックをオフロード
- VM Import/Export を使用した Web サーバーの AWS への移行と、MySQL データベースの Amazon RDS への移行および Multi-AZ 構成の実装
A. S3 バケットを使用した静的ウェブサイトホスティングと Route 53 DNS フェイルオーバーの設定
Amazon S3 の静的ウェブサイトホスティングはサーバーサイド処理（PHP）を実行できないため、動的な Web アプリケーションをそのまま載せられない。
「完全な機能を維持する」という要件に真っ向から反する。
Route 53 の DNS フェイルオーバーも、能力不足の解消ではなく障害時の退避（sorry ページ相当）にしかならない。
B. EC2 インスタンスと Auto Scaling を使用した Web 層の AWS への拡張、および Application Load Balancer によるトラフィック分散。データベースはオンプレミスを継続利用
ボトルネックは Web 層の処理能力であり、EC2 + Auto Scaling で Web 層だけを AWS 側に拡張すれば、既存の PHP コードをほぼそのまま動かしたまま短期間で処理能力を伸ばせる。
データベースは既存の Direct Connect 経由でオンプレミスのまま利用するため、データ移行・整合性検証・カットオーバー計画といった最も時間とリスクを要する作業を回避できる。
Application Load Balancer でトラフィックを分散し、負荷に応じてスケールアウトできるため、2週間という期限と「完全な機能維持」を両立できる唯一の選択肢。
C. CloudFront ディストリビューションを設定し、オンプレミス環境をオリジンとして動的・静的コンテンツのキャッシュによりトラフィックをオフロード
CloudFront はオリジンの前段に置いてキャッシュ可能なコンテンツをオフロードできるが、ログイン後のページや注文処理のようなユーザー固有の動的レスポンスはキャッシュが効かない。
結果として PHP の処理要求はオリジン（オンプレミス）に届き続け、処理能力不足という根本原因が残る。
静的アセットの負荷軽減という補助効果はあるが、単独では要件を満たさない。
D. VM Import/Export を使用した Web サーバーの AWS への移行と、MySQL データベースの Amazon RDS への移行および Multi-AZ 構成の実装
Web サーバーの VM Import/Export による移行に加え、MySQL から Amazon RDS へのデータベース移行（スキーマ・データ検証、カットオーバー、切り戻し計画）まで含むため、2週間という期限では現実的でない。
データベース移行にはダウンタイムとデータ整合性のリスクが伴い、「完全な機能を維持する」という要件とも相性が悪い。
RDS Multi-AZ 化自体は中長期的には正しい方向性だが、今回の緊急のスケール要件に対する解としては過剰かつ遅い。
構成図
利用者 ──▶ Application Load Balancer（AWS）
│
▼
EC2 Auto Scaling（Apache / PHP の Web 層）
│ 既存の Direct Connect
▼
オンプレミス MySQL データベース ◀── 既存のオンプレ Web サーバー
期限が短いなら「動かす範囲を最小に」。ボトルネックの層（Web 層）だけ AWS に伸ばし、DB は据え置く。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 2週間以内という厳しい期限 | 移行範囲が大きいほど間に合わない。DB 移行を含む全面移行（選択肢D）はカットオーバー計画だけで期限を食い潰す →選択肢（D）を消す |
| PHP による動的 Web アプリケーション | S3 静的ホスティングではサーバーサイド処理が動かない（選択肢A）。CloudFront も動的レスポンスはキャッシュできない（選択肢C） →選択肢（A・C）を消す |
| ボトルネックは Web 層の処理能力 | EC2 + Auto Scaling + ALB で Web 層だけを水平スケールさせるのが最短経路 →選択肢（B）が正解 |
| 既存の AWS Direct Connect 接続がある | AWS 側 Web 層 → オンプレ MySQL への低レイテンシ接続が既に用意されている＝ハイブリッド構成を示唆する強いヒント →選択肢（B）が正解 |
| 完全な機能を維持する | アプリの書き換えやデータ移行を伴わない案を選ぶ。リフト（拡張）だけを行い、シフトは後回しにする →選択肢（B）が正解 |
ひっかけポイント
- 「Direct Connect が利用可能」という一文は飾りではなくハイブリッド構成を選ばせるための伏線。この記述があるのに DB をオンプレに残す案を捨ててはいけない
- 選択肢 C は「動的・静的コンテンツのキャッシュ」と書いてもっともらしく見せているが、PHP のユーザー固有ページはキャッシュできず、オリジンの処理能力不足は解消しない
- 選択肢 D は AWS のベストプラクティス（RDS Multi-AZ）を含むため「正しい構成」に見えるのが罠。正しさではなく期限（2週間）とリスクで足切りされる
- DB をオンプレに残すと DX 経由のレイテンシが乗るが、短期での可用性回復を優先するトレードオフとして許容する。SAP では「理想形」より「制約の中の最適解」を問われる
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「期限が6か月あり、恒久的な構成にしたい」 | Web 層・DB 層とも AWS へ移行し、RDS Multi-AZ 化（選択肢D 相当）が正解軸に。 |
| 「サイトは静的コンテンツ中心で、動的処理はごくわずか」 | S3 + CloudFront でのオフロードが正解軸に浮上する。 |
| 「ボトルネックが Web 層ではなくデータベースの読み取りだった」 | リードレプリカや ElastiCache によるオフロードが正解軸に。 |
| 「Direct Connect が無く、インターネット経由の接続しかない」 | Site-to-Site VPN の帯域・レイテンシが論点になり、DB も含めた AWS 側への移行が現実解になり得る。 |
| 「トラフィック急増は年に数回のセール時だけ」 | 平常時はオンプレ、ピーク時のみ AWS 側を増やすクラウドバースティングの設計が問われる。 |
現在のアプリケーション構成：
- Web 層：ロードバランサーと複数の Linux Apache Web サーバー
- データベース層：MySQL データベースをホストする Linux サーバー
- オンプレミスと AWS 間は既存の AWS Direct Connect 接続が利用可能
- S3 バケットを使用した静的ウェブサイトホスティングと Route 53 DNS フェイルオーバーの設定
- EC2 インスタンスと Auto Scaling を使用した Web 層の AWS への拡張、および Application Load Balancer によるトラフィック分散。データベースはオンプレミスを継続利用
- CloudFront ディストリビューションを設定し、オンプレミス環境をオリジンとして動的・静的コンテンツのキャッシュによりトラフィックをオフロード
- VM Import/Export を使用した Web サーバーの AWS への移行と、MySQL データベースの Amazon RDS への移行および Multi-AZ 構成の実装