メインコンテンツへ移動
SAA-C03Resilient Architectures難易度標準

SAA-010

Webアプリケーションを複数AZに分散したEC2で稼働させ、障害のあるインスタンスへトラフィックを送らないようにしたいです。最も適した構成はどれですか?

選択肢

解説と正解

解説と正解を読む(先に自分で回答してから開くのがおすすめです)

正解:B. Application Load BalancerとAuto Scaling Groupを複数AZで構成する

解説

ALBはヘルスチェックで正常なターゲットにトラフィックを振り分けます。Auto Scaling Groupを複数AZに広げることで、インスタンス障害やAZ障害に強い構成になります。

選択肢ごとの解説

A. CloudWatch Logsだけを有効化する

ログ収集だけではトラフィック制御や高可用性は実現できません。

B. Application Load BalancerとAuto Scaling Groupを複数AZで構成する

正解です。高可用性Webアプリの基本構成です。

C. S3バケットを作成してEC2の代わりにする

S3は静的ファイル保存には使えますが、EC2上の動的Webアプリをそのまま置き換える選択肢ではありません。

D. 単一AZのEC2インスタンスにElastic IPを付与する

単一AZ構成ではAZ障害に弱いです。

実務での使いどころ

Application Load Balancer(ALB)と Auto Scaling Group(ASG)を複数 AZ に展開する構成は、AWS における高可用性 Web アプリの基本パターンである。ALB はターゲットグループに登録された EC2 インスタンスへ、設定されたヘルスチェック(HTTP 応答コード等)に基づきトラフィックを振り分ける。ヘルスチェックに失敗したインスタンスは自動的にターゲットから外され、復旧後に再投入される。ASG を複数 AZ で構成しておくと、AZ 障害時にも別 AZ のインスタンスが残るため、サービス全体の停止を防げる。 ASG はメトリクス(CPU 使用率、リクエスト数、カスタムメトリクス等)に基づきインスタンス数を動的に調整するスケーリングポリシー(Target Tracking、Step Scaling、Predictive Scaling)を持つ。また、Launch Template でインスタンス起動時のユーザーデータ・IAM ロール・AMI 等を定義でき、Immutable Infrastructure 的な運用と相性が良い。ALB は Layer 7 でパスベース/ホストベースのルーティングや、HTTP/HTTPS / WebSocket / gRPC をサポートしており、Network Load Balancer(Layer 4、超低遅延)や CloudFront(CDN、エッジ配信)と用途で使い分ける。 SAA-C03 では「複数 AZ に分散」「障害のあるインスタンスへトラフィックを送らない」要件で ALB + ASG(Multi-AZ)が正解となる。単一 AZ + Elastic IP は AZ 障害に弱い、S3 で EC2 を置き換える選択肢は動的処理を担えない、CloudWatch Logs だけではトラフィック制御ができない、と誤答パターンも整理しやすい。ALB / NLB / CloudFront の使い分け、ASG のスケーリングポリシー設計、Launch Template と Launch Configuration の違いは上位試験でさらに踏み込んで問われる。

関連リンク

関連サービス