【テクニカル・上級編】 VPCフローログのサンプリング間隔、集約ウィンドウ、およびドロップパケットの解析 – クラウドインフラと仮想化ネットワーク実践ガイド

ネットワークの迷宮を解く：VPCフローログで「見えないパケット」を可視化する

インフラアーキテクトとして、我々は日々「パケットのゆくえ」に思いを馳せている。AWSのVPCという広大な砂漠において、パケットがどのルートを辿り、なぜ捨てられたのかを追跡することは、まるで暗闇で針に糸を通すような作業だ。

今回は、多くのエンジニアが「なんとなく」設定してしまっているVPCフローログの深淵に潜り込み、その集約のメカニズムと、ドロップされたパケットから何を読み取るべきかを徹底的に解剖する。

—

1. VPCフローログの「時間的制約」という罠

VPCフローログは、ENI（Elastic Network Interface）を通るIPトラフィックをキャプチャする。だが、ここで多くの者が誤解しているのが、これが「リアルタイムのパケットキャプチャ」ではないという点だ。

フローログは、パケットのフローを一定の「集約ウィンドウ」でまとめ上げる。デフォルトでは最大1分（または10分）の集約が行われるが、この間、パケットはメモリ上でカウントアップされ、ウィンドウ終了後にログとして出力される。

なぜこれが重要なのか？

TCPのハンドシェイクやTLSネゴシエーションといった「瞬間的な挙動」を追う際、この1分という集約ウィンドウはあまりに長い。特にマイクロバーストや、TCP SYN floodのような攻撃を検知しようとする場合、このタイムラグが解析の鮮度を著しく低下させる。

最大集約間隔の最適化: リアルタイム性が求められるセキュリティ監視環境では、Max aggregation intervalを1分に設定すべきだ。これ以上長い間隔（10分など）にすると、攻撃者が通信を打ち切った後の事後解析において、時系列の相関が壊滅的になる。

—

2. REJECTされるパケットの背後にある「真実」

REJECTログは、セキュリティグループ（SG）やネットワークACL（NACL）によって破棄されたパケットの墓場である。ここに記録される action フィールドは REJECT だが、その裏側にあるカーネルの挙動を想像してほしい。

なぜ破棄されたのかを特定する

セキュリティグループはステートフルであり、NACLはステートレスだ。この「状態」の有無が、パケットの生死を分ける。

NACLの落とし穴: インバウンドで許可しても、アウトバウンド（エフェメラルポート）を許可していなければ、通信は即座に REJECT される。
解析のヒント: tcp_flags フィールドを確認せよ。もし SYN フラグのみが立っていて REJECT されているなら、それは単純なポート未開放だ。しかし、ACK や RST が混在している場合、それは「接続が確立された後の無効なセッション」として破棄されている可能性が高い。

—

3. パフォーマンスチューニング：RTTとTCPバッファの極致

ネットワークのレイテンシを語る際、AWS環境では物理的なトポロジーが見えない分、論理的なチューニングが鍵を握る。

TCPバッファの最適化（Linuxカーネル）

高スループットを維持するためには、カーネルのTCPウィンドウサイズを最適化する必要がある。デフォルトのままでは、BDP（Bandwidth-Delay Product）が不足し、パイプラインが空の状態が発生する。

# sysctl.conf でTCP送受信バッファの最大値を拡張する
# 10Gbps以上の帯域を考慮した設定例
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

# 設定を反映
sudo sysctl -p

TLSハンドシェイクの短縮

パケットの往復回数（RTT）を減らすには、TLS 1.3 への移行が必須だ。TLS 1.3 はハンドシェイクが1ラウンドトリップで完了し、さらに 0-RTT 機能を使えば、再接続時のオーバーヘッドを限りなくゼロに近づけられる。

—

4. 実践：フローログ解析の自動化パイプライン

ログを眺めるだけではSREとは呼べない。CloudWatch Logs Insightsで異常な REJECT を叩き出すクエリを組もう。

# REJECTされた通信の上位10件を送信元IP別に集計する
filter action = "REJECT"
| stats count(*) as rejectCount by srcAddr, dstPort
| sort rejectCount desc
| limit 10

このクエリを定期的に実行し、rejectCount が急増した瞬間にアラートを飛ばす。これが、攻撃の兆候をいち早く察知する現場の定石だ。

—

終わりに：パケットに心を通わせる

ネットワークは、単なる「データの通り道」ではない。それはシステムの心臓部であり、すべての不調はパケットの振る舞いに現れる。

VPCフローログを単なる「トラブル時の資料」として扱うのはもったいない。パケットの集約間隔、フラグのパターン、そしてLinuxカーネルのバッファ設定。これら一つひとつを深く理解し、最適化することで、初めて「強固で速い」インフラが完成する。

さあ、次はどのパケットを追跡しようか？ネットワークの深淵を覗く準備は、もうできているはずだ。