ネットワークの「監視カメラ」を使いこなせ！VPCフローログで通信の足跡を読み解く方法
こんにちは！クラウドアーキテクト兼SREの視点から、日々泥臭いインフラの現場を駆け回っている筆者です。
皆さんは、AWSやGCPといったクラウド環境で「ネットワークがなぜか遅い」「心当たりのない通信がある気がする」と不安になったことはありませんか？そんな時、真っ先に頼りになるのが「VPCフローログ」という機能です。
これは言わば、クラウドという巨大な街を駆け巡るパケットたちの「配達記録」。今回は、このログをどう読み解けばトラブルシューティングの達人になれるのか、一緒に紐解いていきましょう。
—
VPCフローログは「郵便配達の送り状」
まずは難しく考えず、身近な「郵便」に例えてみましょう。
皆さんが誰かに荷物を送る時、送り状には「誰から（送信元）」「誰へ（宛先）」「どれくらいの重さ（データ量）」「何個（パケット数）」が書かれていますよね。VPCフローログもこれと全く同じです。
クラウド上でパケットがネットワークを通過するたび、AWSやGCPは自動的に「この通信は誰から誰へ、これだけの量が行ったよ」という記録を書き留めています。これがフローログの正体です。
ログの基本フォーマットを覗いてみる
実際にログの中身を見ると、英単語が並んでいて最初は圧倒されるかもしれません。でも大丈夫、主要な4つの項目さえ押さえれば、ネットワークの全体像が見えてきます。
srcaddr（送信元）：荷物の送り主は誰？（IPアドレス）dstaddr（宛先）：荷物はどこへ届くの？（IPアドレス）packets（パケット数）：荷物は全部で何個に分かれて届いた？bytes（バイト数）：荷物の総重量はどれくらい？
これらを組み合わせることで、「あのサーバーが急に巨大なデータを外部へ送っている！」といった異常にいち早く気づけるようになります。
—
実践：Athenaでログを「見える化」しよう
ログをS3に出力して、AWS Athenaという分析ツールを使うと、SQLで簡単に検索ができます。例えば、「特定のサーバーから外部への通信で、大量のデータを送っている怪しい通信はないか？」を調べるクエリはこんな感じです。
SELECT
srcaddr,
dstaddr,
SUM(bytes) / 1024 / 1024 AS total_mb -- バイトをメガバイトに変換して読みやすく！
FROM
vpc_flow_logs
WHERE
-- 特定のサーバーからの通信に絞り込む
srcaddr = '10.0.1.5'
GROUP BY
srcaddr, dstaddr
ORDER BY
total_mb DESC; -- 通信量が多い順に並び替えこのクエリを流すだけで、「あ、このサーバーから外部の怪しいIPへ1GBもデータを送っている！」という事実が一発で判明します。現場では、こうした「通信量のランキング」を作るだけでも、ボトルネックの特定に大きく貢献できるんですよ。
—
現場で役立つ「解析の勘所」
私がトラブルシューティングを行う際、必ずチェックするポイントを2つだけ伝授しますね。
1. bytes と packets の比率を見る
パケット数に対してバイト数が異常に少ない場合、それは「接続テスト」や「スキャン攻撃」の可能性があります。逆に、パケット数は少ないのにバイト数が極端に大きい場合、大容量ファイルの転送が行われています。この「比率」に注目すると、通信の質が見えてきます。
2. dstaddr が「どこか」を意識する
ログの中の dstaddr が、社内の別サブネットなのか、それともインターネット上の全く見知らぬIPなのか。これを見極めるだけで、「内部的な通信ミス」なのか「外部への情報漏洩のリスク」なのか、初動対応の優先順位が劇的に変わります。
—
最後に：ネットワークを「相棒」にするために
ネットワークのトラブルは目に見えない分、怖く感じるかもしれません。でも、VPCフローログという「記録」さえあれば、パケットがどこで迷子になり、どこで渋滞しているのかを論理的に追いかけることができます。
最初はログの多さに圧倒されるかもしれませんが、まずは今日紹介した4つの項目を眺めるところから始めてみてください。それが、皆さんがインフラのエンジニアとして一歩前進する大きなステップになるはずです。
もし「こんなログが出て困っている」「この数値はどう解釈すればいいの？」という疑問があれば、ぜひ現場の知見をまた共有させてくださいね。一緒に、堅牢で快適なクラウド環境を作っていきましょう！
コメント