背景・目的

前提

ここで説明する可用性は、システムが停止することなくサービスを提供し続けることを指す。
可用性を高めるための考え方として、以下を整理する。
- AWSインフラの機能として、マルチAZ、マルチリージョン
- データベースサービス機能として、プライマリ、セカンダリインスタンス
なお、仕組みが異なるものは、同一データベースサービス内でもエンジン別に切り出して整理している。
ここでいうレプリカは、スタンバイレプリカを指しており リードレプリカとは異なる。(Auroraだけは異なる。)
以下に整理した内容を記載する。

データベース	配置可能なロケーション		コンピュートとストレージの分離	データベース機能			備考
データベース	マルチAZ	マルチリージョン	コンピュートとストレージの分離	マルチマスタ	レプリカ	Fail Over(F/O) （※2）	備考
RDS(Aurora)	◯	◯ (※3)	◯ (※1)	◯ (※4)	リードレプリカ、スタンバイレプリカ兼用（※10）（最大15ノード）	◯ 120秒未満（多くは60秒）でF/O（※11）
RDS（MySQL、MariaDB、PostgreSQL、Oracle）	◯	✕	✕	✕	スタンバイレプリカ	◯ 60秒〜120秒でF/O F/OはAWS独自の仕組みを利用。
RDS（SQL Server）	◯	✕	✕	✕	◯	スタンバイレプリカ (※5) 60秒〜120秒でF/O
DynamoDB	◯	◯	？おそらくされている。	◯ (※6)	◯ （※7）	？ドキュメント見つけられず
DocumentDB	◯	✕	◯	✕	リードレプリカ（最大15ノード）	◯ リードレプリカがプライマリに昇格
ElastiCache for Memcached	◯	✕	✕ (※8)	◯	リードレプリカ（最大20ノード）	✕
ElastiCache for Redis	◯	◯ (※9 最大2つのリード専用クラスタ)	◯	✕	リードレプリカ（最大5ノード）	◯ リードレプリカがプライマリに昇格
Neptune	◯	✕	◯	✕	リードレプリカ（最大15ノード）	◯ リードレプリカがプライマリに昇格
Timestream	◯	✕	◯（※12）	✕	?	?
QLDB	◯	✕	?	✕	?	◯

AWSデータベースで採用されているクォーラムモデルは以下の仕様（6コピー）で統一されているようだ。
ストレージは、クラスターボリュームという機構で管理されている。
- ３つのAZに2つずつ、合計6つのコピーが行われるクォラームシステムを導入している。（確か、ZooKeeperやCassandraなどでも採用していた。）
- 6つのうち、同時に2つの障害が発生した場合（AZ１つがダウンなど）でも、書き込み、読み込み可能。
- 6つのうち、同時に３つの障害が発生した場合でも、読み込み可能
クォーラムモデルとは別に、10GBのブロック単位にコピーが行われ、ディスク障害時には自己修復機能により自動的に修復される。