VPCフローログでネットワーク通信を見える化しよう

本記事はネットワークウィーク 10日目の記事です。
💻 9日目 ▶▶ 本記事 ▶▶ 11日目 🌐

はじめに
VPCフローログの概要
VPCフローログの設計ポイント
- ① ログの送信先を決定する
- ② VPCフローログの設定内容を決める
VPCフローログを有効化する
- フローログ作成時の注意書きに注目
  - リソースベースのポリシーとは
  - ポリシーはAWSが自動で設定してくれる
- VPCフローログ有効化後の動作確認
VPCフローログの見方
- ログ形式（デフォルト）
  - 各項目の意味
- REJECTの原因がセキュリティグループかネットワークACLかを判別するポイント
  - セキュリティグループはステートフル
  - ネットワークACLはステートレス
まとめ

はじめに

こんにちは、クラウド事業推進部の佐々木です。
今回は、AWS環境におけるネットワークトラブルの調査に役立つ「VPCフローログ（VPC Flow Logs）」についてご紹介します。 AWS上で障害や不具合が発生した際には、「通信が届いているか？」「外部に向けた通信が行われているか？」といったネットワークの状態を可視化することが、原因の特定や早期復旧において非常に重要です。このような場面で活躍するのが、VPCフローログです。
本記事では、実際のプロジェクトでVPCフローログの設定を担当した経験をもとに、導入の流れや注意すべきポイントを整理しました。これからVPCフローログの導入を検討されている方の参考になれば幸いです。

VPCフローログの概要

VPCフローログとは、AWSのVPC内でやり取りされるIPトラフィック情報を記録する機能です。 VPC内の通信状況を可視化できるため、以下のような用途に活用できます。

インスタンスに到達するトラフィックの監視
- どこからアクセスされているのか、どんな通信が来ているかを把握できる。
セキュリティグループの設定が適切かどうかの確認
- セキュリティグループが厳しすぎないか、必要な通信がブロックされていないかを確認できる。
トラフィックの方向の把握
- 通信がインスタンスに入ってきているのか、出ていっているのかを区別できる。

docs.aws.amazon.com

VPCフローログの設計ポイント

VPCフローログの導入にあたって、決めるべき主なポイントは以下の2つです。

① ログの送信先を決定する

VPCフローログは、CloudWatch Logs、 S3、Data Firehoseに発行できます。そのため、要件に応じて適切な出力先を選択することが必要です。

CloudWatch Logs

可視化とモニタリングの強化
- CloudWatch はログやメトリクスを視覚化するダッシュボードを提供しており、ネットワークトラフィックの傾向や異常をリアルタイムで把握できる。 docs.aws.amazon.com

S3

大容量のデータ保存に最適
- S3はスケーラブルかつ高い耐久性を持ち、膨大な量のログデータを長期間安全に保存できる。またコスト効率も良い。
後からの詳細分析に適している
- Athenaなどの分析サービスと連携することで、保存したログに対して効率的にクエリを実行・分析できる。 docs.aws.amazon.com

Data Firehose

多様な配信先への柔軟な連携
- S3やRedshiftなど、指定した宛先へデータをリアルタイムで配信できる。
データ変換・加工の自動化
- Firehose上でデータの変換や圧縮、暗号化が可能であり、ログの前処理を実現できる。 docs.aws.amazon.com

今回、VPCフローログを有効化する目的は「即時監視」ではなく、エラー発生時の調査に備えることでした。そのため、ログの保存先としてはS3を選定しました。
S3を出力先にすることで、前述のとおりAthenaなどの分析サービスと連携し、蓄積されたログをSQLクエリで柔軟に分析できるという利点があります。
さらに、ログを時間別にパーティション分割して保存することで、Athenaはクエリ実行時に該当するパーティション（例：特定の日付のフォルダ）のみをスキャン対象とします。これにより、大量のログデータがあっても、日付などの条件で効率的に絞り込み・分析を行うことが可能です。
なお、出力先となるS3バケットについては、今回新たに作成するのではなく、既存の環境内に用意されていたS3バケットを活用しています。

② VPCフローログの設定内容を決める

次に詳細設計です。今回は以下のように設定します。

項目名	設定値
名前	vpc-flow-logs
フィルタ	すべて（許可・拒否にかかわらず、すべてのトラフィックを記録）
最大集約間隔	10分
送信先	S3バケット
S3バケットのARN	ログを出力するS3バケットのARN
ログレコード形式	AWSのデフォルト形式
ログファイル形式	テキスト（デフォルト）
時間別にログをパーティション分割	24時間ごと（デフォルト）

VPCフローログを有効化する

では実際にマネジメントコンソールでVPCフローログを有効化します。手順はシンプルです。

対象のVPCを選択
「フローログ」タブから「フローログの作成」を選択
出力先にS3バケットを指定し、その他必要な設定を入力
「作成」ボタンをクリックし完了

フローログ作成時の注意書きに注目

フローログ作成画面には、以下のような注意書きが表示されていました。

リソースベースのポリシーが自動的に作成され、ターゲットバケットにアタッチされることに留意してください。

これはどういう意味なのでしょうか。

リソースベースのポリシーとは

AWSではアクセス制御の仕組みとして、「IAMポリシー（ユーザー側）」と「リソースベースのポリシー（リソース側）」の2種類があります。リソースベースのポリシーとは、特定のAWSリソースに対して、「誰がこのリソースにアクセスできるか」をリソース側で制御するためのポリシーです。
VPC フローログの出力先として S3 バケットを指定する場合にも、このリソースベースのポリシーが必要になります。具体的には、S3 バケットに対して VPC フローログサービスが PutObject（オブジェクトの書き込み）アクションを実行できるよう、アクセス許可を与えるポリシーを設定します。これは、S3 バケットのリソースベースポリシーによって実現されます。

docs.aws.amazon.com

ポリシーはAWSが自動で設定してくれる

そのため、VPCフローログを有効化してS3バケットにログを出力する場合、リソースベースのポリシーを設定する必要がありますが、実際にはAWSが必要なバケットポリシーを自動で生成・適用してくれます。 docs.aws.amazon.com

VPCフローログを作成したあと、対象のS3バケットの [アクセス許可] タブから [バケットポリシー] を確認すると、以下のような内容が追加されていました。 AWSログ配信サービスが、指定されたアカウントのS3バケットにログを書き込むためのアクセス権限を許可するとともに、バケットのアクセス制御情報（ACL）を読み取ることも許可しています。

  
{
    "Version": "2012-10-17",
    "Id": "AWSLogDeliveryWrite20150319",
    "Statement": [
        {
            "Sid": "AWSLogDeliveryWrite1",
            "Effect": "Allow",
            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::s3bucket-test/AWSLogs/123456789012/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012",
                    "s3:x-amz-acl": "bucket-owner-full-control"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:logs:ap-northeast-1:123456789012:*"
                }
            }
        },
        {
            "Sid": "AWSLogDeliveryAclCheck1",
            "Effect": "Allow",
            "Principal": {
                "Service": "delivery.logs.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::s3bucket-test",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:logs:ap-northeast-1:123456789012:*"
                }
            }
        }
    ]
}

VPCフローログ有効化後の動作確認

VPCフローログを有効化した後、対象のS3バケットに設定どおりログが出力されていることを確認します。

  
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-00a0a00a000000a00 xx.xx.xx.xx xx.xx.xx.xx 51498 443 6 3 187 1746057586 1746057611 ACCEPT OK
2 123456789012 eni-00a0a00a000000a00 xx.xx.xx.xx xx.xx.xx.xx 51232 443 6 8 1051 1746057586 1746057611 ACCEPT OK
2 123456789012 eni-00a0a00a000000a00 xx.xx.xx.xx xx.xx.xx.xx 53455 9330 6 1 44 1746057586 1746057611 REJECT OK
2 123456789012 eni-00a0a00a000000a00 xx.xx.xx.xx xx.xx.xx.xx 443 51232 6 8 4171 1746057586 1746057611 ACCEPT OK
2 123456789012 eni-00a0a00a000000a00 xx.xx.xx.xx xx.xx.xx.xx 53002 9736 6 1 44 1746057586 1746057611 REJECT OK
2 123456789012 eni-00a0a00a000000a00 xx.xx.xx.xx xx.xx.xx.xx 443 51498 6 1 52 1746057586 1746057611 ACCEPT OK

許可された通信（ACCEPT）と拒否された通信（REJECT）の両方が、テキスト形式で正しく出力されていることを確認できました。しかし、実際にログファイルを開いてみると、まるで暗号のような文字列がずらりと並んでいるため、戸惑うかもしれません。そこで、次の章ではVPCフローログの基本的な見方と、ログを確認する際に注目すべきポイントについて解説していきます。

VPCフローログの見方

今回は、ログレコード形式にAWSのデフォルト形式を選択しているため、出力されるログは以下のような構造になります。

ログ形式（デフォルト）

  
${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status}

それでは、各項目が何を表しているのかを実際に抽出されたログデータと照らし合わせながら見てみましょう。

各項目の意味

項目名	項目が示す内容	例の値
version	VPCフローログのバージョン	2
account-id	AWSアカウントのID	123456789012
interface-id	ネットワークインターフェイスのID	eni-00a0a00a000000a00
srcaddr	送信元IPアドレス	xx.xx.xx.xx
dstaddr	宛先IPアドレス	xx.xx.xx.xx
srcport	送信元ポート	51498
dstport	宛先ポート	443
protocol	プロトコルの番号	6
packets	パケット数	3
bytes	バイト数	187
start	開始時刻(unixtime)	1746057586
end	終了時刻(unixtime)	1746057611
action	通信が許可されたか拒否されたか	ACCEPT or REJECT
log-status	ログが記録された理由や状態	OK or NODATA or SKIPDATA

このように、項目ごとの意味と実際の値を照らし合わせることで、ログの内容がなんとなく理解できるようになってきたかと思います。
次に注目したいのは、通信が「許可（ACCEPT）」されたのか「拒否（REJECT）」されたのかという情報です。 VPCフローログでは、どこからどこへ向かう通信が許可・拒否されたのかが記録されていますが、この情報を正しく読み解くためには、ログがどこで、どのように記録されているのかを理解しておくことが重要です。
VPCフローログは、VPC内のネットワークインターフェースを通過する通信を対象に、その通信がセキュリティグループやネットワークACLの設定によって許可または拒否されたかを記録しています。
ただし注意点として、フローログには「どの設定が通信を拒否したのか（セキュリティグループやなのかネットワークACLなのか）」までは記録されません。そのため、REJECTのログが出力された場合には、セキュリティグループによる拒否なのか、ネットワークACLによるものなのかを読み解く必要があります。

REJECTの原因がセキュリティグループかネットワークACLかを判別するポイント

セキュリティグループはステートフル

セキュリティグループはステートフル（状態保持）な仕組みため、送信方向の通信が許可されていれば、その応答通信は自動的に許可されます。そのため、応答方向でREJECTが記録されることは基本的にありません。
以下はセキュリティグループで許可された際の通信のログ例です。

  
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-00a0a00a000000a00 送信元のIP 送信先のIP 443 44166 6 8 4171 1746057703 1746057726 ACCEPT OK
2 123456789012 eni-00a0a00a000000a00 送信先のIP 送信元のIP 44166 443 6 8 1051 1746057703 1746057726 ACCEPT OK

ネットワークACLはステートレス

一方、ネットワークACLはステートレスであるため、通信の送信方向・応答方向の両方に対して許可ルールを設定する必要があります。そのため、送信方向は許可されていても、応答方向で拒否されることがよくあります。したがって応答方向でREJECTが記録された場合は、ネットワークACLによって通信が拒否された可能性が高いと考えられます。

  
version account-id interface-id srcaddr dstaddr srcport dstport protocol packets bytes start end action log-status
2 123456789012 eni-00a0a00a000000a00 送信元のIP 送信先のIP 49816 443 6 2 104 1746057681 1746057701 ACCEPT OK
2 123456789012 eni-00a0a00a000000a00 送信先のIP 送信元のIP 443 49816 6 2 128 1746057681 1746057701 REJECT OK

このように、VPCフローログからREJECTの原因を読み解くためには、セキュリティグループとネットワークACLの動作の違いを正しく理解し、通信の方向（送信か応答か）に注目することが重要です。

まとめ

VPCフローログの有効化は、マネジメントコンソールから数クリックで完了します。S3バケットポリシーの設定もAWSが自動で行ってくれるため、初学者の方でも安心して導入できます。
ネットワークの可視化や分析の第一歩として、VPCフローログは非常に有効な手段です。セキュリティ対策やトラブルシューティングへの備えとして、ぜひ一度導入を検討してみてください！