--- title: "AWSでNetFlow相当のフロー監視を実現する方法｜VPC Flow Logs・Traffic Mirroring・Network Flow Monitorの使い分け" url: "https://www.issoh.co.jp/tech/details/4557/" published: 2024-12-18 updated: 2026-10-29 categories: ["AWS"] publisher: "株式会社一創" --- # AWSでNetFlow相当のフロー監視を実現する方法｜VPC Flow Logs・Traffic Mirroring・Network Flow Monitorの使い分け オンプレミスでNetFlowやIPFIXを使ってきた運用をAWSへ移すと、まず「AWSのどこからNetFlowを出せばいいのか」で止まります。答えは、AWSにNetFlow/IPFIXのエクスポーター機能は無く、フローの記録はVPC Flow Logs、パケットの複製はTraffic Mirroring、遅延やパケットロスの監視はNetwork Flow Monitorと、用途ごとに別の機能で置き換える、です。この記事では3つの違いを、作成コマンド・NetFlow風の集計クエリ・東京リージョンの単価（2026年10月時点のAWS Price List）つきで整理します。 ## まとめ：AWSでNetFlowの代わりに使う3つの機能と選び方 「誰と誰がどれだけ通信したか」を残すならVPC Flow Logs、パケットの中身まで見るならTraffic Mirroring、通信の遅さがAWS側の問題かを切り分けるならNetwork Flow Monitorです。NetFlowに一番近いのはVPC Flow Logsで、既存のNetFlowコレクタへ流したいときもVPC Flow Logsを変換して使います。 | 機能 | 取れるもの | 単位 | 鮮度 | 中身 | 東京の主な単価 | | -------------------- | --------------------- | ------------- | ----------------- | ---- | -------------- | | VPC Flow Logs | 5タプル・パケット数・バイト数・許可/拒否 | VPC・サブネット・ENI | 集約は最大10分か60秒＋配信数分 | 含まない | S3宛0.38ドル/GB | | Traffic Mirroring | パケットそのもの（VXLANで転送） | ENI | リアルタイム | 含む | 送信元1つ0.018ドル/時 | | Network Flow Monitor | TCPのRTT・再送・転送量・NHI | EC2・EKSノード | 約30秒ごと | 含まない | 1台0.0069ドル/時 | ## NetFlowの仕組みとAWSに専用機能が無い理由 NetFlowは、ルーターやスイッチ（エクスポーター）が通過したパケットを送信元/宛先IP・ポート・プロトコルなどが同じ組ごとに「フロー」として集計し、フローレコードをUDPでフローコレクタへ送る仕組みです。Ciscoが作ったNetFlow v5は項目が固定、v9はテンプレートで項目を定義でき、v9をもとにIETFで標準化したのがIPFIX（[RFC 7011](https://www.rfc-editor.org/rfc/rfc7011)）です。 AWSのVPCでは、利用者がルーターに当たる部分へ設定を入れられません。そのためNetFlowやIPFIXのレコードを出す機能はありません。代わりにVPC Flow Logsが、ENIごとの5タプル単位でフローを集約したスペース区切りのテキストかParquetを、CloudWatch Logs・S3・Data Firehoseへ書き出します。S3宛ての出力形式はテキストとParquetの2つで、NetFlowやIPFIXは選べません。項目はNetFlowとよく似ていますが形式は別物なので、NetFlowコレクタで受けるには変換が要ります。 ## VPC Flow Logsの記録項目・集約間隔・作成設定 VPC Flow LogsはVPC・サブネット・ENIのどれかに付け、VPCやサブネットに付けると配下の全ENIが対象になります。フローログはトラフィックの経路の外で集められるため、作成・削除しても通信のスループットや遅延には影響しないと[AWSの規範ガイダンス](https://docs.aws.amazon.com/ja%5Fjp/prescriptive-guidance/latest/logging-monitoring-for-application-owners/vpc-flow-logs.html)に書かれています。 ### 記録される項目とカスタム形式（バージョン2〜11） デフォルト形式はバージョン2の14項目で固定です。version・account-id・interface-id・srcaddr・dstaddr・srcport・dstport・protocol・packets・bytes・start・end・action・log-statusが並びます。 ``` 2 123456789010 eni-1235b8ca123456789 172.31.16.139 172.31.16.21 20641 22 6 20 4249 1418530010 1418530070 ACCEPT OK ``` これは「宛先ポート22（SSH）へのTCP通信を、20パケット・4,249バイト受け付けた」という1レコードです。ほかの項目はカスタム形式で選んで追加します。[フィールド一覧](https://docs.aws.amazon.com/vpc/latest/userguide/flow-log-records.html)では、tcp-flags・pkt-srcaddr・pkt-dstaddrがバージョン3、flow-direction・traffic-pathがバージョン5、ECSのタスクやサービス名がバージョン7、BPAなどによる拒否の理由を示すreject-reasonがバージョン8、インスタンスやENIのタグ・次ホップのENIがバージョン11で加わっています。NAT GatewayやNLBを経由する通信では、srcaddr/dstaddrに中継側のIPが入るので、元の送信元・宛先を残すならpkt-srcaddrとpkt-dstaddrを足します。 作成後に項目の追加・削除やIAMロールの変更はできず、作り直しになります（[制限事項](https://docs.aws.amazon.com/vpc/latest/userguide/flow-logs-limitations.html)）。後から欲しくなる項目は最初の作成時に入れておくのが安全です。 ### 集約間隔と、ログが届くまでの遅れ 最大集約間隔は既定で10分で、作成時に60秒を指定できます。ENIがNitroベースのインスタンスに付いている場合は、指定にかかわらず常に1分以下です。集約のあと、CloudWatch Logsにはおおむね5分、S3にはおおむね10分で届きます。つまり「異常に気づいて数秒で止める」用途には使えません。NetFlowのアクティブタイムアウトを短くして準リアルタイムで見ていた運用は、ここで遅くなります。 ### aws ec2 create-flow-logsの作成例（S3・Parquet・60秒） 分析をAthenaで行うならS3にParquetで出し、時間単位のパーティションを切るのが扱いやすい構成です。S3宛てはIAMロールが要らず、バケットポリシーでログ配信を許可します（CloudWatch Logs宛ては`--deliver-logs-permission-arn`が必須）。 ``` aws ec2 create-flow-logs \ --resource-type VPC \ --resource-ids vpc-0123456789abcdef0 \ --traffic-type ALL \ --log-destination-type s3 \ --log-destination arn:aws:s3:::example-flow-logs-bucket/vpc/ \ --max-aggregation-interval 60 \ --log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${vpc-id} ${tcp-flags} ${flow-direction} ${traffic-path} ${pkt-srcaddr} ${pkt-dstaddr}' \ --destination-options FileFormat=parquet,HiveCompatiblePartitions=true,PerHourPartition=true ``` `--max-aggregation-interval`に指定できるのは60か600だけです。`--resource-type`にTransitGatewayを指定するとTransit Gateway Flow Logsになり、こちらは60秒が必須で、経路なしやMTU超過で落ちたパケット数も記録できます（[Transit Gatewayのフローログ](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-flow-logs.html)）。この例はAWS CLIの公式リファレンスに沿った指定例です。`--dry-run`は実行権限の確認用で、ログの作成・配信が成功することを保証するものではありません。 ### 記録されない通信 VPC Flow Logsには記録対象外の通信があります。Amazon提供のDNSサーバーへの問い合わせ、インスタンスメタデータ（169.254.169.254）とAmazon Time Sync Service（169.254.169.123）、DHCP、ARP、WindowsのAmazonライセンス認証、既定のVPCルーター予約アドレス宛ての通信です。DNSの問い合わせを追いたいならRoute 53 Resolverのクエリログを別に有効にします。 対象の通信でも、AWS内部の容量制約やエラーで集約間隔中のレコードが欠落する場合があり、そのときはlog-statusにSKIPDATAが入ります。完全な通信量の台帳としては扱えません。 ## フローログのトップトーカー集計と既存ツールへの連携 NetFlowコレクタで見ていた「通信量の多い送信元・宛先の組」は、ログの置き場所に応じて集計します。同じ通信が送信側と受信側のENIに記録されるため、重複計上を避けるには集計対象のENIや観測方向をそろえます。 ### CloudWatch Logs Insightsのクエリ デフォルト形式のログをCloudWatch Logsに送っていれば、Logs InsightsがsrcAddr・dstAddr・bytesなどのフィールドを自動で認識します。次はバイト数の多い組の上位15件で、[公式のクエリ例](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CWL%5FQuerySyntax-examples.html)を通信量の集計に置き換えたものです。 ``` filter action = "ACCEPT" | stats sum(bytes) as bytesTransferred by srcAddr, dstAddr | sort bytesTransferred desc | limit 15 ``` 自動認識はデフォルト形式に限られます。カスタム形式にした場合は`parse @message`で項目を切り出してから集計します。クエリ構文の詳細は[CloudWatch Logs Insightsの料金と使い方｜スキャン課金・limit上限・3つのクエリ言語【2026年版】](/column/details/2900/)にまとめています。 ### nProbeからntopngへの転送例と入力ログの準備 以下はntopngへZMQで送る例で、一般的なNetFlow/IPFIXコレクタへの送信設定とは異なります。S3からテキスト形式のVPC Flow Logsを取得し、処理用ディレクトリへ配置してから実行します。前節のParquet出力をそのまま渡す手順ではありません。 ntopのnProbeは、`-3`オプションにUDPポートの代わりにディレクトリを渡すと、そこに置いたVPC Flow Logsを読み込んでNetFlow/IPFIXに変換し、ntopngなどへ送ります（[ntopの解説](https://www.ntop.org/how-to-collect-and-analyse-aws-vpc-flow-logs/)）。 ``` nprobe -3 /data/vpc --zmq tcp://127.0.0.1:1234 ntopng -i tcp://127.0.0.1:1234 ``` nProbeは読み込み後にログファイルを削除します。VPC Flow Logsにはペイロードが無いので、アプリケーションの判定はポートとアドレスからの推測にとどまります。ManageEngine NetFlow AnalyzerはCloudWatch Logs APIからフローログを取り込む方式で、ロググループ名とIAMの設定が必要です。 ## Traffic Mirroringのパケット複製・対応条件・料金 Traffic Mirroringは、ENIを通るパケットをコピーして、IDSやパケットキャプチャ用の機器へ送る機能です。フローログでは見えないペイロードやTCPの細かい挙動を調べるときに使います。 ### 送信元・フィルター・ターゲット・セッションの関係 監視するENIが送信元、何をコピーするかのルールがフィルター、送り先がターゲットで、この3つをセッションで結びます。ターゲットにはENI、UDPリスナーを持つNLB、Gateway Load Balancerエンドポイントを指定できます。コピーしたパケットはVXLANでカプセル化され、UDPポート4789へ届きます。受信側はVXLANの処理に対応し、ターゲットのセキュリティグループで送信元からのUDP 4789を許可する必要があります（[パケット形式](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-packet-formats.html)）。受け側にSuricataを置く構成は[Suricata（スリカタ）とは？導入からルール作成・IPSモード運用まで【8.0対応】](/tech/details/9989/)が参考になります。 ``` aws ec2 create-traffic-mirror-target --network-interface-id eni-0aaaaaaaaaaaaaaaa --description "suricata sensor" aws ec2 create-traffic-mirror-filter --description "tcp only" aws ec2 create-traffic-mirror-filter-rule --traffic-mirror-filter-id tmf-0bbbbbbbbbbbbbbbb \ --traffic-direction ingress --rule-number 100 --rule-action accept --protocol 6 \ --source-cidr-block 0.0.0.0/0 --destination-cidr-block 10.0.0.0/16 aws ec2 create-traffic-mirror-session --network-interface-id eni-0cccccccccccccccc \ --traffic-mirror-target-id tmt-0dddddddddddddddd --traffic-mirror-filter-id tmf-0bbbbbbbbbbbbbbbb \ --session-number 1 --packet-length 128 ``` `--packet-length 128`はVXLANヘッダーの後ろの先頭128バイトだけを送る指定で、ヘッダー解析が目的なら転送量を大きく減らせます。省略するとパケット全体を送ります。各IDは実環境の値に置き換え、フィルターとターゲットの作成結果で返されたIDを後続コマンドへ指定します。掲載例は受信方向のTCPだけを複製し、送信方向は対象にしません。 ### 対応インスタンスと上限 送信元にできるのは[公式の対応表](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)に載っているインスタンスタイプだけです。Nitro専用ではなく、2021年2月にM4・C4・R4などNitro以外の一部の型が加わり、2025年8月28日の[発表](https://aws.amazon.com/about-aws/whats-new/2025/08/aws-extends-traffic-mirroring-support-new-instance-types/)でNitro v4のインスタンス全般が対象になりました。一方でT2のように表に無い型は使えず、ベアメタルはNitro v2のものに限られます。[クォータ](https://docs.aws.amazon.com/vpc/latest/mirroring/traffic-mirroring-quotas.html)は1つの送信元ENIあたりセッション3つ、1つのフィルターあたりルール10個で、どちらも引き上げできません。1つのターゲットが受けられる送信元は、m7i.48xlargeなど一部の大型インスタンスが100、それ以外は10です。台数が多い環境では、ターゲットをNLBやGateway Load Balancerの後ろに置きます。 ### 料金と、止め忘れで課金が続く落とし穴 東京リージョンの単価は、送信元1つあたり1時間0.018ドルで、1か月（730時間）続けると約13.1ドルです。これにデータ転送料金と、ターゲットをNLBやGateway Load Balancerの後ろに置いた場合はその処理料金が加わります。注意したいのは、[公式ドキュメント](https://docs.aws.amazon.com/vpc/latest/mirroring/what-is-traffic-mirroring.html)が明記しているとおり、送信元のインスタンスを停止・終了しても、ENIを外しても、セッションを削除するまで課金が続くことです。調査が終わったら`aws ec2 delete-traffic-mirror-session`で消します。 ## Network Flow Monitorの性能監視・導入要件・料金 Network Flow Monitorは、CloudWatch Network Monitoringの機能として2024年12月に提供が始まりました。EC2やEKSノードに入れたエージェントがTCP接続を観測し、通信が遅いときに原因がアプリ側かAWSのネットワーク側かを切り分けます。 ### エージェントの要件と対応リージョン エージェントはLinux専用で、カーネル5.8以降が必要です。Amazon Linux・Ubuntu・Red Hat・SUSE・Debianのx86とaarch64で動作確認されています（[対応Linux](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-NetworkFlowMonitor-agents-versions.html)）。エージェントの一部がeBPFでTCPのイベントを受け取り、残りが統計をまとめて約30秒ごとにバックエンドへ送ります。扱うのはIPアドレス・ポート・カウンター・往復時間だけで、ペイロードには触れません。Windowsのインスタンスは監視できず、UDP主体の通信も対象外です。対応リージョンは東京・大阪を含む17リージョンです。 ### 取得するメトリクスとネットワークヘルスインジケーター（NHI） 取得するのはTCPの往復時間（RTT）・再送・再送タイムアウト・転送バイト数の4つで、CloudWatchの名前空間`AWS/NetworkFlowMonitor`に出ます。モニターごとに出るNHIは、指定期間にAWSネットワークの問題が検出されると100、検出されなければ0になります。0はアプリケーションの正常性を保証する値ではありません。RTTは常に計算されるわけではなく、値が欠けることがあります。 使い方は2段階です。最初にワークロードインサイトで、再送や転送量が突出した通信の上位を一覧し、気になる区間を見つけます。次にその区間をモニターとして登録すると、経由したネットワークの区間とNHIまで継続して追えます。 ### 2025年に増えた監視範囲 [2025年5月6日](https://aws.amazon.com/about-aws/whats-new/2025/05/amazon-cloudwatch-network-monitoring-multi-account-flow-monitors/)にAWS Organizationsと連携した複数アカウントのモニターに対応しました。[2025年9月10日](https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-cloudwatch-network-flow-visibility-regions/)にはリージョン間の通信も監視できるようになり、NHIで「ローカルのリージョン・AWSのグローバルネットワーク・相手のリージョン」のどこで劣化したかを分けられます。[2025年11月19日](https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-eks-enhanced-container-network-observability/)に発表されたEKSのコンテナネットワーク可観測性も、Network Flow Monitorを土台にしています。EKSではNetwork Flow Monitorのエージェントアドオン（1.1.0以降）を入れて使います。 ### Network Flow Monitorのリソース時間料金とメトリクス料金 東京リージョンは、エージェントが動いているリソース（EC2インスタンスかEKSノード）1台あたり1時間0.0069ドルです（AWS Price List、2026年10月7日版）。無料枠を適用しない場合、10台を730時間監視するリソース料金は50.37ドルで、CloudWatchメトリクス料金が別途かかります。公式料金例では最初の12か月に10リソース分の無料枠が示されているため、適用条件も確認します。モニターの本数では課金されません。 ## CloudWatch Network Monitoringの3機能の違い（Flow・Synthetic・Internet） 「network synthetic monitor」で調べると似た名前の機能が並びます。CloudWatch Network Monitoringには次の3つがあり、見る区間と測り方が違います。 | 機能 | 監視する区間 | 方式 | 向く用途 | | ------------------------- | ----------------- | ------------- | ----------------------- | | Network Flow Monitor | AWS内のワークロード間 | エージェントで実通信を観測 | アプリの遅延・再送の切り分け | | Network Synthetic Monitor | AWSとオンプレミスの間 | AWS側からプローブを送る | Direct Connect・VPNの品質監視 | | Internet Monitor | 利用者とAWSの間のインターネット | AWSが持つ計測データ | 地域・回線事業者ごとの到達性 | Network Synthetic Monitorはエージェントを入れず、VPCのサブネットからオンプレミスのIPへプローブを送って往復時間とパケットロスを測ります。料金は監視するサブネット1つあたりの時間課金とCloudWatchメトリクス料金の2つで（[料金の仕組み](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/pricing-nw.html)）、東京の時間単価はAWS Price Listで0.11ドルです。1つのサブネットから宛先IP4つまでを測り、CloudWatchへの集約間隔は30秒か60秒から選びます。HTTPのエンドポイントを模擬アクセスで確かめる[CloudWatch Syntheticsとは？Canaryの作り方・ランタイム選定・料金をAWS外形監視の実装目線で解説](/tech/details/4399/)とは別の機能です。 ## 目的別の選び方と、NetFlowの置き換えで失敗する場面 - **NetFlowのダッシュボードを使い続けたい**：VPC Flow LogsをS3に出し、nProbeで変換して既存のコレクタへ送る。 - **通信量の上位や拒否された通信を週次で見たい**：VPC Flow Logs＋Logs InsightsかAthena。 - **アプリが遅い原因がAWS側か知りたい**：Network Flow MonitorでRTT・再送・NHIを見る。 - **侵入検知やフォレンジックでペイロードが要る**：Traffic Mirroringで対象ENIだけを、期間を決めて複製する。 - **オンプレミスとの回線品質を測りたい**：Network Synthetic Monitor。 失敗しやすいのは3つの場面です。1つ目は、Network Flow MonitorをNetFlowの置き換えだと考えること。対象はLinux上のTCPの性能で、上位の通信を中心に見せる設計のため、全通信の量を漏れなく数える用途には合いません。2つ目は、VPC Flow Logsで障害を即時に検知しようとすること。集約と配信で最短でも数分遅れ、RTTも取れません。3つ目は、全ENIにTraffic Mirroringを常時かけること。送信元ごとの時間課金と転送量が積み上がるうえ、1つのターゲットが受けられる送信元は多くの型で10までです。 東京の最初の月間10TBでは、配信・取り込み単価はCloudWatch LogsのStandardが0.76ドル/GB、Infrequent AccessとS3宛てが0.38ドル/GBです。S3宛てには保存料金が別途かかり、掲載CLIのParquet形式では変換料金0.056ドル/GBも加わります。長期保存用はS3、直近の調査用はCloudWatch Logsへ配信する構成が候補です。ただし、保持期間を短くしても取り込み料金は減らず、二重配信の料金も生じるため、S3とAthenaだけで分析する構成と総額を比較します。 ネットワーク費用全体の見方は[ネットワークコストの内訳と計算方法｜実額と削減の優先順位](/tech/details/3810/)で扱っています。アプリ層の監視まで含めた全体像は[AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成【2026年時点】](/tech/details/15297/)、不審な通信をフローログで調べる手順例は[アンドエスティ不正アクセス：250万件の流出項目と対象確認、ポイントと偽メール](/tech/details/19017/)にあります。フローログの設計からCloudWatchの監視基盤の構築まで任せたい場合は、[AWSのインフラ構築支援](/service/system/aws/)でも対応しています。 ## よくある質問 ### AWSはNetFlowやIPFIXに対応していますか？ NetFlow/IPFIXのレコードを出す機能はありません。フローの記録はVPC Flow Logsで取り、NetFlow形式が必要ならnProbeなどで変換します。 ### VPC Flow Logsの集約間隔は何分ですか？ 最大集約間隔は既定で10分で、作成時に60秒を選べます。Nitroベースのインスタンスでは常に1分以下になります。配信にはさらにCloudWatch Logsで約5分、S3で約10分かかります。 ### Network Flow MonitorとVPC Flow Logsの違いは何ですか？ VPC Flow Logsは通信の内訳を記録するログ、Network Flow MonitorはTCPのRTTや再送を約30秒ごとに測る性能監視です。監査や通信量の分析はVPC Flow Logs、遅延の切り分けはNetwork Flow Monitorを使います。 ### Network Flow MonitorはWindowsやUDPに対応していますか？ エージェントはカーネル5.8以降のLinux専用で、Windowsでは動きません。計測するのはTCPのフローで、UDP主体の通信は対象外です。 ### Network Synthetic Monitorとの違いは何ですか？ Network Flow MonitorはAWS内の実際の通信を観測し、Network Synthetic MonitorはオンプレミスのIPへプローブを送ってDirect ConnectやVPNの区間を測ります。監視する区間が違います。 ## 関連記事 - [AWSオブザーバビリティの実装｜ADOT・CloudWatch・Container Insightsで計装する構成【2026年時点】](/tech/details/15297/) - [AWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方【2026年版】](/tech/details/6812/) - [Application Signalsの導入手順｜ECS・EKS・EC2・Lambda別の有効化設定と表示されないときの確認](/tech/details/7452/) - [AWS Network Firewallとは？仕組み・ルール・料金とセキュリティグループとの違いを実装目線で解説](/tech/details/15501/) - [オブザーバビリティ（可観測性）とは？監視・APM・テレメトリとの違いと使い分け](/column/details/3077/) --- 出典: [AWSでNetFlow相当のフロー監視を実現する方法｜VPC Flow Logs・Traffic Mirroring・Network Flow Monitorの使い分け]()（株式会社一創）