いわさです。
先日、CloudWatch の新しい機能がリリースされました。
CloudWatch Network Monitor というネットワークモニタリングのための機能です。
アナウンスを見てみるとハイブリッドネットワークの監視と修復が云々と記載されております。
今回実際に使ってみました。
先にまとめ
- VPC から任意の宛先に対してプライベートネットワーク経路での死活監視が出来る
- CloudWatch Network Monitor で監視用のプローブというものを既存の VPC 上に作成してくれる
- そこから指定した宛先（IP アドレスで指定）に ICMP などのパケットを一定間隔で送り続けることが出来る
- 死活監視のために送信したパケットの損失率と、送信してから応答が返るまでの時間（RTT: Round Trip Time）を CloudWatch メトリクスとして公開
- メトリクスを元にアラームや修復アクションなどは自分で頑張る必要がある
- AWS ネットワークヘルスインジケータ
- プローブによる正常性確認結果を示すものではなく、プローブがデプロイされたネットワークから Direct Connect Location までの正常性を示す
- ネットワークモニター機能自体が簡易的なダッシュボードとしても機能してる
やってみた
今回は次のように AWS と Azure 上でサイト間 VPN 接続を構成し、トンネルをダウンさせた際にネットワークモニターがどのような挙動をするのかなどを観察してみることにしました。
検証環境の用意
検証環境は次の記事を参考に静的ルートで構築しています。
トンネルは 2 本 UP 状態です。
なお、上記記事では Azure で ICMP を許可する設定が出来ないと記述がありますが、おそらく当時のブログの公開直後だと思いますが Azure 側で NSG のアップデートがあり、ICMP もサポートされました。
なので、AWS と Azure の双方の仮想マシンから ping で疎通確認まで行っています。
以下は AWS から Azure へ。
以下は Azure から AWS へ。
ネットワークモニター追加
ネットワークモニターを追加してみましょう。
CloudWatch のメニューに新しく「Network Monitor」が追加されています。
新しくモニターを作成します。
集計期間は CloudWatch にメトリクスを送信する頻度です。後ほど料金について説明しますが CloudWatch メトリクスの料金を抑えたいのであれば 60 秒を選択しても良いかなというところです。構成は後ほど変更が可能です。
また、初回はサービスロールが自動作成されます。
公式ドキュメントによると、アカウントごとにリージョンあたり最大 100 個のモニターを作成することが出来るとのこと。
次がメインの設定になります。
ネットワークモニターの仕組みとしては、指定した VPC のサブネット上リソースから指定した IP アドレスに対して死活監視用のパケットを送信し続けるというものになります。
なので送信元のサブネットを指定します。
また、送信先の宛先を 4 つまで指定することが出来ます。
今回は Azure の仮想マシンの IP アドレスを ICMP で指定しました。（通信プロトコルは ICMP と TCP をサポート）
次へ進むと、先程選択した構成によって作成されるプローブの情報がプレビューされます。
後述しますが、ネットワークモニターではこのプローブごとに料金が発生します。
この後、作成に進むと 1 分くらいですぐに作成されます。
確認してみると指定したネットワーク上に専用の ENI が作成されていました。
ネットワークモニターリソースにアクセスしてみると、ダッシュボードを確認することが出来ます。
メトリクス収集までちょっと待つ必要があります。私は数分で描画され始めました。
少し待つと、パケット損失と RTT の情報が確認出来るようになりました。
Azure 側の VPN 接続を確認してみると、プライマリトンネルでデータ転送されはじめていることが確認出来ました。
で、これらのメトリクスは CloudWatch メトリクスとして公開されています。
AWS/NetworkMonitor名前空間でPacketLossとRTTとHealthIndicatorの 3 つのメトリクスが公開されているはずです。
後述しますが、AWS ネットワークヘルスインジケータも正常として描画されはじめました。この時点ではまだこやつが何者なのかわかっていません。
ここまでで、ネットワークモニターがマネージドな VPC リソースを作成し、一定間隔で指定した宛先にパケットを送信し続けてその結果をメトリクス化し、さらに簡易的なダッシュボードも提供してくれることがわかりました。
プライマリトンネルを切断してみる
モニタリングが始まったので、VPN のプライマリトンネルがダウンした場合を見てみたいと思います。
Azure 側で、先程データのインアウトが確認出来ていた Local Netowork Gateway の構成を、不正な値に変更して VPN Connection が接続出来ない状態にしてみました。
AWS 側でネットワークモニターを確認してみると、早速パケット損失が発生していることを確認出来ました。
一瞬発生しているのですが、プライマリからセカンダリに自動で切り替わってすぐに落ち着いたような雰囲気を感じますね。
CloudWatch メトリクスでサイト間 VPN のメトリクスを見てみると、データ転送の発生しているトンネルが切り替わってることが確認出来ます。
セカンダリトンネルも切断してみる
同じ方法でもうひとつのトンネルも切断してみました。
ネットワークモニターではパケット損失率が 100% になりました。
これは期待どおりですね。ただし、AWS ネットワークヘルスインジケータが正常のままです。
AWS ネットワークヘルスインジケータ
このあと 1 時間ほど観察を続けたり、仮想プライベートゲートウェイを VPC からデタッチしたりと色々やってみたのですが、AWS ネットワークヘルスインジケータについては正常なままでした。こいつは一体何者なのか。
ドキュメントに書いてあります。
どうやらこのメトリクスは AWS Direct Connect を使った接続の場合に提供されるメトリクスのようです。
何も発生しないのかと思いきや Direct Connect を使っていない場合だと「正常」として出力されるようです。
今回試すことが出来ていませんが、対象 VPC から Direct Connect Location までのパスに異常がある場合にステータスが変更されるようです。
次のドキュメントにもプローブ正常性を示すものではないと記述されていました。
追加料金が発生しますよ
文中で少し触れましたが、ネットワークモニター固有の料金としてはデプロイされたプローブごとに料金が発生します。
それ以外にパブリッシュされる CloudWatch メトリクスにも標準の料金が発生します。
本日時点で東京リージョンだとプローブごとに $0.11/時間 が発生します。
参考までに今回の場合だと 2 つのサブネットからそれぞれ正常性監視を行おうとしているので 2 プローブとなり、720 時間で考えると $158/月 くらいでしょうか。
比較対象として適切だとは思ってないですが、Synthetics を 30 秒間隔で実行すると東京リージョンでは $0.228/時間 がかかるので、ネットワークモニターで実施出来る内容を VPC Lambda な Synthetics で実行している場合は安くなりそうですが、私はその例は聞いたことないですね。
小さいインスタンスサイズの仮想マシンでオンプレミスへのプライベート経路の死活監視を行うケースが聞いたことがあります。東京リージョンの t2.nano インスタンスで $0.0076/時間 なので単純なインフラコスト的な簡単でネットワークモニターに切り替えるケースは少なそうです。
セットアップが簡単だったり、ネットワークモニターのメンテナンスが不要という点から考えるのが良さそうです。
なお、プローブは非アクティブ化や削除が可能で、非アクティブだと料金が発生しないとのことです。
プローブ一覧から非アクティブ化が可能です。
さいごに
本日は Amazon CloudWatch Network Monitor を AWS-Azure のサイト間 VPN 構成で使ってみました。
リソースのメトリクス監視以外で特定経路の死活監視を行いたいシーンがよくあると思いますが、今まで自前で用意する必要があったものが CloudWatch のマネージドな機能で実現出来るようになりました。
re:Invent 2022 のセッションで紹介されていたような gray failures が Direct Connect などで発生した場合に、今回のモニタリング機能を活用すると軽減出来そうです。復元部分は自前で組み込みは必要ですが。
2
