概要
VPC 内でリソースを運用していると、「想定どおりに通信できているか」「不要な通信が発生していないか」を把握したい場面が出てきます。セキュリティグループやネットワーク ACL のルールが過度に厳しくて通信が遮断されていたり、逆に過度に緩くて意図しないアクセスを許してしまっていたりすることは珍しくありません。こうした状況を可視化するには、実際にネットワークを流れたトラフィックの記録が必要です。
VPC フローログは、VPC 内のネットワークインターフェイスを行き来する IP トラフィックの情報を記録する機能です。どの IP アドレスから、どのポートに、どれだけのトラフィックが流れ、それが許可されたか拒否されたかといった情報をログとして残せます。記録されたログは CloudWatch Logs や Amazon S3 などに配信され、トラブルシューティングやセキュリティ分析に活用できます。
本記事では、VPC フローログの基本概念を理解し、VPC に対してフローログを有効化して CloudWatch Logs でトラフィックの記録を確認するところまで体験します。
この記事のメリット
- VPC フローログがどのような情報を記録する機能かを理解できる
- フローログを VPC・サブネット・ネットワークインターフェイスのどのレベルで作成できるかを把握できる
- フローログレコードの主要なフィールドと、
actionの ACCEPT / REJECT の意味を読み解けるようになる - VPC に対してフローログを有効化し、CloudWatch Logs でトラフィックを確認する手順を習得できる
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
VPC フローログとは
クラウドおさるとひさん、VPC を作って EC2 を動かせるようになったんですけど、実際にどんな通信が流れているのか見えなくて不安なんです。これって確認する方法はあるんですか？
土肥いい着眼点だね！そういうときに使うのが VPC フローログだよ。VPC フローログは、VPC 内のネットワークインターフェイスを行き来する IP トラフィックの情報をキャプチャできる機能なんだ。
クラウドおさるネットワークインターフェイス、ですか？
土肥ネットワークインターフェイスは、EC2 インスタンスなどに付いている仮想的なネットワークの差し込み口だと考えるとわかりやすいかな。インスタンスを起動すると自動的に 1 つ付いてくるんだ。フローログは、その差し込み口を通った通信を記録してくれるんだよ。
クラウドおさるなるほど！通信の出入り口にカメラを付けて、流れたものを記録するイメージですね。
土肥まさにそんな感じだね。しかも嬉しいことに、フローログのデータはネットワークトラフィックの経路の外で収集されるから、スループットやレイテンシーには影響しないんだ。だからフローログを作成したり削除したりしても、通信のパフォーマンスを心配する必要はないよ。
どのレベルで作成できるか
クラウドおさるフローログって、EC2 1 台ごとに設定するんですか？
土肥設定する単位は選べるよ。フローログは 3 つのレベルで作成できるんだ。
| 作成レベル | 記録対象 | 使いどころ |
|---|---|---|
| VPC | VPC 内のすべてのネットワークインターフェイス | VPC 全体の通信をまとめて把握したいとき |
| サブネット | サブネット内のすべてのネットワークインターフェイス | 特定のサブネットに絞って調査したいとき |
| ネットワークインターフェイス | 1 つのネットワークインターフェイス | 特定のインスタンスの通信だけを見たいとき |
クラウドおさるVPC レベルで作成すれば、その VPC の中の通信を全部まとめて記録できるんですね！
土肥そのとおり。VPC レベルでフローログを作成すると、その VPC 内のすべてのネットワークインターフェイスが記録対象になるんだ。あとからインスタンスを追加しても、自動的に記録対象に含まれるよ。本記事の実践でも VPC レベルで作成するよ。
ログの出力先
クラウドおさる記録したログって、どこに保存されるんですか？
土肥フローログのデータは、3 つの送信先から選んで発行できるよ。
| 送信先 | 特徴 |
|---|---|
| Amazon CloudWatch Logs | ログをロググループに蓄積し、コンソールから検索・フィルタリングできる |
| Amazon S3 | ログをファイルとして S3 バケットに保存する。長期保管や大量データの分析に向く |
| Amazon Data Firehose | ログをストリーミングで他のサービスや外部の分析基盤に配信する |
クラウドおさる3 つもあるんですね。どれを選べばいいんでしょう？
土肥用途次第だね。コンソールですぐにログを眺めたり検索したりしたいなら CloudWatch Logs が手軽だよ。大量のログを安価に長期保管したいなら S3、リアルタイムに別の分析基盤へ流し込みたいなら Data Firehose、という使い分けになるんだ。本記事ではいちばん手軽な CloudWatch Logs を使うよ。
フローログレコードのフィールド
クラウドおさる実際のログって、どんな内容が記録されるんですか？
土肥フローログの 1 行 1 行を「フローログレコード」と呼ぶよ。デフォルト形式のレコードには、次のようなフィールドが順番に並ぶんだ。主要なものを見てみよう。
| フィールド | 説明 |
|---|---|
version | フローログのバージョン。デフォルト形式では 2 |
account-id | 記録対象のネットワークインターフェイスを所有する AWS アカウント ID |
interface-id | トラフィックが記録されるネットワークインターフェイスの ID |
srcaddr | 送信元 IP アドレス |
dstaddr | 送信先 IP アドレス |
srcport | 送信元ポート |
dstport | 送信先ポート |
protocol | IANA プロトコル番号（6 = TCP、17 = UDP など） |
packets | この期間に転送されたパケット数 |
bytes | この期間に転送されたバイト数 |
start | 集約期間内で最初のパケットを受信した時刻（UNIX 秒） |
end | 集約期間内で最後のパケットを受信した時刻（UNIX 秒） |
action | トラフィックが許可されたか拒否されたか（ACCEPT / REJECT） |
log-status | ログの記録ステータス（OK / NODATA / SKIPDATA） |
クラウドおさる送信元と送信先の IP やポート、それに通信量まで記録されるんですね。action っていうのが気になります。
土肥action はトラブルシューティングでいちばんよく見るフィールドだよ。値は 2 種類あるんだ。
土肥ACCEPT は、セキュリティグループとネットワーク ACL のルールによって許可されたトラフィックを表すよ。一方の REJECT は、それらのルールによって許可されなかった、つまり遮断されたトラフィックを表すんだ。
クラウドおさるなるほど！「通信できない」というときに REJECT のレコードを探せば、どこで止まっているのかわかるってことですね。
土肥そういうこと。だからフローログは、過度に制限的なセキュリティグループやネットワーク ACL のルールを調査するのにとても役立つんだ。逆に、本来あってはならない通信が ACCEPT で記録されていれば、ルールが過度に許可的だと気づける。トラフィックの監視やセキュリティ分析にも使えるよ。
クラウドおさるところで、この表のフィールドって全部記録しないといけないんですか？必要なものだけにしたいときもありそうです。
土肥いいところに気づいたね。フローログにはデフォルト形式のほかにカスタム形式もあって、カスタム形式なら記録するフィールドと並び順を自由に選べるんだ。不要なフィールドを省けばストレージコストを抑えられるよ。まずはデフォルト形式で全体像をつかむのがおすすめだから、本記事ではデフォルト形式を使うね。
CloudWatch Logs へ配信するときの IAM ロール
クラウドおさるCloudWatch Logs に配信するとき、何か準備が必要だったりしますか？権限まわりが心配で…。
土肥そう、CloudWatch Logs へフローログを配信する場合は、専用の IAM ロールが必要になるよ。フローログのサービスがそのロールを引き受けて、ロググループにログを書き込むという仕組みなんだ。
土肥ロールには 2 つのポイントがあるよ。1 つは、vpc-flow-logs.amazonaws.com というサービスがロールを引き受けられるようにする信頼ポリシー。もう 1 つは、CloudWatch Logs に書き込むための権限だね。具体的には logs:CreateLogGroup、logs:CreateLogStream、logs:PutLogEvents、logs:DescribeLogGroups、logs:DescribeLogStreams の 5 つのアクションが必要なんだ。
クラウドおさる自分で JSON を書いて作るのは難しそうです…。
土肥安心して。VPC コンソールでフローログを作成するとき、「サービスアクセス」の項目で新しいサービスロールを作成できるんだ。必要な権限を持つロールをコンソールが用意してくれるから、手作業で JSON を書く必要はないよ。本記事の実践でもこの方法を使うね。
クラウドおさるコンソールがロールまで作ってくれるなら安心です！さっそくやってみたいです。
実践
VPC に対してフローログを有効化し、CloudWatch Logs にトラフィックを記録します。フローログ用の IAM ロールはフローログ作成時に自動で作成し、Web サーバーへの HTTP アクセスを発生させて、記録されたフローログレコードを確認します。
前提条件
- リージョン:
ap-northeast-1（東京） - IAM ユーザーまたはロールに VPC・CloudWatch Logs・IAM ロールの操作権限があること
- 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 説明 |
|---|---|---|
| VPC | fl-vpc | 仮想ネットワーク（CIDR: 10.0.0.0/16） |
| パブリックサブネット | fl-public-subnet | インターネット接続可能なサブネット（10.0.1.0/24、AZ: ap-northeast-1a） |
| インターネットゲートウェイ | fl-igw | VPC とインターネットの接続 |
| ルートテーブル | fl-public-rt | パブリックサブネット用（0.0.0.0/0 → IGW） |
| セキュリティグループ | fl-web-sg | HTTP(80) を 0.0.0.0/0 から許可 |
| EC2 インスタンス | fl-web-server | パブリックサブネットの Web サーバー（Amazon Linux 2023、httpd 起動済み） |
作成するリソース一覧
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| CloudWatch ロググループ | /vpc/flow-logs/fl-vpc | フローログレコードの配信先 |
| IAM ロール | fl-vpc-flow-logs-role | フローログが CloudWatch Logs へ書き込むためのサービスロール |
| VPC フローログ | fl-vpc のフローログ | fl-vpc 内のトラフィックを記録 |
ステップ1: CloudWatch ロググループを作成する
フローログレコードの配信先となるロググループをあらかじめ作成しておきます。
- AWS マネジメントコンソールにログインし、リージョンが
ap-northeast-1（東京）であることを確認します - 上部の検索バーに
CloudWatchと入力し、表示された「CloudWatch」を選択します - 左側ナビゲーションの「ログ」→「ロググループ」を選択します
- 右上の「ロググループの作成」をクリックします
- 以下の内容を入力します
- ロググループ名:
/vpc/flow-logs/fl-vpc - 保持設定:
2 週間（任意。ログの保管期間を選択します） - その他の項目はデフォルトのままにします
- 「作成」をクリックします
- ロググループ一覧に
/vpc/flow-logs/fl-vpcが表示されたことを確認します
ステップ2: VPC に対してフローログを作成する
VPC コンソールから fl-vpc に対してフローログを有効化します。CloudWatch Logs へ配信するための IAM サービスロールは、フローログ作成画面からそのまま自動で作成できます。
- 上部の検索バーに
VPCと入力し、表示された「VPC」を選択します - 左側ナビゲーションの「お使いの VPC」を選択します
- 一覧から
fl-vpcを選択し、下部の「フローログ」タブを選択して「フローログの作成」をクリックします - 以下の内容を入力します
- 名前:
fl-vpc-flow-log - フィルター:
すべて（承諾・拒否の両方のトラフィックを記録します） - 最大集約間隔:
10 分 - 送信先:
CloudWatch Logs に送信 - 送信先ロググループ: ステップ1 で作成した
/vpc/flow-logs/fl-vpcを選択 - サービスアクセス:
新しいサービスロールを作成して使用を選択 - サービスロール名:
fl-vpc-flow-logs-role - ログレコード形式:
AWS のデフォルト形式（デフォルトのまま）
新しいサービスロールを作成して使用 を選ぶと、vpc-flow-logs.amazonaws.com を信頼し CloudWatch Logs への書き込み権限を持つ IAM サービスロールが、フローログ作成と同時に自動で作成されます。信頼ポリシーや権限を手作業で設定する必要はありません。
- 「フローログの作成」をクリックします
- 作成したフローログの詳細画面が表示されます。フローログ ID とステータスが確認できます
fl-vpcの「フローログ」タブで、作成したフローログのステータスがアクティブになっていることを確認します
ステップ3: トラフィックを発生させる
フローログに記録するためのトラフィックを発生させます。fl-web-server の Web サーバーにブラウザからアクセスします。
- 上部の検索バーに
EC2と入力し、表示された「EC2」を選択します - 左側ナビゲーションの「インスタンス」を選択し、
fl-web-serverを選択します - 詳細画面で「パブリック IPv4 アドレス」を確認します
- ブラウザの新しいタブで
http://<fl-web-server のパブリック IP>にアクセスします - Apache のテストページが表示されることを確認します
- ページを数回再読み込みし、トラフィックを発生させます
フローログレコードが集約・配信されるまでに数分かかります。CloudWatch Logs への配信は通常 5 分ほどです。
ステップ4: CloudWatch Logs でフローログレコードを確認する
記録されたフローログレコードを CloudWatch Logs で確認します。
- 上部の検索バーに
CloudWatchと入力し、表示された「CloudWatch」を選択します - 左側ナビゲーションの「ログ」→「ロググループ」を選択します
- ロググループ一覧から
/vpc/flow-logs/fl-vpcを選択します - 「ログストリーム」の一覧に、ネットワークインターフェイスごとのログストリームが表示されます
- 任意のログストリームを選択し、フローログレコードを表示します
- レコードの中から、
srcportまたはdstportが80のものを探します。fl-web-serverへの HTTP アクセスに対応するレコードで、actionがACCEPTになっていることが確認できます - レコードのフィールドを左から順に読むと、送信元 IP・送信先 IP・ポート・プロトコル・パケット数・バイト数などが記録されていることがわかります
ロググループの「ログのインサイト」を使うと、action = REJECT のレコードだけを抽出するといったクエリも実行でき、遮断された通信の調査に役立ちます。
まとめ
- VPC フローログは、VPC 内のネットワークインターフェイスを行き来する IP トラフィックの情報を記録する機能である
- フローログは VPC・サブネット・ネットワークインターフェイスの 3 つのレベルで作成できる
- ログの出力先は CloudWatch Logs・Amazon S3・Amazon Data Firehose から選択できる
- フローログレコードには送信元・送信先の IP やポート、通信量、
action（ACCEPT / REJECT）などが記録され、過度に制限的・許可的なセキュリティグループやネットワーク ACL のルールの調査に役立つ - CloudWatch Logs へ配信する場合は、
vpc-flow-logs.amazonaws.comを信頼し CloudWatch Logs への書き込み権限を持つ IAM ロールが必要になる
参照先
- VPC フローログ
- CloudWatch Logs へのフローログの発行
- CloudWatch Logs へのフローログ発行のための IAM ロール
- CloudWatch Logs に発行するフローログを作成する
- フローログレコード
- フローログの使用
