AWS Direct Connect のフェイルオーバーテストを使って待機系の AWS Site-to-Site VPN へ切り替えテストをしてみた

いわさです。

AWS で Direct Connect を構成する時、次のように Direct Connect に障害が発生した場合に備えて Site-to-Site VPN を待機系として構成する場合があります。
この構成では、通常は Direct Connect が優先されて、Direct Connect で障害が発生した際には Site-to-Site VPN が使用されます。

上記のような冗長構成はみなさんもよくやられていると思いますし、次のように記事でも紹介されています。

待機系を構成したからにはテストをしたいところ。
上記記事で紹介されている AWS Black Belt Online Seminar の資料は古いもので、「AWS 側の仕組みで障害を疑似する機能の提供は無い」と記載されており、ルーター側のインターフェースをシャットダウンする方法について言及されていますが、その後の Direct Connect のアップデートで、回復性をテストするためのフェイルオーバーテストという機能が登場しています。

上記記事では Direct Connect 上でメイン回線とバックアップ回線が切り替わるか確認していますが、今回これに加えて Site-to-Site VPN を待機系として構成した環境で、Direct Connect の VIF を全てダウンさせ、Site-to-Site VPN へ切り替わるのかテストしてみましたので、その様子を紹介したいと思います。

検証対象の環境

前述のとおり、VPC に対して Site-to-Site VPN と Direct Connect Private VIF の経路を用意しています。

Site-to-Site VPN は既に構成済みで、トンネルステータスはアップ状態です。

また、Private VIF はかなり前に構成済みのもので、VGW に 2 本直接アタッチされています。
この VIF を 2 本ともダウンさせることで、トラフィックが VPN に流れるか試してみたいと思います。

ルート伝播やら静的ルートやら色々と他にもあるのですが、今回はフェイルオーバーテストによって Direct Connect から Site-to-Site VPN への切り替えが可能なのかを検証したいので、そのあたりは割愛します。

フェイルオーバーテストの開始

では Direct Connect のフェイルオーバーテストを開始しましょう。
手順は簡単で、ダウンさせたい仮想インターフェースを選択し、アクションメニューから「BGP を停止させる」を選択します。

そうすると、どの程度の期間停止させるかオプションで指定することが可能です。デフォルトは 3 時間 (180 分) で、最大は 3 日間（4,320 分）です。
後述しますが、テストはキャンセルすることができるので、ギリギリの時間を見積もる必要はないです。今回は余裕を持って 3 時間を指定しました。

仮想インターフェースのフェイルオーバーテストを開始すると、仮想インターフェースのステータスが「testing」に変わります。
フェイルオーバー中は down には変わらず、testing となっていました。
冒頭のフェイルオーバーテストの記事ではテスト開始後に testing → down と遷移すると記述がありましたが、私が確認した際には VIF ステータスは testing、ピアリングステータスが down となっていました（テスト開始後 30 分程度程度まで確認）

ピアリングの BGP ステータスについては testing 中は「down」となります。
ここのステータス切り替えは数十秒程度で切り替わったかと思います。

そして、今回は VPN にトラフィックを流したいので、もう 1 本の仮想インターフェースも停止させます。
操作は先程と同じ流れです。

なお、停止された仮想インターフェースの詳細画面では、テスト中でありキャンセルが可能であること、テスト履歴タブからテストごとの開始時刻・終了時刻・ステータスが確認出来ます。

テスト中のメトリクス

ここで、フェイルオーバー開始後の Direct Connect と VPN に関するメトリクスを確認してみました。
通信状況が変化したか確認できると思ったので。

CloudWatch メトリクスで、Direct Connect 仮想インターフェースの BpgIngress と BpsEgress を確認します。
テスト開始後に通信量が減り始めていることが確認出来ました。

また、VPN の各トンネルの TunnelDataIn と TunnelDataOut を確認してみると、こちらは逆にテスト開始後から通信が発生し始めていることが確認出来ました。

このメトリクスを確認した感じ、うまく Direct Connect から Site-to-Site VPN に切り替えが出来ていそうなことが確認出来ました。
その後、アプリケーションなどを通して、正常に通信できることも確認が取れました。

フェイルオーバーテストの停止

切り替えテストを行うことで待機系である Site-to-Site VPN でもワークロードが動作することが確認出来ました。
このまま 3 時間待つことで Direct Connect は復旧するはずですが、手動でフェイルオーバーテストを停止することで復旧も可能です。

操作は先程と似た感じになりますが、対象の仮想インターフェースを選択し、アクションから「テストをキャンセル」を選択します。

障害テストをキャンセルするか確認されるので「確認する」ボタンを押して確定を行います。

テスト履歴を確認してみると InProgress だったテストステータスがすぐに cancelling に変化します。

そして数秒後には cancelled に変化しました。

フェイルオーバーテストを停止する時に VIF ステータスが一度 down になる

フェイルオーバーテストの停止を行うと、こちらは仮想インターフェースのステータスが testing から down に変化しました。

今回は 2 本の VIF を同時に選択してテストキャンセルしたのですが、次のように仮想インターフェース 2 つとも一度 down 状態となります。

その後ステータスが available となりました。
対抗機器との構成状況にも依りそうな気がしますが、複数のテスト環境で試した感じではおおよそ 5 ~ 10 分間程度でステータスが復旧しました。

復旧後は次のようにピアリングステータスも up に復旧しましたね。良さそうです。

テスト後のメトリクス

テスト開始後と同様にメトリクスを確認してみます。
VPN トンネルについては、また通信が発生しなくなっていることを確認しました。

また、 Direct Connect 仮想インターフェースについては、また通信が発生し始めていることが確認出来ました。

テスト前の状態に復旧出来ていそうですね。
アプリケーションからも確認を行い、ワークロードも正常に動作していることが確認出来ました。

さいごに

本日は AWS Direct Connect のフェイルオーバーテストを使って待機系の AWS Site-to-Site VPN へ切り替えテストをしてみました。

テスト出来ましたね。
待機系の Site-to-Site VPN を構築した際にフェイルオーバーテストをしたい場合でも Direct Connect のフェイルオーバーテストが有効であることが確認出来ました。
また、完全に切り替わらない時の手動切替のリハーサルにもなって良いですね。一度はやっておきたいです。