しばたです。
前回の記事でAmazon CloudWatch Network Monitorを実際に試してみて、これまでサービスの目的や監視対象について誤解していたところがあったので簡単に解説します。
AWSから公式なベストプラクティスがまだ出ていないため本記事の内容はあくまでも「私見」となりますので予めご了承ください。
Amazon CloudWatch Network Monitorの監視対象
改めてサービスページから概要を引用すると
Amazon CloudWatch Network Monitor provides visibility into the performance of the network connecting your AWS hosted applications to your on-premises destinations and allows you to identify the source of any network performance degradation within minutes.
とあり、AWSとオンプレミスネットワークが接続されている環境に対して「ネットワーク接続のパフォーマンス」を可視化し監視するサービスであることが記載されています。
加えて
Network Monitor focuses monitoring on the routes taken by flows from your AWS hosted resources instead of broadly monitoring all flows from your AWS Region.
とも記載されており、ネットワーク接続のうち2点間のルートをその対象としています。
監視対象が2点間ルートなので取得可能なメトリクスが
- パケットロス率
- ラウンドトリップタイム(RTT)
の2となります。
ここまでをまとめるとざっくり下図のイメージです。
(Direct Connect経由でオンプレミス環境と接続しているケース)
私は最初VPC内のプローブから指定の宛先(送信先)に対して監視用パケットを送出する点だけを見て「宛先に対する監視」と誤解してしまったのですが、「Network Monitor」の名が示す通り監視の主体はネットワークです。
私見
監視対象がネットワークの2点間ルートであるのならばプローブと送信先の間には極力邪魔なものが混ざらない様にすべきでしょう。
CloudWatch Network MonitorではDirect ConnectやSite-to-Site VPNを介したAWSとオンプレミス環境の2点をメインターゲットとしているのでAWS・オンプレミス環境それぞれの"端"に近ければ近いほど邪魔なものが入る余地が無くなります。
送信先に指定すべき対象
ドキュメントに明記されていないものの、内容を見る限り「送信先は常に疎通可能(ダウンしない)」であることが前提である様に見えました。
加えてパケットロス率とRTTを適切に記録するために送信先は安定した応答を返すことが求められます。
これらの点から送信先にはスイッチやルーターなどのネットワーク機器を選ぶのが適切だと思います。
AWSとしてはあくまでも「IPで指定」としか言っていませんが、こちらのブログの例でも送信先に172.16.100.1や172.16.200.1とそれっぽいIPアドレスが設定されています。
(実際にネットワーク機器かは明言されていません)
そしてオンプレミス環境における"端"は顧客ルーターになります。
顧客ルーターのLAN側インターフェイスのIPアドレスが送信先として一番適切そうです。
環境によっては顧客ルーターではなくルーターに近いスイッチなどの機器を選んでも良いでしょう。
大事なのは
- 常に起動している
- 安定した応答を返す
- ネットワークの"端"に近い
という要素を満たせる機器のIPアドレスを選ぶことです。
プローブを配置すべきサブネット
AWS側となるVPCは仮想ネットワークであるため"端"を決めるのが困難です。
論理的にはVGWが"端"になるでしょうが「VGWに一番近いサブネット」なんて決めようがありません。
こちらは基本的に「計測のスタート地点としたい」サブネットを選ぶ形で良いと思います。
たとえば
- オンプレミス環境と疎通するリソース(EC2など)が一番多いサブネット
- オンプレミス環境と疎通する一番重要なリソースが存在するサブネット
など監視の目的に応じて選ぶと良さそうです。
既存サブネットのIPアドレスが枯渇ぎみでない限りプローブ用に専用のサブネットを設ける必要は無いと思います。
また、プローブをMulti-AZで配置すべきかは要件次第ですが、オンプレミス環境との安定した疎通が重要視されていなければそもそもCloudWatch Network Monitorを導入しないでしょう。
そういう意味で必然的に各AZからの監視が必要となりプローブをMulti-AZで配置することになると思います。
特定リソースを送信先に選ぶパターン
ここまでネットワークを監視するという点にフォーカスしてきましたが、オンプレミス環境に極めて重要なリソースがある場合は「2点間の疎通監視」を重視するのもアリだと考えます。
たとえば「何らかのWEBサービスをAWS上で公開しているが、オンプレミス環境に極めて重要なリソース(たとえば専用データベースなど)があり、リソースに対して安定して・遅延なくアクセスすることが求められる」といったケースにもCloudWatch Netowrk Monitorを使えそうです。
AWS側のアプリケーションが配備されているサブネットにプローブを用意し、送信先にオンプレミス環境の重要リソースを指定すれば2点間の疎通を監視できます。
これにより万が一トラブルが発生した際に「ネットワークの不調によるものか？それともそれ以外か？」の切り分けができるはずです。
(AWS上のアプリケーション⇔オンプレミス環境の重要リソースの2点間監視をする例)
オンプレミス環境の重要リソースに直接監視パケットを送ることの是非はあると思うのでそこは個別に検討すると良いでしょう。
余談 : AWS Network Health Indicator (NHI)の監視対象について
オンプレミス環境との接続にDirect Connectを使用している場合、AWS Network Health Indicator(NHI)が利用可能とされています。
ドキュメントではNHIについて
The metric is a statistical measure of the health of the AWS controlled network path from the AWS hosted resource, which is where the monitor is deployed, to the Direct Connect location.
と記載されており、AWSにホストされたリソースからDirect Connect locationまでのAWS管理ネットワークの正常性を監視した結果をメトリクスに記録してくれます。
具体的な対象までは明言されていませんが「AWSにホストされたリソース」はプローブ用のENIを起点としたAWS内部ネットワーク全体を指すのでしょう。
The Network Health Indicator does not indicate the health of the probe, but only the AWS network.
とも記載されており、あくまでもネットワーク基盤に限定されていることが明言されています。
個人的にはNHIは局所的なAWS Personal Health Dashboardみたいなものと捉えています。
また、Direct Connect locationはその内部でAWS管理の区画(AWS cage)とパートナー・顧客管理の区画(Partner cage)に分かれているのですが、NHIの境界がどちらになるのかは不明でした。
「the AWS controlled network path」とあるのでおそらくAWS cageまでじゃないかと予想しています。
正直わからないことだらけなのでNHIについてはもっと詳しい情報が公開されることを期待します。
最後に
以上となります。
かなり私見を交えて記事を書いておりすべての内容が正解だとは思っていませんのでご注意ください。
ただ、CloudWatch Network Monitorはその名の通りネットワークに対する監視であり2点間ルートを対象としている点だけは押さえてもらえると嬉しいです。
3
