データベース層の可用性設計は、アプリケーション層以上に慎重な検討が必要です。本記事ではRDS Multi-AZとAurora Global Databaseを中心に解説します。

SAA レベル：基礎概念

RDS Multi-AZの基本

プライマリDBインスタンスと同期レプリケーションされたスタンバイインスタンスを、異なるAZに配置
プライマリに障害が発生すると、自動的にスタンバイへフェイルオーバー（DNSエンドポイントは変わらない）
スタンバイは通常、直接クエリを受け付けない（読み取り専用としては使えない）

SAA 試験のポイント

RDS Multi-AZのスタンバイインスタンスは可用性のためのものであり、読み取りの負荷分散には使えません。読み取り負荷分散が必要な場合は、別途リードレプリカを作成する必要がある、という違いがSAAで頻出します。

リードレプリカとの違い

項目	Multi-AZスタンバイ	リードレプリカ
レプリケーション方式	同期	非同期
読み取りクエリの受付	不可	可能
目的	高可用性（フェイルオーバー）	読み取りスケーリング

SAP レベル：高度な設計シナリオ

Aurora Global Databaseのアーキテクチャ

SAP 試験のポイント

Aurora Global Databaseは、プライマリリージョンのAuroraクラスターから、専用のレプリケーションインフラ（ストレージレイヤーでのレプリケーション）を使って最大5つのセカンダリリージョンへ通常1秒未満の遅延でデータを複製します。これは一般的なRDSクロスリージョンリードレプリカ（数秒〜のラグ）よりも大幅に低遅延である点がSAPの重要な選定基準になります。

フェイルオーバー時間の比較

構成	RTOの目安
RDS Multi-AZ（同一リージョン内）	通常60〜120秒
Aurora Multi-AZ（同一リージョン内）	通常30秒未満
Aurora Global Database（リージョン間、手動フェイルオーバー）	通常1分程度
Aurora Global Database（Managed Planned Failover使用時）	より短時間かつ自動化された切り替えが可能

設計上の落とし穴

「Aurora Global Databaseを使えば自動的にリージョン間フェイルオーバーが即座に行われる」という理解は誤りです。リージョン全体の障害時には、セカンダリリージョンを**書き込み可能なプライマリへ昇格させる操作（Failover）**が必要であり、これは完全に自動というよりは、運用者による判断（またはあらかじめ定義された自動化）を伴うプロセスである点に注意が必要です。

書き込みフォワーディングとローカルライトレイテンシ

Aurora Global Databaseの書き込みフォワーディング (Write Forwarding) 機能を使うと、セカンダリリージョンで受けた書き込みリクエストを、透過的にプライマリリージョンへ転送できる
グローバルにユーザーが分散しているアプリケーションで、読み取りは各リージョンのセカンダリで高速に処理しつつ、書き込みの整合性はプライマリに集約する、という設計を実現できる

RPOの考慮

Aurora Global Databaseは非同期レプリケーションであるため、プライマリリージョンが完全にデータ消失を伴う障害に見舞われた場合、直近のレプリケーションが完了していないデータは失われる可能性がある（RPOはゼロではない）
厳密にRPOゼロが求められる場合は、同期レプリケーションを要件に合わせて別途検討する必要がある

まとめ

SAA: RDS Multi-AZが同期レプリケーションによる高可用性のための仕組みであり、読み取り負荷分散にはリードレプリカが必要であることを理解する。
SAP: Aurora Global Databaseの低遅延レプリケーションの仕組み、フェイルオーバーが完全自動ではない点、書き込みフォワーディングによるグローバル設計ができる。

次は **キャッシュ戦略（ElastiCache、DAX、CloudFront）**を見ていきましょう。