2.2基礎
リレーショナルDBの書き込み可用性が必要である。
AZ障害時にスタンバイへ自動切り替えし、アプリの接続先を変えたくない。
最も適切な構成はどれか。
× 不正解
書き込み可用性にはRDS Multi-AZを使い、読み取り分散用のRead Replicaと区別する。
詳細解説
誤り単一AZのRDSだけを利用する
AZ障害時にDBが利用できなくなる。
AZ障害時にDBが利用できなくなる。
誤り読み取りレプリカだけを作成する
Read Replicaは読み取り分散が主目的で、自動フェイルオーバー用の同期スタンバイとは異なる。
Read Replicaは読み取り分散が主目的で、自動フェイルオーバー用の同期スタンバイとは異なる。
正しいRDS Multi-AZのDBインスタンス配置を利用する
別AZのスタンバイへ同期し、障害時にRDSがフェイルオーバーする。
別AZのスタンバイへ同期し、障害時にRDSがフェイルオーバーする。
誤りS3 CRRでRDSのSQL接続を継続する
S3レプリケーションはRDS接続のフェイルオーバーを提供しない。
S3レプリケーションはRDS接続のフェイルオーバーを提供しない。
実際に確かめる
一時的な検証環境で実行できる例です。
Amazon RDS Multi-AZ deploymentの公式説明を確認する。期待される結果
Multi-AZとRead Replicaの目的を可用性要件から区別できる。理解のポイント
- RDS Multi-AZ
- スタンバイ
- フェイルオーバー
確認時の注意
- 確認環境: AWS公式RDSドキュメントの確認
- AWS公式SAA-C03 Domain 2と各サービスの公式ドキュメントを確認する。
基礎のおさらい
判断のポイント
障害ドメイン、データの復旧点、処理の重複、切り替え時間を分けて評価する。
設計の確認
正常系だけでなく、キュー滞留・AZ障害・リージョン障害・依存サービス停止時の動作を確認する。
問題IDAWS-SAA-132
確認環境AWS公式RDSドキュメントの確認
最終技術確認2026-08-20
誤り・権利侵害を報告