パケットの息遣いを聞け：AWS VPCフローログ V2からV5への進化と、現場で本当に使えるログ設計の極意
ネットワークのトラブルシューティングにおいて、パケットキャプチャは最後の切り札だ。しかし、巨大なマイクロサービス群が稼働するクラウドネイティブな環境において、すべてのENI（Elastic Network Interface）で tcpdump を常時走らせるなどという暴挙は、ストレージコストとパフォーマンスの観点から現実的ではない。
そこで我々SREの強力な武器となるのが、AWS VPCフローログだ。
VPCフローログは、ENIを通過するIPトラフィックのメタデータをキャプチャし、Amazon CloudWatch LogsやAmazon S3に吐き出してくれる。しかし、「とりあえず有効化しておけばいいや」とデフォルト（V2）のままで運用しているテックリードやセキュリティエンジニアはいないだろうか？
本稿では、VPCフローログのログフォーマット仕様の変遷、特にV2からV5へのフィールド拡張がネットワーク観測性に何をもたらしたのか、パケットレベルの挙動やLinuxカーネルの内部処理にまで踏み込んで徹底的に解説する。単なる仕様のなぞりではない、現場のトラブルシューティングとセキュリティインシデント対応で生き残るための知見を共有しよう。
—
1. VPCフローログの正体：ハイパーバイザー層でのサンプリングと「見えないパケット」
まず大前提として、VPCフローログがどこで生成されているかを知る必要がある。
AWSの仮想化基盤（AWS Nitro Systemや従来のXen基盤）において、フローログはENIがアタッチされているホストのハイパーバイザー層、あるいはNitroカード上で非同期に処理される。
ここで重要なのは、「パケットそのものが記録されるわけではない」という点だ。記録されるのは、一定の集約期間（Aggregation Interval：デフォルト60秒、最短1分）内に観測されたフローの「メタデータ」の集約値である。
サンプリングと集約のメカニズム
Linuxカーネルの netfilter や iptables のログとは異なり、AWSのフローログはハードウェア/ハイパーバイザーレベルでフローを集約（Aggregation）している。
同一の5タプル（srcaddr, dstaddr, srcport, dstport, protocol）を持つパケットは、集約期間内であれば1行のログレコードにまとめられ、packets と bytes がインクリメントされる。
しかし、この「集約」が災いして、瞬発的なバーストトラフィックやSYNフラッド攻撃の初期段階を見落とす原因になることがある。最短1分の集約間隔の間に行われた大量の微小なコネクションは、1つのレコードに丸め込まれてしまうのだ。高精度なセキュリティ分析やDDoSの兆候検知には、この特性を頭に入れた上でログを解釈しなければならない。
—
2. ログフォーマットの変遷：V2からV5への進化がもたらしたもの
VPCフローログのフォーマットは、バージョンアップに伴い観測可能なメトリクスを劇的に増やしてきた。それぞれのバージョンの違いを、ネットワークスペシャリストの視点で解剖する。
V2：すべての基本だが情報不足のレガシー
V2はAWS VPCフローログの初期から存在するデフォルトフォーマットだ。
${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}- 課題: トランスポート層のステータスや、パケットがどちらの方向（Ingress/Egress）に流れたのか、あるいはパケットがどのAWSリソース起源なのかを判別するためのコンテキストが圧倒的に不足している。
V3 & V4：パケット方向とトラフィックパスの可視化
V3では、トラフィックの方向を示す tcp-flags、パケットの向きを示す flow-direction、そしてパケットの送受信元/先を識別する traffic-path が追加された。
特に flow-direction は画期的だった。NATゲートウェイやトランジットゲートウェイ（TGW）を介する複雑なルーティング環境において、そのトラフィックがENIにとって「流入（ingress）」なのか「流出（egress）」なのかを明確に切り分けられるようになった。
V5：レイテンシー計測とステートフルパケットインスペクションの極み
そして、現代のクラウドインフラストラクチャにおいて必須となるのがV5である。V5では以下のフィールドが追加され、アプリケーション層のパフォーマンスボトルネックやセキュリティインシデントの深掘りが可能になった。
pkt-src-addr/pkt-dst-addr: カプセル化（VPCピアリングやTGWなど）される前の元のパケットの送信元/宛先IPアドレス。region/az-id: トラフィックが通過したリージョンおよびアベイラビリティーゾーン。pkt-src-aws-service/pkt-dst-aws-service: 通信の相手先が特定のAWSサービス（S3やDynamoDBなど）である場合に識別される。- TCPフラグの細密化: TCPのハンドシェイクやティアダウンの挙動を追うためのフラグが完全に網羅された。
—
3. 実践：カスタムフォーマットを活用した極限のパフォーマンス・セキュリティ監視
V2のデフォルトフォーマットだけで満足しているインフラエンジニアは、宝の山の上に座りながら目隠しをしているようなものだ。
ここでは、現場で即座に採用すべき、V5のフル機能を活用したカスタムフローログの定義例と、その活用法を紹介する。
AWS CLIによるV5カスタムフローログの作成
以下のAWS CLIコマンドを実行することで、すべての主要なメタデータを含むリッチなV5フローログをS3バケットに出力させることができる。
aws ec2 create-flow-logs \
--resource-type VPC \
--resource-ids vpc-0123456789abcdef0 \
--traffic-type ALL \
--log-destination-type s3 \
--log-destination arn:aws:s3:::my-production-vpc-flow-logs-bucket \
--log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${flow-direction} ${traffic-path} ${pkt-src-addr} ${pkt-dst-addr} ${tcp-flags} ${sublocation-type} ${sublocation-id}'- 日本語コメント付き解説:
--traffic-type ALL: 許可されたトラフィック (ACCEPT) だけでなく、セキュリティグループやNACLでドロップされたパフィック (REJECT) もすべてキャプチャする。セキュリティ監査の基本である。--log-format: V2の基本情報に加え、flow-direction（方向）、traffic-path（パス）、カプセル化前の元IP（pkt-src-addr）を明示的に指定している。これにより、複雑なルーティングループや不正アクセスの起点をピンポイントで特定できる。
—
4. パケットとカーネルの挙動から読み解くトラブルシューティング事例
ここからは、実際に現場で遭遇したシビアな障害と、VPCフローログを用いた解決のプロセスを紐解こう。
ケース1：TLSハンドシェイクのタイムアウトと tcp-flags の解析
マイクロサービス間で突発的なコネクションタイムアウトが発生した。アプリケーションログには Connection timed out とだけ出力されている。
ここでVPCフローログ（V5）の出力を確認する。
5 123456789012 eni-0abcd1234567890ef 10.0.1.50 10.0.2.100 45832 443 6 1 60 1672531200 1672531260 REJECT OK ingress 2 10.0.1.50 10.0.2.100 2 0 0- 解析のポイント:
${protocol}が6（TCP）であり、${action}がREJECTになっている。- 末尾の
${tcp-flags}が2（これはSYNフラグのみが立っている状態、すなわちSYNパケット）を示している。 - つまり、送信元（
10.0.1.50）から宛先（10.0.2.100のポート443）へ向けてTCPのSYNパケットは飛んでいるが、宛先側のセキュリティグループ（Security Group）またはネットワークACL、あるいはホスト内のLinuxカーネル（iptables/nftables）によって完全にドロップ（あるいはRST返却なしの破棄）されていることが即座に判別できる。 - もしこれが
SYN-ACK（フラグ値18）の段階で止まっていれば、アプリケーション層の過負荷やバックログの枯渇（somaxconn溢れ）を疑うべきだが、最初のSYNで落ちているため、インフラストラクチャのネットワーク境界（セキュリティグループのミス設定など）に原因があると確信を持って絞り込める。
ケース2：MTUブラックホール問題とコネクションハング
AWSのVPC内では通常MTUは9001バイト（ジャンボフレーム）または1500バイトに設定されているが、外部の特定のパートナー網やVPN（AWS Site-to-Site VPN）を通過する際に、適切なMSSクランプ（Maximum Segment Size）が行われていないと、巨大なパケットが途中でドロップされる「MTUブラックホール問題」が発生する。
この時、VPCフローログの ${bytes} と ${packets} の比率、および ${log-status} に注目する。
packets 数に対して極端に ${bytes} が大きいフローが途中で途絶え、REJECT や NODATA（パケットが流れていない状態）に遷移する場合、ICMP Destination Unreachable (Fragmentation Needed) が適切に処理されていない可能性が高い。
フローログから該当するトラフィックの通信元を特定し、Linuxインスタンス側で iptables -A OUTPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu が正しく効いているかを検証する材料として活用できる。
—
5. 高度なセキュリティ監視とSRE的プラットフォーム設計
VPCフローログは、単にS3に保存して終わりではない。膨大なログデータをいかにリアルタイムに処理し、インシデントの予兆を検知するかという「オブザーバビリティ（可観測性）パイプライン」の構築がSREの腕の見せ所だ。
アーキテクチャのベストプラクティス
1. ストリーミング収集: VPCフローログの宛先を Amazon Kinesis Data Firehose に指定する。
2. ストレージと分析: Firehoseを経由して、Amazon S3（Parquet形式に変換して保存、コスト最適化）および Amazon OpenSearch Service や Amazon Athena に流し込む。
3. セキュリティ検知 (SIEM): Amazon GuardDuty は内部でVPCフローログを機械学習モデルにかけ、不審なポートスキャンやC&Cサーバーとの通信を検知しているが、自社固有のビジネスロジックに基づく異常検知（例：「本来通信してはならない内部セグメントへのアクセス試行」など）は、AthenaやOpenSearch上のカスタムクエリで常時モニタリングする。
—
まとめ：パケットの文脈を読めるエンジニアであれ
クラウドがどれほど抽象化され、サーバーレスやコンテナが当たり前になっても、その下層で動いているのは厳然たる「IPパケット」のやり取りに他ならない。
VPCフローログのV2からV5への進化は、我々にインフラストラクチャの深部を覗き込むための強力なレンズを与えてくれた。
ログを単なる「テキストの羅列」としてではなく、パケットが発する「息吹」や「シグナル」として捉えられるか否か。それこそが、障害発生時に数分で原因を特定し、システムの信頼性を守り抜く一流のインフラエンジニアと、そうでない者を分かつ境界線なのである。
さあ、今すぐあなたのAWS環境のVPCフローログ設定を見直し、V5へのアップグレードとカスタムフォーマットの導入に着手してほしい。ネットワークの静寂の裏で何が起きているのか、そのすべてがログという名のキャンバスに鮮明に描き出されるはずだ。
コメント