【CLF-C02 試験対策問題 第3問】高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）

「台数を増やしたり、大きなインスタンスにしたりすれば、止まりにくくなるはずです。それでは足りないのですか」
「バックアップを毎日取っていれば、障害が起きても安心だと思っていました」

AWS Certified Cloud Practitioner（試験コード CLF-C02。以下 CLF）では、障害が起きる範囲（ここでは AZ 全体）に耐えられる設計かどうかを問う問題がよく出ます。今回は、EC2 と RDS で作った受注システムを、AZ 全体に障害が起きても止めないための設計を選びます。

この記事は、CLF の練習問題を1問ずつ解説する連載の第3問です。問題は筆者が試験の範囲に合わせて作ったもので、実際の試験の問題ではありません。まず自分で答えを選んでから、解説を読んでください。

▶ この回の内容は、YouTube の動画（約4分）でも見られます（記事の最後にも埋め込んであります）。

---

問題

ある企業は、社内の受注システムを Amazon EC2 と Amazon RDS で構築しています。データセンター単位の停電などでアベイラビリティーゾーン（AZ）全体に障害が起きても、受注を止めたくないと考えています。最も適切な設計はどれですか。

• A. 1つの AZ の中で EC2 の台数を増やし、Auto Scaling で台数を保つ
• B. EC2 の AMI と RDS のスナップショットを、毎日取得しておく
• C. 1つの AZ に、より大きなインスタンスタイプの EC2 を配置する
• D. EC2 を複数の AZ に配置して Elastic Load Balancing で振り分け、RDS をマルチ AZ 配置にする

答えを決めたら、下を開いてください。

正解を見る（クリックで開きます）

正解：D

EC2 を複数の AZ に配置して Elastic Load Balancing で振り分け、RDS をマルチ AZ 配置にすると、AZ 全体が止まっても、アプリケーションとデータベースの両方が別の AZ で動き続けます。

---

正解は D

正解は D です。

• EC2：複数の AZ に配置し、Elastic Load Balancing で振り分ける
• RDS：マルチ AZ 配置にする

AZ 全体が止まっても、アプリケーションとデータベースの両方が、別の AZ で動き続けます。ここから、選択肢を1つずつ見ていきます。

---

選択肢ごとの解説

A：台数を増やしても AZ は1つ（誤り）

台数を増やせば、図の左のように、1台の故障には耐えられます。Auto Scaling が、代わりのインスタンスを起動して、台数を保ちます。

しかし、すべてのインスタンスが同じ AZ にあります。図の右のように、AZ 全体に障害が起きると、すべて同時に止まってしまいます。同じ AZ に何台並べても、AZ 全体の障害には耐えられません。

B：バックアップは復旧の手段（誤り）

EC2 の AMI や、RDS のスナップショットは、障害の後に復旧するためのバックアップです。図の下のように、AZ の障害が起きるとシステムは止まり、バックアップから復元して再開するまでの間、受注は止まったままです。

止めないための仕組みではありません。

C：大きくしても1台・1つの AZ（誤り）

より大きなインスタンスタイプにするのは、図の左の、垂直スケーリングです。1台の性能は上がります。

しかし、1つの AZ に1台のままです。図の右のように、AZ の障害が起きると、その1台ごと止まってしまいます。垂直スケーリングは、1台の性能を上げるだけです。

D：EC2 も RDS も複数の AZ に（正解）

図は、EC2 を2つの AZ に置いた構成です。Elastic Load Balancing（ELB）が、利用者からの通信を、動いている AZ に振り分けます。

RDS のマルチ AZ 配置では、別の AZ に、同期したスタンバイを置きます。障害が起きると、スタンバイに自動で切り替わります。AZ-a が止まっても、AZ-b の EC2 と RDS で、受注を続けられます。

---

止めない／失わない・戻せる

2つの対策の違いを整理しておきます。目的が 止めないこと ならマルチ AZ、失わない・戻せること ならバックアップです。どちらも大切ですが役割が違うので、試験では、問題の目的がどちらかで見分けます。

観点	止めない（高可用性）	失わない・戻せる（バックアップ）
仕組み	複数の AZ に分けて配置（マルチ AZ）	AMI・スナップショットを取得
AWS の例	EC2 を複数 AZ ＋ ELB、RDS マルチ AZ	EC2 の AMI、RDS のスナップショット
障害のとき	別の AZ で稼働を続ける	復元するまで止まる

---

ポイント

• AZ 全体の障害でも止めない ＝ 複数の AZ（EC2 ＋ ELB、RDS マルチ AZ）
• 同じ AZ で台数を増やす・大きくするだけでは、AZ の障害 で止まる
• 「止めない」→ マルチ AZ、「失わない・戻せる」→ バックアップ

複数の AZ に分けて置く考え方と、RDS のマルチ AZ 配置は、講座の記事で詳しく解説しています。

• 講座の第03回③「高可用性と複数リージョン」（連載の入口のページから）
• 講座の第07回④「RDS とマルチ AZ 配置」（連載の入口のページから）

講座の全14回は、連載の入口のページから順に読めます。

---

動画で見る

この回の内容を、YouTube の動画（約4分）でも解説しています。

連載の全回は、YouTube の再生リスト「CLF-C02 試験対策問題」にまとめています。

連載「CLF-C02 試験対策問題」

全回の目次と、読む順番・目的別の読み方は、CLF-C02 試験対策問題の入口のページにまとめています。

1. 第1問 初期費用をかけずに始めるコストの利点（従量課金・規模の経済）
2. 第2問 数分でグローバルに展開（世界同時公開と低い遅延）
3. 第3問 高可用性（EC2 の複数 AZ 配置と RDS マルチ AZ）（この記事）
4. 第4問 クラウドの俊敏性（数分で作成・すぐに削除）
5. 第5問 責任共有モデル（EC2 へのリホストで AWS に任せられること）
6. 第6問 数時間だけのアクセスのピークに備える（EC2 Auto Scaling・オンデマンド）
7. 第7問 Well-Architected の6つの柱（信頼性・パフォーマンス効率）
8. 第8問 信頼性の柱の設計原則（自動で復旧・水平方向のスケール）
9. 第9問 持続可能性の柱の設計原則（使用率の最大化・マネージドサービス）
10. 第10問 AWS CAF の変革ジャーニーのフェーズ（構想・連携・ローンチ・スケール）
11. 第11問 AWS CAF のパースペクティブ（構成管理・パッチ管理はオペレーション）
12. 第12問 移行のビジネスケース（Migration Evaluator）
13. 第13問 AWS CAF のパースペクティブ（役割と組織の変化は人材）
14. 第14問 サーバーをそのまま EC2 に移す（AWS Transform MGN）
15. 第15問 ファイルの移行（AWS DataSync）
16. 第16問 移行戦略の7つの R（リパーチェス・SaaS への乗り換え）
17. 第17問 適切なサイズ設定（CPU は余り、メモリが不足）
18. 第18問 責任共有モデル（Lambda と RDS）
19. 第19問 最小権限の原則（IAM のポリシーと SCP）
20. 第20問 責任共有モデル（EC2 と S3、AWS の責任）
21. 第21問 共有統制の例（責任共有モデルの IT 統制）
22. 第22問 コンプライアンスの資料と契約（AWS Artifact）
23. 第23問 脅威の検出（Amazon GuardDuty）
24. 第24問 脆弱性の継続的なスキャン（Amazon Inspector）
25. 第25問 S3 の機密データの検出（Amazon Macie）
26. 第26問 S3 の保管時の暗号化とキーの管理
27. 第27問 だれが操作したかを調べる（AWS CloudTrail）
28. 第28問 IAM ユーザーの認証情報の一覧（認証情報レポート）
29. 第29問 EC2 のアプリケーションに権限を与える（IAM ロール）
30. 第30問 データベースのパスワードの自動ローテーション（AWS Secrets Manager）