下記のページを参照して改めて内容を確認。またリードレプリカについても公式のドキュメントを参照した。（後述）
Amazon Web Services, Inc.
普段は主にAuroraのメンテナンスをすることが多いのでここの部分（フェイルオーバーするとAuroraの場合はリードレプリカがマスターとなる）の認識をいつも忘れる。
インフラストラクチャ障害の場合、Amazon RDS はスタンバイ (Amazon Aurora の場合はリードレプリカ) に自動的にフェイルオーバーするので、フェイルオーバーが完了するとすぐにデータベースの動作を再開できます。
AuroraではないRDSインスタンスの障害時のフェイルオーバーは下記の条件の時に発動され、手動での操作を行う必要はない。
- プライマリ利用可能ゾーンの可用性損失
- プライマリに対するネットワーク接続の喪失
- プライマリ上でのコンピュートユニット障害
- プライマリへのストレージ不良
ちなみにAuroraではないRDSインスタンスで手動フェイルオーバーを行う方法は、再起動時にチェックを付けることで実行することができる。（DB インスタンスを再起動するには）
フェイルオーバー自体は上記のドキュメントにもあるように1〜2分の時間がかかるためその間はダウンタイムとなる。
Amazon Aurora の場合 1 分間以内 (Maria DB Connector/J を使用する場合わずか 30 秒)、その他のデータベースエンジンでは 1～2 分間です (詳細については、RDS のよくある質問を参照してください)。
※Auroraの場合は「フェイルオーバー」と言う操作項目があるため、マスターに対してその操作を行うと待機系（＝リードレプリカ）と入れ替わる。
根本的にマルチAZの仕組みとリードレプリカは別々の機能であるため（若干混同していた）、その認識を改めるためにも下記の資料も参照した。
docs.aws.amazon.com
リードレプリカ自体はその名の通り読み込み用のインスタンスであるため、用途はDBの分散にある。
ただしドキュメントにもあるように、マルチAZを使用していないインスタンス（=スタンドアロンデータベース）に対して手動でマスターに昇格することは可能になる。これが自分がマルチAZでのフェイルオーバーと混同していた理由だと思う。
実際に昇格してみるとフェイルオーバーとは違って、レプリカではなく1つの書き込み可能なインスタンスが作成されることになる。
スタンドアロン DB インスタンスとなるようにリードレプリカを昇格
MySQL、MariaDB、Oracle、または PostgreSQL リードレプリカをスタンドアロンの DB インスタンスに昇格させることができます。リードレプリカを昇格させると、使用可能になる前に DB インスタンスが再起動されます。
リードレプリカを使用するユースケースはこれも公式の方に指針が載っていた。（下記ページの「リードレプリカ」の章を参照）
