RDSのマルチAZ・リードレプリカ・DRの考え方
マルチAZの同期スタンバイと自動フェイルオーバー、リードレプリカによる読み取りスケール、クロスリージョン、用途の違いを整理します。
マルチ AZ 配置
マルチ AZ は、プライマリとは別の AZ にスタンバイを置き、同期レプリケーションでデータを揃えます。プライマリに障害があれば 自動フェイルオーバーが行われ、クライアントが向いている DNS 名（エンドポイント）の背後で CNAME が切り替わるイメージです（接続中のセッションは切断されやすく、アプリは再接続を前提にします）。
次のポイントが強調されやすいです。
- プライマリとスタンバイは同期レプリケーション … RPO を小さくしやすい（同一リージョン内の HA 向け）。
- スタンバイは通常アクセス不可 … 読み取りも書き込みもできない（読み取り分散はリードレプリカ）。
- フェイルオーバーは設定を有効にするだけで比較的簡単 … 運用上はメンテナンスやフェイルオーバー時の短いダウンタイムに注意。
試験で落とし穴になりやすい記述
- 「マルチ AZ のスタンバイに読み取りクエリを振り分けられる」→ 誤り（リードレプリカの役割）。
- 「マルチ AZ は災害時の別リージョン DR」→ 主目的は同一リージョンの AZ 障害。リージョン全体の災害にはバックアップのコピーやクロスリージョンレプリカなど別策が必要。
リードレプリカ
リードレプリカは、プライマリから非同期（基本）で追従する読み取り専用の DB インスタンスです。用途は次のとおりです。
- レポート・分析など、プライマリに負荷をかけたくない読み取り。
- 読み取りスループットの水平方向の拡張（台数を増やす）。
プライマリ障害時の扱いはシナリオ次第ですが、レプリカを昇格（プロモート）してスタンドアロンにする、別リージョンのレプリカを昇格する、などが DR の文脈で出題されます。所要時間や RTO は手動／自動の設計次第です。
台数上限は Aurora（最大15リードなどの説明）と RDS 各エンジンで異なります。数字は現行ドキュメントで確認してください。
マルチ AZ DB クラスター配置（「3AZ・読み取り可能スタンバイ」）
一部の構成では、複数 AZ に跨ったクラスターとして、読み取り可能なスタンバイ DB を複数持つモードが説明されます。これは従来の「マルチ AZ のスタンバイは触れない」とは別の製品／モード（例: Aurora クラスターや RDS Multi-AZ DB cluster）として理解してください。試験ではエンジン名とモードを読み分ける必要があります。
クロスリージョンのレプリカ
別リージョンにリードレプリカを置くと、災害時の読み取りや、地理的に近いユーザーへの参照レイテンシ低減に使えます。レプリケーションは非同期のため、プライマリとの間にラグがあります。RPO の要件が厳しい場合は、同期のマルチ AZ やバックアップ戦略と組み合わせて設計します。
目的ごとの整理（概念）
| 観点 | マルチ AZ（スタンバイ） | リードレプリカ | バックアップ／スナップショット |
|---|---|---|---|
| 主な狙い | 同一リージョンの AZ 障害に耐える | 読み取りスケール・参照の分散 | 論理削除・誤操作・長期保管 |
| レプリケーション | 同期 | 非同期が基本 | ポイントインタイムは別メカニズム |
| スタンバイ参照 | 不可 | 読み取り可 | リストアして別インスタンスとして利用 |
Aurora との違い（概要のみ）
Aurora は共有ストレージレイヤーとフェイルオーバーの仕組みが RDS シングル DB と異なり、リードレプリカ数やフェイルオーバー速度の説明が別系統になります。詳細は RDS, Aurora, DynamoDB と公式ドキュメントを参照してください。
公式ドキュメント（深掘り）
重要ポイント
- ▸マルチAZは同期スタンバイ・スタンバイは参照不可・DNSでエンドポイントが切り替わる
- ▸リードレプリカは非同期の読み取り専用。マルチAZの代替ではない
- ▸マルチAZクラスタ（読み取り可能スタンバイ）はAurora系のモードとして別扱い
- ▸クロスリージョンDRはレプリカ昇格やスナップショットとセットで検討
- ▸フェイルオーバー時の接続切断・DNS TTLはアプリ設計の論点
このトピックの学習を完了しますか？
完了状態はいつでも切り替えられます
この試験ドメイン内で次の学習に進む
同じサービスの関連トピック
RDS / Aurora / ElastiCache に関連するトピックを続けて確認できます。