RDS の画面や資料に「Multi-AZ」「リードレプリカ」「バックアップ」が並ぶと、どれも「データを複数持つ機能」に見えて混ざりがちです。「レプリカがあるから止まっても大丈夫」「Multi-AZ のスタンバイで読み取りを分散できる」と考えてしまう人も多いはずです。この記事では、3 つが何を守る部品かと、データの渡し方が違うからその役割になることを順に確かめます。RDS そのものの説明は RDS とは に任せます。
この記事の結論
- Multi-AZ は別 AZ のスタンバイへ同期でコピーし、障害時に自動でフェイルオーバーする「止まりにくさ」の部品です。DB インスタンス配置のスタンバイは読み取りを受けません。
- リードレプリカは非同期でコピーした読み取り専用のインスタンスで、「読みを増やす」部品です。非同期なので古いデータを返しうるうえ、自動では増減せず手動で作ります。
- バックアップは、保持期間内の任意の時点へ戻せる自動バックアップと、明示的に消すまで残る手動スナップショットの 2 つです。誤操作やデータ破損から戻す部品で、レプリカでは代わりになりません。
- 3 つは組み合わせられます（Multi-AZ とリードレプリカの併用、クロスリージョンレプリカを DR に使う、など）。
- 迷ったら「何が起きたときに困るか」（AZ 障害・読み取りが重い・消した／壊した）から選びます。
RDS の「複数持つ」「戻す」は何が違うのか｜3 つの部品を先に並べる
最初に結論の形を置きます。3 つの部品は、守る相手が別です。
| 部品 | 守るもの | データの渡し方 | 切り替え・復元 |
|---|---|---|---|
| Multi-AZ | AZ やインスタンスの障害 | 別 AZ のスタンバイへ同期 | 障害時に自動でフェイルオーバー |
| リードレプリカ | 読み取りの負荷 | 非同期で読み取り専用のコピーへ | 昇格は手動の作業 |
| バックアップ | 誤操作・データ破損 | 自動バックアップ／手動スナップショット | 時点やスナップショットを指定して復元 |
「渡し方」の列が肝です。同期か非同期かは、「いつの時点の内容を持っているか」を決めます。そして今の状態を写す部品は、今の状態の誤りも写します。この性質が、後の章で何度か効いてきます。
困りごとから部品を引く
困りごとが違えば、使う部品も違う。止める・増やす・戻すは別の仕事
困りごと
使う部品
困りごと: AZ に障害が起きても止まりたくない
使う部品: Multi-AZ（同期のスタンバイ）
困りごと: 読み取りが重くてプライマリが苦しい
使う部品: リードレプリカ（非同期のコピー）
困りごと: 誤って消した・壊した
使う部品: バックアップ（過去の時点を残す）
Multi-AZ とは何か｜同期コピーと自動フェイルオーバーの動き
Multi-AZ は、プライマリの DB インスタンスとは別の AZ にスタンバイを置き、データを同期で写しておく構成です。同期とは、書き込みがスタンバイにも渡る前提で動くという意味で、プライマリが使えなくなったときにスタンバイが同じ内容を持っている状態を作ります。
障害が起きると、RDS が自動でスタンバイへ切り替えます。アプリの接続先は RDS のエンドポイントなので、切り替えのたびに接続文字列を書き換える必要はありません。この「エンドポイントは変わらない」点が、人手の対応を減らす理由のひとつです。なお、切り替えにかかる時間の目安は、この記事では公式で確かめていないので書きません。
ここで間違えやすいのが、スタンバイの役割です。
- DB インスタンスのマルチ AZ 配置（スタンバイ 1 つ）: スタンバイは待機専用で、読み取りを受けません。
- DB クラスターのマルチ AZ 配置（スタンバイ 2 つ）: スタンバイで読み取りができる構成もあります。
ここでいう「読み取りを受けない」は、前者の配置の話です。読み取りを増やす目的でスタンバイを当てにしてはいけません。その役割は次章のリードレプリカです。
CHECK 1ここまでの確認
AZ に障害が起きたとき、人手を介さずに別の AZ へ切り替えたい。RDS で使う部品はどれ?
答えと解説
答え: 2. Multi-AZ 配置
Multi-AZ は別の AZ にあるスタンバイへ同期でデータを写し、障害時に自動でフェイルオーバーします。リードレプリカは非同期で、切り替えを前提にした部品ではありません。「Multi-AZ とは何か」を読み直してください。
リードレプリカとは何か｜非同期コピーで読みを増やす仕組みと、古いデータを読む可能性
リードレプリカは、プライマリの内容を非同期で写した、読み取り専用の DB インスタンスです。参照系のクエリをレプリカに向ければ、プライマリが受ける読み取りが減ります。
データの渡し方
同期のスタンバイは読まず、非同期のレプリカが読む
-
プライマリ
書き込みを受ける
-
同期 → スタンバイ
別 AZ。障害時に自動で切り替わる
-
非同期 → リードレプリカ
読み取り専用。少し古いことがある
押さえる点は 3 つです。
- 非同期なので、少し古いデータを返すことがあります。 プライマリの書き込みが届く前に読むと、直前の更新が見えません。「更新直後の値を必ず読みたい」処理はプライマリに向けます。
- 自動では増減しません。 必要な数のレプリカは手動で作ります。負荷に合わせて勝手に増える部品ではありません。
- レプリカは別リージョンにも置けます。 クロスリージョンのレプリカを作り、必要になったら昇格させて DR（災害復旧）に使う、という使い方があります。昇格は手動の作業で、昇格すると読み取り専用ではなく書き込めるインスタンスになります。
Multi-AZ との違いを一言で言えば、Multi-AZ は「止まらないための同期の控え」、リードレプリカは「読みをさばくための少し遅れたコピー」です。エンジンごとにレプリケーションの方式に差はありますが、この記事では「非同期で写す」という共通の性質だけを押さえれば十分です。
CHECK 2ここまでの確認
参照系のクエリをプライマリから逃がしたい。ただしレプリカの内容が少し古いことは許せる場合、どれを足す?
答えと解説
答え: 1. リードレプリカ
リードレプリカは非同期でコピーした読み取り専用のインスタンスで、読みを増やす部品です。DB インスタンス配置のスタンバイは読み取りを受けません。「リードレプリカとは何か」を読み直してください。
バックアップはどう動くか｜自動バックアップ・保持期間・ポイントインタイムリカバリと手動スナップショットの違い
バックアップには 2 種類あります。
自動バックアップは、有効にして保持期間を決めると RDS が取り続けてくれるものです。保持期間の中であれば、任意の時点を指定して新しい DB インスタンスとして復元できます。これがポイントインタイムリカバリです。「直前の状態に戻したい」という要求に答えるのはこちらです。
手動スナップショットは、利用者が好きなタイミングで取るものです。自動バックアップのように保持期間で消えることはなく、明示的に消すまで残ります。長期保管したいデータや、大きな変更の前の保険に向きます。
2 つのバックアップ
日々の巻き戻しは自動バックアップ、長く残すなら手動スナップショット
自動バックアップ
保持期間の中を自由に戻る
- 保持期間内の任意の時点へ復元
- 期間を過ぎると消える
手動スナップショット
取った 1 点を残す
- 取った時点の 1 点へ復元
- 明示的に消すまで残る
| 自動バックアップ | 手動スナップショット | |
|---|---|---|
| 取り方 | 有効にしておくと RDS が取る | 利用者が好きなときに取る |
| 戻せる範囲 | 保持期間内の任意の時点 | 取った時点の 1 点 |
| 残る期間 | 保持期間まで | 明示的に消すまで |
| 向く用途 | 日々の「直前に戻したい」 | 長期保管・変更前の保険 |
どちらもバックアップの実体は S3 に保存されます。復元は「元のインスタンスを巻き戻す」のではなく、新しい DB インスタンスとして作る点にも注意してください。復元後に接続先を切り替える作業は、アプリ側で考える必要があります。また、DB インスタンスを削除したときに自動バックアップがどう扱われるかは、削除の方法で変わります。消す前に公式ドキュメントの該当箇所を確認してください。
CHECK 3ここまでの確認
一昨日の昼の状態へ DB を戻す必要が出た。前提として有効にしておく設定はどれ?
答えと解説
答え: 2. 自動バックアップ（保持期間が一昨日まで届いている）
自動バックアップが有効なら、保持期間の中の任意の時点を指定して復元できます。Multi-AZ やレプリカは現在の状態を写しているだけで、過去の時点を持っていません。「バックアップはどう動くか」を読み直してください。
組み合わせるとどうなるか｜Multi-AZ ＋ リードレプリカ、クロスリージョンレプリカと昇格（DR）
3 つは排他ではなく、組み合わせられます。
- Multi-AZ ＋ リードレプリカ: プライマリを Multi-AZ にして止まりにくくしつつ、参照系はリードレプリカにさばかせる。可用性と読み取り性能という別々の課題に、別々の部品で応える形です。
- クロスリージョンのリードレプリカ: リージョン障害に備えて、別リージョンに読み取り可能なコピーを持ちます。必要になったら昇格させて DR に使います。
- Multi-AZ ＋ バックアップ: 日常の部品構成です。Multi-AZ が障害からの自動復帰を、バックアップが「人の操作ミスからの復元」を担当します。
そして、最も大事な誤解が「Multi-AZ やレプリカがあればバックアップは要らない」です。冒頭で見たとおり、同期も非同期も、今の状態を写す仕組みです。テーブルを誤って消せば、その削除は同期でスタンバイに反映され、非同期でレプリカにも届きます。消した・壊した、からの復元に使うのは、過去の時点を持っているバックアップです。
混ぜてはいけない 3 つの理解
- Multi-AZ のスタンバイ（DB インスタンス配置）で読み取りを分散できると考える。
- リードレプリカを「自動で切り替わる控え」と考える。
- Multi-AZ やレプリカがあるからバックアップは不要と考える。
アプリ層の可用性（複数 AZ の Auto Scaling グループや ALB など）は DB とは別の層の話なので、ここでは触れません。DB を単一 AZ の自前構築から RDS のマルチ AZ に移すのは、あくまで「DB 層の止まりにくさ」を上げる一手です。
CHECK 4ここまでの確認
担当者がテーブルを誤って削除した。Multi-AZ のスタンバイから元のデータを取り戻せる?
答えと解説
答え: 2. 取り戻せない。同期コピーなので削除もスタンバイに反映される
同期コピーは「今の状態を同じにする」仕組みなので、誤操作も一緒に写ります。戻すにはバックアップ（ポイントインタイムリカバリやスナップショット）を使います。「組み合わせるとどうなるか」を読み直してください。
「困りごと」から部品を引く｜AZ 障害／読み取り負荷／誤削除の対応表
最後に、困りごとから引く表にまとめます。
| 起きて困ること | 使う部品 | 理由 |
|---|---|---|
| AZ やインスタンスの障害で止まりたくない | Multi-AZ | 同期のスタンバイへ自動で切り替わる |
| 読み取りが重く、プライマリが苦しい | リードレプリカ | 参照系を非同期のコピーに逃がせる（古いデータの可能性は許容する） |
| リージョン障害に備えたい | クロスリージョンのリードレプリカ | 別リージョンに持ち、必要なら昇格する（手動） |
| 誤って消した・壊した | 自動バックアップ（PITR） | 保持期間内の任意の時点に戻せる |
| 長く残したい・変更前に保険がほしい | 手動スナップショット | 明示的に消すまで残る |
迷ったときは、部品の名前から考えず、「何が起きたときに困るのか」から始めてください。そして、料金は構成によって変わるので、具体額は公式の料金ページで確かめてください。
まとめ
Multi-AZ・リードレプリカ・バックアップは、守る相手が別の部品です。Multi-AZ は同期のスタンバイで障害に自動で備え、リードレプリカは非同期のコピーで読み取りを増やし、バックアップは過去の時点を残して誤操作から戻します。データの渡し方（同期・非同期・スナップショット）の違いが、そのまま役割の違いになっています。次は練習問題で、同じ論点を別の言い方で問い直して確かめてください。
参照ソース
- Multi-AZ DB 配置（Amazon RDS ユーザーガイド） — スタンバイ 1 つの DB インスタンス配置が読み取りを受けないこと、スタンバイ 2 つの DB クラスター配置との区別の根拠
- リードレプリカの使用（Amazon RDS ユーザーガイド） — 非同期レプリケーション、手動作成、クロスリージョン、昇格の根拠
- バックアップの使用（Amazon RDS ユーザーガイド） — 自動バックアップと保持期間内の任意時点への復元、手動スナップショットの根拠
