【テクニカル・上級編】 VPCフローログ(VPC Flow Logs)を用いたパケットメタデータのキャプチャ – クラウドインフラと仮想化ネットワーク実践ガイド

AWS VPC Flow Logsの深淵：パケットの「足跡」から読み解くネットワークの真実

ネットワークエンジニアにとって、AWSのVPCはしばしば「巨大なブラックボックス」のように映るかもしれない。しかし、我々SREがその中身を解剖し、パケットがどの瞬間に拒絶され、どの瞬間にインターネットゲートウェイ（IGW）を通過したのかを可視化する手段がある。それが VPC Flow Logs だ。

多くの教科書は「Flow Logsを有効化せよ」と説くが、真のアーキテクトは「そのログの中に何が隠されているか」を読み解く。今回は、パケットのメタデータからネットワークのボトルネックを特定し、セキュリティの穴を塞ぐための「深層心理」に迫る。

なぜ Flow Logs は「ただのログ」ではないのか

VPC Flow Logs は、厳密には「パケットキャプチャ」ではない。IPフローのメタデータである。しかし、このメタデータこそが、TCPのハンドシェイクがどこで詰まっているのか、あるいはMTUサイズが原因でパケットロスが発生しているのかを推定するための最強の武器となる。

特に注目すべきは action フィールドだ。ACCEPT は通信が成功したことを意味するが、REJECT が記録されている場合、それはセキュリティグループ（SG）やネットワークACL（NACL）の壁に阻まれたことを示す。しかし、ここで勘違いしてはならない。REJECT が記録されているからといって、その通信が完全に遮断されているとは限らないのだ。

IGWを巡るパケットの挙動

パケットが IGW を通過する際、VPC Flow Logs はその入り口と出口でどのように振る舞うか。

パブリックサブネット: インスタンスのENI（Elastic Network Interface）とIGWの間でフローが記録される。
プライベートサブネット: NAT Gateway を介した通信の場合、フローは NAT Gateway のENIを通過する際のログとして記録される。

ここで重要なのは、tcp_flags の分析だ。もし SYN パケットは記録されているのに、その後の ACK が見当たらない場合、それはパケットがどこかで破棄されたのではなく、相手方からの応答が「ブラックホール」に飲み込まれている可能性が高い。

極限のネットワークチューニング：カーネルとTCPパラメータ

高負荷なWebアプリケーションでは、VPCのネットワーク境界だけでなく、OS側の TCPバッファ チューニングがボトルネックになる。AWSのインスタンスタイプごとに最適な net.core.rmem_max と net.core.wmem_max を設定しなければ、高スループット時にパケットドロップが多発する。

以下のカーネルパラメータは、私が大規模なKubernetesクラスタのノード構築時に必ず適用する「黄金の定石」だ。

# /etc/sysctl.conf に記述するネットワーク最適化設定
# TCP受信バッファの最大値を拡張し、高レイテンシ環境でのスループットを向上
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# TCPウィンドウサイズを自動調整し、パケットロスに対する耐性を強化
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# TCPの接続キューを溢れさせないためのバックログ増強
net.core.somaxconn = 65535

これらの設定を適用するだけで、RTT（往復遅延時間）が安定し、TLSハンドシェイクの完了速度が劇的に向上する。

セキュリティの「見えない穴」を塞ぐ

Flow Logsを活用して、攻撃の予兆を検知する手法は極めて実践的だ。例えば、特定のプライベートIPからインターネット上の未知のポートへ向けて REJECT が大量に発生している場合、それはインスタンス内部でのマルウェア感染や、設定ミスによるスキャン活動を意味する。

Athenaを用いた異常検知クエリ

AWS Athenaを使用して、特定のENIから発生した REJECT フローを抽出するクエリ例を示す。

-- 特定のプライベートサブネットからのREJECTフローを抽出
SELECT 
    srcaddr, dstaddr, dstport, protocol, COUNT(*) as rejection_count
FROM 
    vpc_flow_logs
WHERE 
    action = 'REJECT' 
    AND srcaddr LIKE '10.0.1.%' -- プライベートサブネットのCIDR
GROUP BY 
    srcaddr, dstaddr, dstport, protocol
ORDER BY 
    rejection_count DESC
LIMIT 20;

このクエリを定期的に実行し、CloudWatch Alarms で閾値監視を行うことで、脆弱性スキャナーが起動する前に「異常なパケットの足跡」を捕捉することが可能になる。

最後に：クラウド時代のネットワークエンジニアリングとは

クラウドのネットワークは、物理的なケーブルの配線から解放された。しかし、その分、論理的なパケットの挙動を追うスキルがより重要になっている。VPC Flow Logs は単なるトラブルシューティングの手段ではなく、クラウド環境における「防衛と最適化の羅針盤」である。

パケットがなぜその経路を辿ったのか。なぜそのポートで拒絶されたのか。その問いを突き詰める先には、常に最適化された高速で安全なネットワーク環境が待っている。インフラアーキテクトとして、ログという「沈黙の証言者」に耳を傾けることを忘れないでほしい。

技術の深淵は、ログの行間にこそ存在しているのだから。