【RDSの役割（耐障害性と高可用性）】
目次
🔍 1. 結論
💎 一言でいうと Amazon RDS における弾力性の要は、「Multi-AZ配置による自動フェイルオーバー」 と 「クロスリージョンリードレプリカを用いた災害復旧（DR）」 です。物理サーバーの障害からリージョンレベルの災害まで耐えうる設計が可能です。
- 高可用性が求められる場合は、必ず Multi-AZ（マルチAZ） を有効にする。
- リージョン障害（DR対策）には、別リージョンに リードレプリカ（Read Replica） を作っておき、いざという時にマスターに昇格させる。
📈 2. SAAで出やすいポイント
- Multi-AZの挙動 (高可用性/HA):
- メイン（プライマリ）DBと同じデータを、別AZのスタンバイDBへ 同期的に レプリケーションします。
- プライマリDBに障害が発生すると、自動的にスタンバイ側へフェイルオーバーし、DNS名（エンドポイント）がスタンバイ側に向き直るため、アプリ側のコード変更は不要です。
- リードレプリカ (Read Replica):
- 本来は読み込み（Read）の負荷分散用ですが、非同期 で別リージョン（クロスリージョン）に作成できます。
- メインリージョンが壊滅した場合、別リージョンのリードレプリカを 「スタンドアロンDB（マスター）」に昇格（Promote） させることで、迅速にシステムを復旧（DR）できます。
- 自動バックアップ: 指定したウィンドウ（時間帯）に自動でスナップショットを取得し、最大35日間保持。障害が起きた「特定の時間（秒単位）」にデータを巻き戻す（Point-in-Time Recovery）ことが可能です。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑う機能・構成 |
|---|---|
| 🛡️ 「DBの単一障害点をなくす」「障害時に自動で切り替える」 | RDS Multi-AZ |
| 🌍 「リージョン全体がダウンした際のディザスタリカバリ(DR)」 | クロスリージョン・リードレプリカ（作成後、昇格させる） |
| ⏪ 「誤ってテーブルをドロップした！数時間前に戻したい」 | RDS Point-in-Time Recovery (PITR) |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「可用性を高めるためにリードレプリカを追加する」 → 可用性（障害時の自動復旧）を高めるのは Multi-AZ です。リードレプリカはパフォーマンス（負荷分散）向上とDRが目的です。 – 「Multi-AZのスタンバイDBに読み込みトラフィックを分散させる」 → 従来のMulti-AZではスタンバイDBは「待機専用」でありアクセスできません。（※最近は「Multi-AZ DBクラスター」という読込可能な構成もありますが、基本のひっかけとして覚えておいてください）。
💡 5. 覚え方
🧠 暗記ショートカット – Multi-AZ = 「影武者」。普段は隠れているが、殿（メインDB）が倒れると一瞬で殿になりすます。 – リードレプリカ = 「速記者（海外赴任）」。殿の言葉をひたすらメモして別リージョンで配る。殿が死んだら、速記者が新しい殿（昇格）になる。
📚 6. 関連サービス
| アイコン | サービス名 | 弾力性における役割 |
|---|---|---|
| 🐘 | Amazon Aurora | RDSの進化版。最初から3つのAZに6つのデータコピーを持つ超弾力性DB |
| 🌐 | Route 53 | アプリケーション全体のフェイルオーバールーティングを制御する |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: データベースの高可用性設計、ディザスタリカバリ（DR）戦略の学習時
- 関連ノート候補:
AWS_SAA_Multi-AZ_vs_ReadReplica
8. HTMLファイル名:
AWS_弾力性設計_RDS.html
