【Flowmon × AWS】VPCフローログ連携で実現するクラウド通信可視化
2025年7月1日
はじめに
クラウド化が進む昨今、お客様の中でも社内サーバのクラウド移行を検討している、または既に移行しているというようなケースをよく耳にします。クラウド移行を検討しているお客様では、オンプレミスで設置している移行前のサーバに対して現状どれだけの通信が発生しているのかをまず可視化し、それをもとに移行後のキャパシティプランニングやローカルブレイクアウトの計画に役立てたいというようなご用件から、トラフィック可視化ツールFlowmonにご注目いただくことが多いです。既に移行を済ませているようなお客様でも、クラウドサーバとの通信可視化の必要性はオンプレ環境と変わりません。これらのようなケースでは、可視化対象はオンプレ端末-オンプレサーバ間及びオンプレ端末-クラウドサーバ間の通信となり、いずれもオンプレ側が基点となります。では、例えばクラウド上のVM同士の通信を見たい場合はどのような方法が取れるでしょうか。FlowmonではAWS（Amazon web Service）、Azure、GCP（Google Cloud Platform）の3種類のクラウドサービスと連携し、クラウドの内部通信を可視化することができます。本コラムではAWSにフォーカスし、連携方法や可視化検証をご紹介いたします。
VPC Flowログとは
AWSの内部通信は、VPC（Virtual Private Cloud）のFlowログという機能を使用することで可視化が可能です。このFlowログはCloudWatch Logs Insightsを使ってマネジメントコンソールから確認する方法や、S3バケット経由でAmazon Athena・AWS Glueなどの解析ツールと連携する方法が一般的ですが、FlowmonのFlowログ連携機能を使うことでFlowmon Collectorでも表示することができます。この機能ではFlowログをIPFIX（NetFlow）形式で収集します。収集したログは通常のネットワーク機器で生成したFlowと同様に生データ保持・解析ができるため、オンプレとクラウドでツールを分けることなく、Flowmonで一括して扱うことが可能になります。
FlowmonとVPC Flowログの連携
FlowmonとFlowログの連携は、以下のような流れで行われます。
①VPC内のリソース（EC2インスタンス等）で通信が発生すると、②ENI（Elastic Network Interface）単位でFlowログが生成され、③Amazon CloudWatchのロググループに格納されます。④格納されたログをFlowmon Collectorが1分または5分（プロファイル粒度に依存）間隔で取得し、IPFIX形式に変換して保持します。また、Flowmonで対応しているVPC Flowログレコードは、デフォルトフォーマット及びデフォルトのフィールドに「tcp-flags」を追加したカスタムフォーマットの2種類となります。VPC FlowログとIPFIX形式変換後とのフィールドのマッピングは以下の通りです。
なお、カスタムフォーマットを用いる場合は、表に記載の順序でレコードを作成する必要があります。 AWS連携の詳しい設定方法は弊社までお気軽にお問い合わせください。
AWS環境可視化検証
AWS上に下図のような環境を構築し、VPC Flowログを用いて実際にどのように可視化ができるのかを検証いたしました。
Flowmonは物理版のほかにAWS等の仮想環境にも対応したアプライアンスをご用意しており、AWS版ではAWS Marketplaceにてデプロイ可能なAMI（Amazon Machine Image）を公開しております。今回の構成ではAWS版Flowmon Collector（Collector_EC2）と検証用のダミーサーバ（Test_EC2）を1台ずつデプロイし、これらのインスタンス間で通信を発生させます。Flowログの連携にはデプロイしたCollector_EC2を使用しておりますが、連携に使用するCollectorはAWS環境に設置されている必要はなく、オンプレ環境の物理Collectorでも問題ありません。 環境構築後、Test_EC2からCollector_EC2に対してping、ssh、curl（HTTPS）を実行し、これらの通信をCollector_EC2で確認しました。表1に記載の情報が取得されるはずですので、「フローのリスト」解析を用いて以下の項目を出力しています。
- 開始時間 – 最終確認
- 期間
- 送信元IPアドレス
- 宛先IPアドレス
- 送信元ポート
- 宛先ポート
- プロトコル
- パケット
- バイト
- パケット/秒
- ビット/秒
- バイト/パケット
- フロー
- TCPフラグ
- 入力インターフェース
- FlowソースIPアドレス
実際に取得された情報は以下の通りです。
それぞれの項目がきちんと取得されており、pingの場合はプロトコルが「ICMP」、宛先ポートが「Echo reply」となっています。また、sshやcurlの場合はポートがそれぞれ「ssh」、「https」となっているほか、TCP通信のためカスタムフィールドのTCPフラグも取得されました。入力インターフェースにはENIのIDが記載されています。また、VPC Flowログのフィールドにはありませんが、FlowソースIPアドレスにはCloudWatchロググループの名前が出力されました（IPアドレス部分は127.128.0.xで、Flowソースとして認識された順に0から振られていきます）。このように、ロググループ単位でFlowソースとして認識されるため、ロググループを複数作成することで別々のFlowソースとして管理することが可能です。CollectorでVPCの通信を取得できることが確認できましたが、AWS CloudWatchで直接Flowログを確認できるLogs Insights機能ではどのように見えるのでしょうか。
図4は、図3と同じpingの通信ログをCloudWatch Logs Insightsから確認した画面です。こちらでは、Flowmonでは非対応の「accountId」や、セキュリティグループ・ネットワークACLでの処理結果を示す「action」（ACCEPT/REJECT）なども確認できます。また、Flowログから通信量の多いIPアドレスや使用されているポートの統計であったり、通信量の推移をグラフで出力したりといった解析を行うこともできますが、クエリコマンドを入力する必要があり初心者では手を出しづらい印象があります。
一方、Flowmonでは、統計解析やトラフィックグラフ描画がGUIで簡単に行えます。
VPC Flowログで取得したデータと通常のネットワーク機器から収集したFlowデータとは同等に扱われ、解析機能などに差はありません。また、このことから、VPCから生成したFlowログとオンプレ環境で生成したFlowをCollector 1台で同時に扱うことができ、環境によって複数のツールを使い分ける手間を省くことができます。加えて、オンプレ環境とAWS環境両方に監視ポイントを設けることで可視化できる範囲が拡張でき、双方のトラフィックデータを組み合わせることでより詳細な解析も可能になるといえます。
5. おわりに
本コラムでは、Flowmonを用いてAWS環境の可視化を実現する、VPC Flowログ連携についてご紹介しました。今回はAWSに焦点を絞ってご紹介しましたが、ほかにもAzureやGCPといったクラウドサービスにも対応しております。オンプレ環境だけでなくクラウド環境まで可視化範囲を広げることで、Flowmonを最大限活用いただければと思います。
◆Flowmonについて、より詳しく知りたい方は、下記の資料をぜひご覧ください。
細かく相談されたい方は、こちらよりお気軽にお問い合わせください。
担当営業が直接Web会議ツールなどで製品のご案内をすることも可能ですので、お気軽にお申し付けください。
- お見積依頼、お問い合わせはこちらからどうぞ
- 03-6205-6082
- 平日AM9:00～17:30（土日、祝祭日、年末年始、および弊社が定める定休日を除く）