※リードレプリカとリーダーインスタンスは同じです
※最初の画像はRDS(Aurora以外）の構成図であってAmazon Auroraの構成図ではありません。→ここでハマった

【まとめ】

クロスリージョン系
・「クロスリージョンのリードレプリカの作成」で作成されたリードレプリカの正体はクラスターである（→一番気づくのに苦労した）
→ 要はクラスター内のリードレプリカやライターインスタンスがスタンドアロンに昇格するのは無理なのである。無理なのである！！！！
・リードレプリカ作成先のリージョンのクラスターは作成元のデータベースと同期される
・リードレプリカ作成先のリージョンのクラスターを昇格させると元のクラスターのデータベースと同期されなくなる

・クロスリージョンレプリケーションで同じリージョンにもう一度作成するとそのクラスターは削除される。
※イベントでこのように表示。

・クロスリージョン先のクラスタのインスタンスを削除するためにはクラスターを昇格させてスタンドアロンにする必要がある。

Cannot delete the last instance of the read replica DB cluster. Promote the DB cluster to a standalone DB cluster in order to delete it. (Service: AmazonRDS; Status Code: 400; Error Code: InvalidDBClusterStateFault; Request ID: 00c6a147-4621-47c3-b4dc-ba2d70f4e653; Proxy: null)

非クロスリージョン系
・「フェイルオーバー」はライターインスタンスに対して行われるとリードレプリカのどれかが昇格
・「フェイルオーバー」はリードレプリカに対して行われると現在のライターインスタンスがリードレプリカになる
・ライターインスタンスが削除されるとリーダーインスタンスは勝手にライターインスタンスとしてフェイルオーバーされる

実験

auroraのリードレプリカをスタンドアロンに昇格させたときに細かい挙動がよくわからなかったので試そうとしてみました

クロスリージョンのリードレプリカを作成する前に何を準備する？
基本的に準備はレプリカ作成先のリージョンで行います
･サブネットグループ(そのためにVPCやサブネット等を作成しておく)
※レプリカ作成前のクラスタでVPC内部に設定していてもレプリカ作成時にパブリック変更可能です｡その際にはVPCの設定でDNSホストやDNS解決を有効にしておく必要があります｡
･セキュリティグループ(接続することも考慮して3306のポートの空いたセキュリティグループを作成しておきます)
･パラメータグループは必要ありません｡残念ながらレプリケーション作成時にパラメータグループを指定することができず､もともとカスタムでパラメータグループを設定していてもレプリケーション先ではデフォルトのパラメータグループに戻ってしまいます･･･

クロスリージョンのリードレプリカを作成すると何が起こる？
･それぞれのリージョンでマスターおよびクラスタがある状態になる
→要はリードレプリカ作成先でマスターインスタンスが作成される｡
→これらは同期される(もとのDBで書き込みを行えばもう片方のリージョンのデータベースが更新される)

では次にレプリカをスタンドアロンに昇格させようと思います

手順

プライマリ DB インスタンスに対するトランザクションの書き込みを停止し、すべての更新がリードレプリカに反映されるまで待ちます。
※Replica Lag メトリクスを使用して、リードレプリカに対するすべての更新の時期を確認できます。

MySQL および MariaDB の場合のみ、MySQL または MariaDB リードレプリカに変更を加えるには、リードレプリカの DB パラメータグループで read_only パラメータを 0 に設定する必要があります。

Amazon RDS コンソールの [昇格] を使用して、リードレプリカを昇格させます。

うーんなるほど
んでやってみますと・・・
見た目が何も変わっていない・・・どういうこと？

【変わったところ】
ソースのデータベース（クロスリージョン元のクラスター）のデータが同期されなくなった。
昇格してクラスタがスタンドアロンになる前はデータが同期されていた。

そうなんだけどさ。。。リードレプリカの昇格がクロスリージョン先のクラスターを指しているってなんか混乱させる表現だな。。。解釈が間違ってるのか・・・
とにかくクロスリージョンのリードレプリカの作成で作成されるのはクラスターだから！！！！