AuroraでテストDBの復元→削除を繰り返すときに、うっかり既存のスナップショットと同じ名前**（○○-final-snapshot）**を付けて最終スナップショットを取得すると…？

0. 初期状態

以下のテストDBを削除し、最終スナップショットを取得しているとします。

DBインスタンス識別子 : db1-test
同・クラスター識別子 : db1-test-cluster
最終スナップショット名 : db1-test-final-snapshot

こんな感じになります。この時点では、クラスター**「db1-test-cluster」**はきれいに削除されています。

1. スナップショットからテストDBを復元

↑のスナップショットからDBインスタンス**「db1-test」**を復元します。

クラスター識別子は元のままで、クラスターエンドポイントのIPアドレスもDNSで引くことができており（PINGで確認）、MySQLクライアントからの接続もちゃんとできています。

2. テストDBを削除

このテストDBを削除します。

ここで、うっかり、最終スナップショット名を（元のスナップショットを消さないまま）同じものにすると、画面上には何のメッセージも出ませんが…

インスタンスは削除されますが、クラスターが残っています（インスタンス数は0です）。
クラスターエンドポイントのIPアドレスは、DNSで引けなくなりました。

3. 再度、スナップショットからテストDBを復元

最初と同じ画面で、同じスナップショットから再びテストDBを復元します。

何の指定もしていませんが、クラスター識別子の末尾に**「-1」が付きます。
つまり、先ほどまでとは別のクラスターでインスタンスが復元**されます。

クラスターが変わっていることに気づかないまま、前回のクラスターエンドポイントにPINGを打ってみると…なんと、新しいインスタンスのIPアドレスが引けてしまいます！（第4オクテットが152から154に変わっていますね。）
当然、MySQLクライアントから接続もできてしまいます。

4. レプリカを作成し、フェイルオーバーを試す

フェイルオーバーのテストをするために、別AZにレプリカを作成します。

作成後、フェイルオーバーしてみると…？

前回のクラスターエンドポイントにPINGを打ってみても、IPアドレスは変わりません。DNSエンドポイントがレプリカにフェイルオーバーしない…!?

当然ですが、このときのクラスターエンドポイントは**「db1-test-cluster-1」用のものが正解です。
こちらのエンドポイントを使うと、ちゃんと「db1-replica」**インスタンスのIPアドレスを指しているのですが…そもそも、この時点では別クラスターにインスタンスが復元されていることに気づいていないので、ちょっとしたパニックに…。

私の場合、しばらく悩み、AWSのパートナーさんのサポート窓口とやり取りしている途中にようやく気づきました（スクリーンショットと画面ログを添付していたのですが、私自身が気付くまで、サポート窓口の方も気づきませんでした）。

その後、同僚が別のテストでDBの復元→削除を繰り返しているときに全く気づかずに同じことをしていて、**「○○-cluster-2」まで出来上がり（末尾の番号はインクリメントされていきます）、さらに「○○-cluster-3」**までも（意図せず）作ろうとしていたので、慌てて止めました。

なお、クラスターを削除し損ねた場合、指定のバックアップウィンドウの中で自動スナップショットの取得が行われるので、そちらを見て「おや？なんか変だぞ？」と気づくかもしれません。

皆さんも、騙されないよう、気を付けましょう。

【おまけ】
Amazon Aurora関連投稿記事へのリンクを集めました。

Qiitaに投稿したAmazon Aurora関連記事