[アップデート] CloudWatchでネットワークモニタリングでリージョン間のフローも見れるようになりました!
こんにちは、まるとです。
先日、CloudWatch Network Flow Monitorで新たにリージョン間のモニタリングもできるようになるAWSのアップデートがありました。
今まではVPCやサブネット、アベイラビリティゾーン、対応AWSサービス間のみのモニタリングでしたが、新たにリージョン間も対応したことでより包括的に監視ができるようになりました。
これにより、マルチリージョン戦略においてリージョン間にネットワークの問題が発生したときに原因の切り分けがしやすくなります。
特にNetwork Health Indicatorと呼ばれる、AWS基盤レベルのネットワーク状況を確認できるため、リージョン間で接続ができなくなった場合に原因がAWS基盤レベルなのか、ソフトウェアの問題かを特定しやすくなります。
やってみる
以下の構成図のように、東京リージョン(ap-northeast-1)と大阪リージョン(ap-northeast-3)にそれぞれVPCとEC2を構築し、VPCピアリングで接続します。
その後、CloudWatch Network Flow Monitorでリージョン間のモニタリングをしていきます。
検証にあたり、上記構成図の構築は割愛します。
CloudWatch Network Flow Monitorを利用するにはエージェントのインストール、有効化、IAMロールの割り当てが必要となります。
Systems Managerの管理ノードの場合、ディストリビューターパッケージとして「AmazonCloudWatchNetworkFlowMonitorAgent」が用意されています。
また、SSMドキュメントとして「AmazonCloudWatch-NetworkFlowMonitorManageAgent」が用意されているため、エージェントのインストール・有効化は容易に実施可能です。
詳しくは以下のAWS公式ドキュメントをご確認ください。
また、エージェントがCloudWatch Network Flow Monitorに値を送信できるよう、IAMロールを割り当てる必要があります。
割り当てるべきAWSマネージドポリシーは「CloudWatch Network Flow Monitor」となります。
今回は、上記の設定まで完了した前提でモニタリングを作成していきます。
モニターを作成する
まず初めに、CloudWatch コンソールの「ネットワークモニタリング > フローモニター」から「モニターを作成」をクリックします。
モニター名には任意の名前をつけます。
続いて、ローカルリソースを設定します。
今回は構築したVPCから送信されていることをわかりやすくするために「<リージョンコード>の特定リソース」から「VPCとサブネット」、東京リージョン側のVPCを指定します。
ローカルリソースを設定したらリモートリソースを指定します。
今回は大阪リージョン宛の通信となるため、監視対象として「別のリージョン」から「大阪」を選択します。
内容を確認して問題なければ「モニターを作成」を押下します。
データを流してモニターを見てみる
モニターを作成したら、実際に東京リージョンと大阪リージョン間で通信を行ってみます。
今回は10〜100MBのファイルのやりとりを行ってみました。
この状態でモニターを見てみるとしっかりと反映されていました。
ネットワークの問題が発生していないため、再送信回数は0となっていますが、転送量などは正しく表示されていました。
続いて、tcコマンドで20%ほどランダムでパケットロスを発生させる状態で再度通信を行い、モニタを確認してみます。
意図してパケットロスを発生させているためか、再送信が発生しています。一方でソフトウェア側で意図してパケットロスを発生しているため、ネットワークヘルスインジケーターは正常となっておりAWS基盤の問題ではないことがわかります。
また、再送信が発生した場合は、「Historical Explorer」タブで影響が発生しているフローを図で確認することができ、直感的に経路がわかるようになっています。
終わりに
今までは特定のリージョン内(VPC、アベイラビリティゾーン、対応AWSサービス)のみのモニタリングとなっていましたが、リージョンを越えて対応したことによりさまざまなケースで利用できるようになりました。
可用性や遅延などの観点からマルチリージョンで展開しているシステムの場合は、本サービスを利用することで基盤レベルでネットワークの状況を可視化できるため、問題の早期発見や原因特定に役立つのではないかと思います。
以上、まるとでした!