Amazon CloudWatch Network Monitor を使ってみる

# 1. はじめに
- Direct Connect経由でオンプレミス環境と接続しているAWS上のシステムがあるが、障害時における接続断やパケロスの検知や、経路上の障害箇所の特定などに苦労する場合がある。
- 2023/12に、CloudWatchの新機能「Amazon CloudWatch Network Monitor」がリリースされた。「AWS とオンプレミス環境間のネットワークの可用性とパフォーマンスを監視するのに役立つ」とのことだが、実際にどういったことができるのかを確認する。

# 2. やったこと
- AWSとオンプレミス環境がDirect Connect経由で接続されている検証環境がある。（構成図参照）
- オンプレミス環境内に監視対象サーバを作成し、pingに応答できるようにする。
- AWS側でCloudWatch Network Monitorを設定し、ポーリング先としてオンプレミス環境内の監視対象サーバを指定する。
- 監視可能な項目（監視対象サーバとの接続正常性やレイテンシーなど）について確認する。また、異常時にどのような検知ができるのかを確認する。

# 3. 構成図

- オンプレミス環境とAWSが冗長化されたDirect Connectで接続されている。Direct ConnectのVIF1とVIF2がDXGWに接続されており、通常時はVIF1側経路が使用される。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/6a45a7a8-99d7-3221-803d-8cb72c1995de.png)

# 4. 手順

## 4.1 Network Monitorの作成

- CloudWatch -> ネットワークモニタリング -> Network Monitor から、「ネットワークモニターを作成」を開始する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/e14dc854-db72-dd18-f44d-e8f44ffedb60.png)

- Network Monitorを作成するVPC/Subnet、監視対象サーバのIPアドレス、プロトコルを設定する。今回は以下の通り設定する。
    - VPC/Subnet：　DXGWにアタッチされたVGWへのルーティング情報があり、オンプレミスへの通信が可能なサブネットを選択
    - 監視対象サーバ：　Direct Connectを経由して接続されているオンプレミスのサーバのIPアドレス
    - プロトコル： icmp (なおicmpの他、tcpも指定可能)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/fb39272c-5923-a398-bd4b-2874c7108e1f.png)

- 設定内容を確認し、Network Monitorを作成する。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/9a5ee23d-b3be-4869-9528-0df3c6ba5157.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/75f27713-d651-f522-433e-db4b93732b9a.png)

## 4.2 Network Monitor の通常時動作確認
- Network Monitorでは、以下の3つの監視項目が表示される。
    - AWSネットワークヘルスインジケータ
        - AWS基盤の正常性を示し、通常時は「正常」として緑色のラインが表示される。AWS基盤の障害発生時は「パフォーマンス低下」の表示に変わるようだが、その動作確認はできない。
    - パケット損失
        - パケロス率を表示。通常時は0%となっている。
    - ラウンドトリップタイム
        - 監視対象サーバまでの往復時間。本環境では7.8ms程度となっている。※右上の概要のところで、「7.86μs」となっているが、2024/1時点での日本語版の誤記の様子で、英語表示に変えると「7.86ms」と表示される。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/6774554f-bf50-3705-6fc3-431f79198d36.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/ae57d637-6ca0-df2b-36a5-d6f9a89e2838.png)

## 4.3 Direct Connect フェイルオーバーテスト時の動作確認
- VIF1(通常時トラフィックが流れるAct側経路)に対してフェイルオーバーテスト(BGPの停止を行い経路切替を発生させ、5分後に自動復旧)を行った。その際のパケット損失のグラフは以下。
- 14:26にフェイルオーバーテストを実行した際、少量のパケロスが検出された。(5分後の系戻しの際には断検出なし)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/189302/d8f98855-7ecb-6464-6855-39e706e75149.png)

# 5. 所感
- これまでは、本機能と同様のネットワーク監視を行いたい場合、自分でzabbixなどの監視サーバを構築・運用する必要があった。本機能ではそうした手間がなく、簡単にAWS/オンプレ間のエンドtoエンドの監視ができるメリットがある。
- AWS/オンプレ間のエンドtoエンドの監視において接続断が発生した場合、障害箇所がAWS側なのか、オンプレ側なのかの切り分けが困難な場合がある。AWS側で障害発生した場合、今回の機能で提供される「AWSネットワークヘルスインジケータ」の表示が変わるとのことだが、この機能から得られる情報を期待したい。

# 6. 参考
- [Amazon CloudWatch Network Monitor の一般提供を開始](https://aws.amazon.com/jp/about-aws/whats-new/2023/12/amazon-cloudwatch-network-monitor-generally-available/)
    - 本機能のリリース記事。
- [[アップデート] Amazon CloudWatch Network Monitor を AWS-Azure のサイト間 VPN 構成で使ってみた
](https://dev.classmethod.jp/articles/cloudwatch-network-monitor/)
    - 本記事と同様の検証をDirect Connectではなく、インターネットVPN経路で実施。
- [【AWS】Direct Connect フェイルオーバーテスト機能使ってみた](https://qiita.com/taka-s_999/items/7db56cecfc0406034111)　
    - 本記事でも使用した、Direct Connectのフェイルオーバーテストの手順。