2024.12.18 aws

AWSでNetFlow相当のフロー監視を実現する方法｜Network Flow MonitorとVPC Flow Logsの使い分け

オンプレミスでCisco NetFlowを使ってきた運用をAWSへ移すとき、多くの人が最初に突き当たるのが「AWSにNetFlowはあるのか」という疑問です。結論から言うと、AWSはNetFlowやIPFIXのフローレコードをそのまま出力する機能を持ちません。代わりに、フロー情報を扱う用途を「メタデータの記録」「パケットの複製」「性能のニアリアルタイム監視」の3つに分け、それぞれ別のサービスで実現します。この記事では、VPC Flow Logs・Traffic Mirroring・Network Flow Monitor（2024年12月GA）の違いと、目的別の選び方を公式仕様に沿って整理します。

まとめ：AWSでNetFlow相当のフロー監視を選ぶ3つの道

AWSでフロー情報を扱う手段は、必要な粒度とリアルタイム性で決まります。NetFlowのような「どの通信がどれだけ流れたか」の記録はVPC Flow Logs、パケット中身まで見る深掘りはTraffic Mirroring、通信の遅延やパケットロスを短周期で追うのはNetwork Flow Monitorが担当します。まず用途を1つに絞り、次の早見表で該当する道を選んでください。

手段 取得できるもの 粒度 リアルタイム性 ペイロード 主な用途
VPC Flow Logs メタデータ（IP・ポート・プロトコル・バイト数） VPC・サブネット・ENI 既定1分（最大10分） 含まない 監査・セキュリティ分析・課金の内訳
Traffic Mirroring パケットそのもの（ヘッダー＋中身） ENI単位 リアルタイム複製 含む 侵入検知・フォレンジック・NetFlow/IPFIX生成
Network Flow Monitor TCPフローの性能（RTT・再送・転送量・健全性） フロー〜AZ・VPC・AWSサービス 約30秒周期 含まない ネットワーク遅延の切り分け・性能監視

AWSに「NetFlow」はあるのか — ネイティブ非対応と代替の考え方

NetFlowは、ルーターやスイッチが通過したトラフィックを「フロー」（同一の送信元/先IP・ポート・プロトコルの組）ごとに集計し、そのメタデータをコレクタへ送るフロー監視の仕組みです。IPFIXはその標準化版にあたります。AWSはこのNetFlow/IPFIXエクスポーターをマネージドサービスとして提供していません。仮想ルーターにあたるVPCの内部構造をユーザーが直接触れないため、従来のNetFlow機器と同じ形での出力はできない、と理解すると整理しやすくなります。

そのうえでAWSは、NetFlowが担っていた役割を用途ごとに別サービスへ分解しています。フローの「記録」はVPC Flow Logs、パケットの「複製」はTraffic Mirroring、通信品質の「監視」はNetwork Flow Monitorです。既存のNetFlowコレクタ資産を使い続けたい場合は、後述のとおりVPC Flow LogsやTraffic Mirroringを起点にサードパーティツールでNetFlow/IPFIX形式へ変換する構成を取ります。

VPC Flow Logs：NetFlow相当のフローメタデータを記録する

VPC Flow Logsは、VPC内のネットワークインターフェースを出入りするIPトラフィックのメタデータを記録する機能で、AWSでNetFlowに最も近い位置づけです。パケットの中身は記録せず、どの通信がいつどれだけ流れたかを残します。

記録される項目と取得レベル

デフォルト形式では、送信元/先IPアドレス、送信元/先ポート、プロトコル番号、パケット数、バイト数、開始/終了時刻、ACCEPT/REJECTのアクションなどが1レコードとして残ります。集計間隔は既定で1分（最大集約間隔オプションで10分まで変更可）、取得の単位はVPC・サブネット・ENI（ネットワークインターフェース）の3レベルから選べます。

2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK

この例は「送信先ポート22（SSH）への通信を、20パケット・4,249バイト受け付けた」ことを表します。NetFlowレコードと同様、通信の内訳を後から分析できる形です。

送信先とNetFlow/IPFIXへの変換

ログの送信先はCloudWatch Logs・Amazon S3・Amazon Data Firehoseから選べます。CloudWatch Logsへ送ればCloudWatch Logs Insightsでのログ分析でクエリ集計でき、S3へ送ればAthena等で長期保管・分析ができます。既存のNetFlowコレクタを活かしたい場合は、nProbeでVPC Flow LogsをNetFlow/IPFIXへ変換する、あるいはGigamonやManageEngine NetFlow Analyzerといったツールでフローレコードを生成する構成が使われます。

向くケースと不向きなケース

VPC Flow Logsは、セキュリティグループやネットワークACLの許可/拒否の可視化、不審な通信の追跡、通信量ベースのコスト按分に向きます。一方、集計は既定1分単位で、RTTやパケットロスといった通信品質は取得できません。ミリ秒単位の遅延を追う性能監視には不向きで、その用途はNetwork Flow Monitorの担当です。

Network Flow Monitor：フローの遅延・パケットロスをニアリアルタイムで可視化

Network Flow Monitorは、Amazon CloudWatch Network Monitoringの一機能として2024年12月にGA（一般提供開始）した、比較的新しいサービスです。VPC内のTCPトラフィックについて、遅延やパケットロスをニアリアルタイムで計測し、障害がアプリ側かAWSインフラ側かの切り分けを助けます。

仕組み — eBPFエージェントによる計測

計測はエージェント方式です。EC2インスタンスやEKSノードに軽量なエージェントを導入すると、その一部がLinuxカーネルのeBPFを使ってTCP接続のイベントを受け取り、もう一部が統計を集約してバックエンドへ送ります。送信間隔は約30秒（最大5秒のジッターあり）です。エージェントはTCP接続のペイロード（中身）にはアクセスせず、IPアドレス・ポート・カウンター・往復時間だけを扱います。Linuxカーネルのフックを使う設計のため、対象はLinuxワークロードのEC2/EKSが中心です（対応リージョンや要件は公式ドキュメントで確認してください）。

取得メトリクスとネットワークヘルスインジケーター（NHI）

取得するのは、TCP往復時間（RTT）、TCP再送、TCP再送タイムアウト、転送バイト数の4つの性能メトリクスです。これらはサブネット・アベイラビリティゾーン・VPC・AWSサービスといった単位に集約され、CloudWatchメトリクスの名前空間AWS/NetworkFlowMonitorから参照できます。あわせて、モニターごとにネットワークヘルスインジケーター（NHI）という二値の指標が出ます。NHIも同じ名前空間のCloudWatchメトリクスとして扱え、値が「Degraded」のときは対象フローの少なくとも1つでAWSネットワーク側の問題が起きていたことを示し、切り分けの初手になります。なおRTTは常に計算されるわけではなく、データが疎になることがあります。

ワークロードインサイトとモニターの2つの使い方

使い方は2段階です。まず「ワークロードインサイト」で、スコープ内の全フローから再送や転送量が突出したトップコントリビューターを俯瞰し、注視すべき通信を見つけます。そのうえで、特定のワークロードを継続的に追う「モニター」を作成すると、フローが経由したネットワークホップの情報やNHIまで含めて詳細に確認できます。スコープはAWS Organizations連携で最大100アカウントまで広げられます。

料金の考え方（2要素課金・初期費用なし）

料金は初期費用なしで、「監視対象リソース（稼働中のエージェント）」と「発行されるCloudWatchメトリクス」の2要素で決まります。作成したモニターの本数ではなくエージェントが動いているリソース数に応じて課金され、これに標準のCloudWatchメトリクス料金が加わる構成です。正確な単価はリージョンで異なり改定もあるため、CloudWatch料金ページのNetwork Monitoringの項で確認してください。

3つのCloudWatchネットワーク監視機能の違い（Flow／Synthetic／Internet）

「network synthetic monitor」「cloudwatch network monitor」で調べると名前が似た機能が並び、混同しやすいところです。CloudWatch Network Monitoringは3つの機能で構成され、監視する区間と計測方式が異なります。

機能 監視する区間 方式 代表的な用途
Network Flow Monitor AWS内のワークロード間・AWSサービス向け通信 パッシブ（エージェント） アプリのネットワーク遅延・再送の切り分け
Network Synthetic Monitor AWSとオンプレミス間のハイブリッド接続 アクティブ（定期プローブ） 専用線・VPN区間の遅延/パケットロス監視
Internet Monitor エンドユーザーとの間のインターネット経路 AWSのグローバル網の計測データ 地域別の到達性・パフォーマンス把握

Network Synthetic Monitorは、AWS上のリソースからオンプレミスの宛先IPへプローブを送って回線品質を測る、能動的な監視です。パッシブに実トラフィックを見るNetwork Flow Monitorとは目的も方式も異なります。なお、外形監視でよく使うCloudWatch Syntheticsによる外形監視はさらに別物で、こちらはHTTPエンドポイントの死活・応答を模擬アクセスで確認する機能です。

目的別の選び方と、やりがちな誤解

迷ったら、いま解きたい問題から逆算するのが確実です。

  • NetFlowで慣れた運用をそのまま持ち込みたい：VPC Flow Logsを起点に、nProbeやGigamonでNetFlow/IPFIXへ変換する。
  • アプリの通信が遅い原因がAWS側か自分側か切り分けたい：Network Flow Monitorで再送・RTT・NHIを見る。
  • 侵入検知やフォレンジックでパケット中身が要る：Traffic Mirroringで対象ENIの通信を監視アプライアンスへ複製する。
  • オンプレミスとの専用線・VPNの品質を測りたい：Network Synthetic Monitorのプローブで区間を監視する。

誤解しやすいのは次の2点です。1つは、Network Flow MonitorをNetFlowの完全な置き換えと考えてしまうこと。実際は計測対象がTCPフローの性能に絞られ、トップコントリビューター中心の見え方でペイロードも持たないため、全通信を漏れなく会計するNetFlowとは目的が違います。もう1つは、リアルタイムの性能監視をVPC Flow Logsでやろうとすること。集計が分単位でRTTも取れないため、遅延の原因追跡には向かず、ログ量とコストだけが膨らみます。アプリ全体の挙動まで見たい場合は、Application Signalsによるアプリ監視やAWS X-RayとCloudWatchの違いもあわせて検討すると、ネットワーク層とアプリ層の役割分担が整理できます。

よくある質問（FAQ）

Q. AWSはNetFlowをサポートしていますか。
NetFlow/IPFIXレコードをそのまま出力するマネージド機能はありません。フローのメタデータはVPC Flow Logs、パケット複製はTraffic Mirroringで取得し、NetFlow形式が必要ならサードパーティツールで変換します。

Q. Network Flow MonitorとVPC Flow Logsはどう違いますか。
VPC Flow Logsは通信の内訳（メタデータ）を分単位で記録するログ機能、Network Flow MonitorはTCPフローのRTTや再送を約30秒周期で追う性能監視です。監査・分析はVPC Flow Logs、遅延の切り分けはNetwork Flow Monitorと役割が分かれます。

Q. Network Flow MonitorはWindowsやUDPトラフィックに対応していますか。
エージェントはLinuxカーネルのeBPFを使い、対象はEC2とEKSが中心です。計測はTCPフローのRTTや再送が対象で、UDP主体の通信は想定されていません。最新の対応要件は公式ドキュメントで確認してください。

Q. Network Flow Monitorの料金はどう決まりますか。
稼働中のエージェント（監視対象リソース）数と、発行されるCloudWatchメトリクスの2要素で課金され、初期費用はありません。単価はリージョンで異なるためCloudWatch料金ページで確認します。

Q. Network Synthetic Monitorとの違いは何ですか。
Network Flow MonitorはAWS内の実トラフィックをパッシブに監視し、Network Synthetic Monitorはオンプレミス宛にプローブを送るハイブリッド接続向けのアクティブ監視です。監視する区間が異なります。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る