変更要約: SOA-C02 第2章を Associate 級に深掘り（比較表・シナリオ・FAQ・ひっかけ＋深掘り段落、図を日本語化）
2.2データベースの可用性とスケール
RDS のマルチ AZ（自動フェイルオーバーによる高可用性）とリードレプリカ（読み取りスケール）の違い、両者の使い分けを理解します。
データベースの可用性と性能は別の仕組みで対処します。高可用性＝マルチ AZ、読み取りスケール＝リードレプリカ、と役割を分けて理解しましょう。
2.2.1マルチ AZ とリードレプリカ
- マルチ AZ：別 AZ に同期スタンバイを持ち、障害時に自動フェイルオーバーする（高可用性）。スタンバイは読み取り不可。
- リードレプリカ：読み取り可能なコピーで読み取りをオフロードする（読み取りスケール）。非同期でフェイルオーバー用途ではない。
「高可用性/自動フェイルオーバー＝マルチ AZ（スタンバイは読めない）」「読み取り負荷の軽減＝リードレプリカ」 の取り違えは SOA の定番ひっかけです。
混同しやすいので役割で覚えます。マルチ AZ は可用性のための仕組みで、別 AZ に同期レプリケーションしたスタンバイを持ち、プライマリ障害時に DNS エンドポイントを切り替えて自動フェイルオーバーします。スタンバイは読み取りに使えません（待機専用）。一方 リードレプリカ は性能（読み取りスケール）のための仕組みで、非同期レプリケーションの読み取り可能なコピーを最大数台作り、読み取りクエリをオフロードします（クロスリージョンも可）。フェイルオーバー先ではない点に注意。両方必要なら併用します。バックアップでは、自動バックアップ＋トランザクションログで ポイントインタイムリカバリ（PITR） ができ、手動スナップショットは明示削除まで保持されます。Aurora はストレージ層で6コピーを保持し、レプリカ昇格が速く、可用性・性能とも RDS より優れます。メンテナンスウィンドウ中のパッチ適用やスケール変更はマルチ AZ で影響を抑えられます。
| 観点 | マルチ AZ | リードレプリカ |
|---|---|---|
| 目的 | 高可用性 | 読み取りスケール |
| レプリケーション | 同期 | 非同期 |
| 読み取り | 不可（待機） | 可能 |
| フェイルオーバー | 自動 | 用途外（手動昇格） |
シナリオ：DB が単一障害点で、かつ読み取りが重い。 マルチ AZ で自動フェイルオーバー（可用性）を確保し、リードレプリカを複数足して読み取りをオフロード（性能）。災害対策にはクロスリージョンのリードレプリカやスナップショットのクロスリージョンコピーを使い、PITR で誤操作からも復旧できるようにします。
Q. 自動フェイルオーバーは？ マルチ AZ（スタンバイは読めない）。Q. 読み取り負荷を下げたい。 リードレプリカ。Q. 誤って消したデータを戻す？ 自動バックアップ＋PITR。Q. 別リージョンへ DR？ クロスリージョンレプリカ/スナップショットコピー。
混同に注意：
①マルチ AZ のスタンバイは読み取り不可——「読み取りスケール＝マルチ AZ」は誤り（正しくはリードレプリカ）。
②リードレプリカは非同期でフェイルオーバー先ではない（手動昇格は可能）。
③自動バックアップを無効化すると PITR ができない。
高可用性と読み取りスケールの両方が必要なら、マルチ AZ とリードレプリカを併用します。Aurora はさらに高速な複製とフェイルオーバーを提供します。
2.2.2この節のまとめ
- マルチ AZ＝HA/自動フェイルオーバー（読めない）／リードレプリカ＝読み取りスケール
- 両立が必要なら併用する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. RDS でプライマリ障害時に自動でスタンバイへ切り替え、可用性を高めたい。何を使いますか？
Q2. 読み取りクエリが多くプライマリの負荷が高い。読み取りをオフロードするには何を使いますか？
Q3. マルチ AZ のスタンバイインスタンスに関する正しい記述はどれですか？