AWS 認定資格 ラボ
データベース ・

RDS Multi-AZ とは？同期レプリで実現する高可用性構成

RDS Multi-AZ は 別 AZ にスタンバイインスタンスを自動構築する高可用性構成。プライマリ DB に障害が発生すると、1〜2 分でスタンバイへ自動フェイルオーバーする。本番運用で必須の構成で、RDS の可用性 SLA は Multi-AZ 構成で 99.95%。...

#AWS #RDS-MultiAZ #データベース

RDS の高可用性構成。別 AZ にスタンバイインスタンスを自動構築し、障害時に自動フェイルオーバー。

1. 概要（端的に）

RDS Multi-AZ は 別 AZ にスタンバイインスタンスを自動構築する高可用性構成。プライマリ DB に障害が発生すると、1〜2 分でスタンバイへ自動フェイルオーバーする。本番運用で必須の構成で、RDS の可用性 SLA は Multi-AZ 構成で 99.95%。

2. 何ができるか

  • 別 AZ にスタンバイ自動構築：同期レプリ
  • 自動フェイルオーバー：1〜2 分で切替
  • エンドポイント不変：DNS 名は変わらない（CNAME 切替）
  • メンテ・パッチの透過適用：スタンバイから順にパッチ → フェイルオーバー
  • バックアップの影響なし：スタンバイで取得 → プライマリへの影響軽減

注意：読み取り負荷分散には使えない

  • スタンバイは 同期レプリだが、読み取り受付不可
  • 読み取りスケールには Read Replica を別途構成

3. 特徴

観点特徴
追加料金プライマリの 2 倍（スタンバイも課金）
レプリ方式同期レプリ
可用性 SLA99.95%
AZ 分離必須（同 AZ ではない）
対応エンジンMySQL / Postgres / MariaDB / Oracle / SQL Server
フェイルオーバー時間1〜2 分（DNS TTL 短縮で更に短く）

Multi-AZ Cluster（Postgres / MySQL の新方式）

通常の Multi-AZ より新しい方式：

  • 3 AZ・3 ノード（Writer 1 + Reader 2）
  • フェイルオーバー時間：< 35 秒
  • Reader からの読み取り負荷分散も可能
  • Postgres / MySQL のみ（2024-）

vs Read Replica

観点Multi-AZRead Replica
用途高可用性（HA）読み取りスケール
レプリ同期非同期
読み取り受付×○
自動フェイルオーバー○×
別 AZ 必須○×
別リージョン可×○

4. 仕組み

Multi-AZ では プライマリ DB の全トランザクションが、別 AZ のスタンバイ DB に同期レプリケーションされる。

動作の流れ（フェイルオーバー）

  1. プライマリ DB 障害発生（インスタンス停止・AZ 障害等）
  2. AWS が障害検知
  3. DNS 名（エンドポイント）の参照先をスタンバイへ切替（CNAME 更新）
  4. スタンバイがプライマリに昇格
  5. 新スタンバイが別 AZ で再構築
  6. 通常運用復帰（合計 1〜2 分）

フェイルオーバー発生条件

  • AZ 障害
  • プライマリインスタンス障害
  • プライマリのストレージ障害
  • プライマリのネットワーク障害
  • 手動フェイルオーバー（メンテ用）
  • インスタンスタイプ変更時

構成要素

  • プライマリ：書き込み可能・読み取り可能
  • スタンバイ：同期レプリ・読み取り不可
  • エンドポイント：DNS（CNAME）でプライマリを指す

5. ユースケース

ユースケース 1：本番 Web サービス DB

24/7 稼働の本番。Multi-AZ は必須。

ユースケース 2：基幹システム

ミッションクリティカルな業務 DB。

ユースケース 3：規制要件

SLA を契約で求められるシステム。

ユースケース 4：パッチ適用の透過化

ダウンタイムなしでパッチ適用したい運用。

6. 関連用語

7. 関連サイト

AWS 公式

参考

🎓 試験での出題傾向

試験重要度主な出題パターン
CLF高HA 構成の概念
SAA高Multi-AZ vs Read Replica（最頻出）
DVA中フェイルオーバー時のアプリ対応
SOA高運用・パッチ適用