Cloud Practitioner で混同しやすい「障害対策」の整理
AWS Certified Cloud Practitioner では、障害対策に関する設問で「自動フェイルオーバー」「自動復旧」「自動置換」「ルーティング切替」を区別できることが重要です。特に Amazon RDS の Read Replica と Multi-AZ、そして Amazon EC2 Auto Scaling は役割が似て見えて混同されやすい論点です。
結論から言うと、RDS Read Replica は読み取り性能向上のための複製であり、標準的な RDS DB インスタンスの構成ではプライマリ障害時に自動昇格しません。一方、RDS Multi-AZ は高可用性のための構成で、障害時には自動フェイルオーバーします。また、EC2 Auto Scaling は壊れたインスタンスを待機系へ切り替えるのではなく、新しい EC2 を起動して置き換える仕組みです。
まず押さえたい4つの用語
- 自動フェイルオーバー：待機系やレプリカへ役割を切り替えて、サービス継続を図ること。代表例は RDS Multi-AZ です。
- 自動復旧：同じインスタンスを別ホストで復旧させること。代表例は EC2 Automatic Instance Recovery です。
- 自動置換：異常なインスタンスを終了し、新しいインスタンスを起動して台数を維持すること。代表例は EC2 Auto Scaling です。
- ルーティング切替：壊れた先には流さず、正常な先へ通信を回すこと。代表例は ELB と Route 53 DNS Failover です。
試験向け比較表
| サービス / 機能 | 主な目的 | 障害時の動き | 自動か | 試験での覚え方 |
|---|---|---|---|---|
| Amazon RDS Read Replica | 読み取り負荷分散、読み取り性能向上 | プライマリ障害時に自動昇格しない。必要なら手動で Promote する | いいえ | 「Read Replica = 読み取り性能」 |
| Amazon RDS Multi-AZ | 高可用性 | スタンバイ側へ自動フェイルオーバーする | はい | 「Multi-AZ = 高可用性」 |
| Amazon Aurora Replica | 高可用性 + 読み取り性能 | 障害時に Aurora Replica が自動昇格の候補になる | はい | 「Aurora は通常の RDS Read Replica と性質が違う」 |
| Amazon EC2 Auto Scaling | 台数維持、自己修復、スケーリング | 不健全な EC2 を置き換えるために新しいインスタンスを起動する | はい | 「作り直して維持する」 |
| EC2 Automatic Instance Recovery | 単一 EC2 の可用性向上 | 基盤障害時に同じインスタンスを別ホストで復旧する | はい（条件あり） | 「置換ではなく復旧」 |
| Elastic Load Balancing | トラフィック分散 | 不健全ターゲットには流さず、正常なターゲットへルーティングする | はい | 「振り分け役」 |
| Amazon Route 53 DNS Failover | DNS レベルでの切替 | ヘルスチェック結果に基づいて正常なリソースへ名前解決を切り替える | はい（設定時） | 「DNS で切り替える」 |
| Amazon ElastiCache Multi-AZ | キャッシュの高可用性 | プライマリ障害時にリードレプリカへ自動フェイルオーバーする | はい | 「Redis/Valkey の HA」 |
最重要ポイント1：RDS Read Replica と Multi-AZ は目的が違う
Read Replica は性能対策、Multi-AZ は可用性対策です。この切り分けは Cloud Practitioner で非常に重要です。Read Replica はプライマリ DB の更新を複製し、主に読み取りを分散して性能を上げるために使います。一方で、Multi-AZ は障害発生時に待機系へ切り替えることを目的としています。
そのため、「データベースの可用性を高めたい」という要件に対して、試験で最も素直な答えは通常 RDS Multi-AZ です。逆に、「読み取りが増えてきたので性能を上げたい」という要件なら RDS Read Replica が候補になります。
最重要ポイント2：EC2 Auto Scaling は“昇格”ではなく“置換”
EC2 Auto Scaling は、Auto Scaling グループ内のインスタンスに対してヘルスチェックを行い、不健全と判断されたインスタンスを置き換えます。ここで重要なのは、待機機が主役に昇格するのではなく、新しい EC2 を起動して desired capacity を保つという点です。データベースのフェイルオーバーとは考え方が異なります。
たとえば Web サーバーを複数台で動かしているなら、ELB が正常なインスタンスへトラフィックを流し、Auto Scaling が不健全インスタンスを置き換える、という組み合わせがよく使われます。これは ステートレスなアプリケーション層 と相性がよい構成です。
最重要ポイント3：EC2 Automatic Instance Recovery は Auto Scaling と別物
EC2 Automatic Instance Recovery は、AWS が基盤となるハードウェアやソフトウェアの障害を検出したときに、インスタンスの可用性を自動的に復元する仕組みです。これは 同じインスタンスを復旧する 発想であり、新しいインスタンスを作る Auto Scaling とは別物です。
試験では「EC2 の障害に対して自動で復旧できる機能はどれか」という問いで、Auto Scaling と Automatic Instance Recovery を区別できるかがポイントになります。Auto Scaling は“台数維持”、Automatic Instance Recovery は“インスタンス復旧”と覚えると整理しやすくなります。
最重要ポイント4：ELB と Route 53 は“直す”のではなく“流し先を変える”
Elastic Load Balancing はターゲットグループのヘルスチェックを行い、正常なターゲットだけにリクエストを送ります。これは障害インスタンスを修理する機能ではなく、正常な先へ通信を振り分ける機能です。
Route 53 DNS Failover も同様に、ヘルスチェックに基づいて正常なリソースへ名前解決を返す仕組みです。つまり、ELB も Route 53 も本質は「トラフィックの切替」であり、「DB の自動昇格」や「EC2 の自動復旧」とは種類が違います。
試験直前の暗記フレーズ
- Read Replica は速くする。自動昇格しない。
- Multi-AZ は止まりにくくする。自動フェイルオーバーする。
- Auto Scaling は作り直す。不健全な EC2 を置換する。
- Automatic Instance Recovery は復旧する。同じインスタンスを回復させる。
- ELB / Route 53 は流し先を変える。通信を正常な先へ回す。
よくあるひっかけ
- 「RDS の可用性を上げたい」→ Read Replica ではなく Multi-AZ をまず考える。
- 「EC2 の障害に備えたい」→ Auto Scaling は置換、Automatic Instance Recovery は復旧。
- 「ALB があるからインスタンスは復旧される」→ ALB は ルーティング をするだけで、復旧や置換そのものは別機能。
- 「Aurora Replica も通常の RDS Read Replica と同じ」→ Aurora は自動フェイルオーバーの挙動が異なる ため、同一視しない。
まとめ
Cloud Practitioner の障害対策は、サービス名を丸暗記するよりも、何を自動でしてくれるのかで整理すると覚えやすくなります。RDS Read Replica は「読み取り性能」、RDS Multi-AZ は「自動フェイルオーバー」、EC2 Auto Scaling は「自動置換」、EC2 Automatic Instance Recovery は「自動復旧」、ELB と Route 53 は「通信先の切替」と整理すれば、設問で迷いにくくなります。