AWS RDS マルチAZ構成

Primary に障害が発生すると、60〜120秒で Standby が新 Primary に自動昇格します。手動介入は不要で、エンドポイント（CNAME）が自動更新されるためアプリケーションの接続文字列を変更する必要はありません。

書き込みは Primary と Standby の両方にコミットされた後に完了します。これにより、フェイルオーバー時のデータ損失がゼロ（RPO = 0）になります。ただし、非同期レプリケーション（Read Replica）と比較すると書き込みレイテンシが若干増加します。

Standby インスタンスは Primary と同じスペックで作成されるため、インスタンス料金が約2倍になります。ただし、ストレージは共有されないため EBS 料金も別途発生します。本番環境ではコストより可用性を優先すべきです。

OS パッチやエンジンアップグレード時は、まずStandby にパッチを適用→ フェイルオーバー → 旧 Primary（現 Standby）にパッチ適用の順で行われます。これによりダウンタイムはフェイルオーバーの60〜120秒のみに抑えられます。

コミットは Primary と Standby の両方に書き込まれてから完了。データ損失ゼロ。Standby への読み取りアクセスは不可。可用性が目的。

Primary のコミット完了後に非同期でレプリカに反映。わずかなレプリケーションラグあり。レプリカへの読み取りアクセスが可能。読み取りスケーリングが目的。

以下のいずれかが発生すると、RDS が自動的にフェイルオーバーを開始します:

RDS の内部ヘルスチェック機構が Primary の異常を検知します。検知は数秒以内に行われ、検知後すぐに DNS 切替プロセスが開始されます。CloudWatch の RDSEventNotification でフェイルオーバーイベントが通知されます。

RDS エンドポイントは DNS の CNAME レコードで実装されています。フェイルオーバー時は、CNAME が指す先の IP アドレスが旧 Primary から Standby（新 Primary）に自動更新されます。DNS TTL は短く設定されているため（通常5秒）、クライアントは素早く新しい IP を解決できます。この仕組みにより、アプリケーションの接続文字列を変更する必要がありません。

Standby DB が新しい Primary に昇格します。昇格プロセスでは、最後のトランザクションログの適用 → リカバリ処理 → 読み書き可能モードへの切り替えが行われます。同期レプリケーションにより Standby は常に最新データを持っているため、データ損失はゼロ（RPO = 0）です。

フェイルオーバー完了後、RDS は自動的に新しい Standby インスタンスを別の AZ に構築します。この間は一時的に冗長性が低下しますが、構築完了後に再びマルチAZの可用性が確保されます。手動操作は不要です。

常に現在の Primary DB を指す CNAME レコードです。フェイルオーバー時に自動的に新 Primary に切り替わるため、アプリケーションの接続文字列を変更する必要がありません。書き込み・読み取りの両方に使えます。

CNAME レコードの動き（通常時）

リードレプリカへの読み取りクエリをロードバランシングするエンドポイントです。複数のリードレプリカがある場合、接続が自動的に分散されます。Aurora クラスターでは標準提供されますが、通常の RDS では各レプリカに個別エンドポイントが割り当てられます。

特定のインスタンスに直接接続するエンドポイントです。Primary・Standby・各リードレプリカそれぞれに固有のエンドポイントがあります。トラブルシューティングや特定レプリカへの接続に使いますが、通常のアプリケーションではクラスターエンドポイントを使うべきです。