VPC Flow Logsの新メタデータフィールド（ネクストホップ・EC2タグ）を試してみた
はじめに
2026年6月10日、VPC Flow Logsに新たなメタデータフィールドが追加されました。
従来のVPC Flow Logs（デフォルトフォーマットv2）は送信元/宛先IP・ポート・プロトコル・バイト数など14フィールドを記録します。しかし「通信のネクストホップに該当するリソースは何か」「相手側のAZはどこか」を知るにはdescribe-network-interfaces等で別途調べる必要がありました。
今回追加されたフィールドにより、対応する通信ではフローログの1レコードでネクストホップのENI・サブネット・AZ・VPCを確認できます。事前に指定したEC2インスタンス/ENIのタグ値も同様です。
本記事で検証するフィールド
本記事では、従来の14フィールドに加えて追加されたネクストホップ関連フィールドとinterface-type、およびEC2タグフィールドを検証します。まず、ネクストホップ確認に使ったフィールドは以下です。
| # | フィールド | 用途 |
|---|---|---|
| 15 | interface-type |
記録元ENIの種別 |
| 16 | next-hop-interface-id |
ネクストホップのENI ID |
| 17 | next-hop-subnet-id |
ネクストホップのサブネット |
| 18 | next-hop-az-id |
ネクストホップのAZ |
| 19 | next-hop-vpc-id |
ネクストホップのVPC |
| 20 | next-hop-interface-type |
ネクストホップの種別（例：regional_nat_gateway） |
EC2タグフィールド（instance-tag、interface-tag）については後述します。
新フォーマットでは version フィールドの値が 11 になります（従来は 2）。
フローログの有効化手順
東京リージョン（ap-northeast-1）のALB + ECS Fargate構成が稼働中のVPCに対し、フローログのみを追加しました。新フィールドを使うにはカスタムフォーマットで新規フローログを作成します。
IAM ロール作成
aws iam create-role \
--role-name agentcore-webshell-flow-logs-role \
--assume-role-policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {"Service": "vpc-flow-logs.amazonaws.com"},
"Action": "sts:AssumeRole"
}]
}'
aws iam put-role-policy \
--role-name agentcore-webshell-flow-logs-role \
--policy-name FlowLogsPolicy \
--policy-document '{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents",
"logs:DescribeLogGroups",
"logs:DescribeLogStreams"
],
"Resource": "*"
}]
}'
ロググループ作成
aws logs create-log-group \
--log-group-name /vpc/agentcore-webshell-flow-logs \
--region ap-northeast-1
aws logs put-retention-policy \
--log-group-name /vpc/agentcore-webshell-flow-logs \
--retention-in-days 7 \
--region ap-northeast-1
フローログ作成（ネクストホップフィールド付き）
aws ec2 create-flow-logs \
--resource-ids vpc-0bb0ec1dcd48xxxx \
--resource-type VPC \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name /vpc/agentcore-webshell-flow-logs \
--deliver-logs-permission-arn arn:aws:iam::7846937xxxxx:role/agentcore-webshell-flow-logs-role \
--log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${interface-type} ${next-hop-interface-id} ${next-hop-subnet-id} ${next-hop-az-id} ${next-hop-vpc-id} ${next-hop-interface-type}' \
--max-aggregation-interval 60 \
--region ap-northeast-1
--log-format で ${next-hop-interface-id} などのネクストホップフィールドを指定します。
作成後、describe-flow-logs で FlowLogStatus が ACTIVE になっていることを確認します。1〜2分でログが到着し始めます。
検証結果
ALB → ECS タスクのネクストホップ追跡
ALBのENI（eni-0bcf1b5ac970xxxx）からECSタスクへの通信レコードを確認します。
11 7846937xxxxx eni-0bcf1b5ac970xxxx 192.168.24.xxx 192.168.25.xxx 60628 3000 6 5 407 1781242505 1781242506 ACCEPT OK - eni-0ef3b34b6ff0xxxx subnet-0034e5d410bbxxxx apne1-az1 vpc-0bb0ec1dcd48xxxx -
従来フォーマットでは、同種の通信は以下のように14フィールドまでで記録されます。
2 7846937xxxxx eni-0bcf1b5ac970xxxx 192.168.24.xxx 192.168.25.xxx 60628 3000 6 5 407 1681242505 1681242506 ACCEPT OK
従来は14フィールドで終わっており、この通信の先にどのENIがあるか分かりませんでした。新フォーマットでは末尾にネクストホップの情報が追加されています。
| フィールド | 値 | 意味 |
|---|---|---|
next-hop-interface-id |
eni-0ef3b34b6ff0xxxx |
ECS タスクの ENI |
next-hop-subnet-id |
subnet-0034e5d410bbxxxx |
ECS タスクが所属するサブネット |
next-hop-az-id |
apne1-az1 |
ECS タスクの AZ |
next-hop-vpc-id |
vpc-0bb0ec1dcd48xxxx |
同一 VPC 内通信 |
next-hop-interface-type |
- |
この例ではNAT Gateway等の中継デバイス種別は記録されていない |
クロスAZ通信の可視化
ECSタスクのENI（eni-0ef3b34b6ff0xxxx）のレコードを確認します。このENIでは、next-hop-*フィールドに通信相手のALB ENI情報が記録されていました。
同一AZ（apne1-az1）のALB ENIからの通信：
11 7846937xxxxx eni-0ef3b34b6ff0xxxx 192.168.24.xxx 192.168.25.xxx 39708 3000 6 5 407 1781242688 1781242708 ACCEPT OK - eni-0bcf1b5ac970xxxx subnet-0034e5d410bbxxxx apne1-az1 vpc-0bb0ec1dcd48xxxx -
別AZ（apne1-az4）のALB ENIからの通信：
11 7846937xxxxx eni-0ef3b34b6ff0xxxx 192.168.12.xxx 192.168.25.xxx 63634 3000 6 5 407 1781242688 1781242708 ACCEPT OK - eni-0a5ad0e49676xxxx subnet-034e9621c47axxxx apne1-az4 vpc-0bb0ec1dcd48xxxx -
next-hop-az-id の値が apne1-az1 と apne1-az4 で異なります。今回は記録元のECSタスクENIが apne1-az1 にあることが分かっているため、next-hop-az-id が apne1-az4 のレコードをクロスAZ通信として識別できます。
AZ間のデータ転送には料金が発生するため、next-hop-az-id を使うことでクロスAZ通信に該当するレコードを絞り込めます。集計対象のENIや通信方向を決めてbytesを集計すれば、クロスAZ転送量の内訳を可視化しやすくなります。従来は各ENIのサブネットをdescribe-network-interfacesで逆引きしてAZを特定する必要がありましたが、その手間がなくなります。
NAT Gateway 経由の外部通信
EC2インスタンス（プライベートサブネット配置）から外部への送信レコード：
このレコードは後述のタグフィールドも有効化したフォーマットです。interface-typeの後にinstance-tag、interface-tagが続き、その後にネクストホップフィールドが記録されます。
11 7846937xxxxx eni-0ea6b0349fcaxxxx 192.168.2.xxx 52.195.198.xxx 54596 443 6 15 4564 1781243707 1781243723 ACCEPT OK - flowlog%2Dtest%2Dinstance flowlog%2Dtest%2Deni - - apne1-az4 vpc-0bb0ec1dcd48xxxx regional_nat_gateway
| フィールド | 値 | 意味 |
|---|---|---|
next-hop-interface-id |
- |
このレコードではNAT GatewayのENI IDは記録されていない |
next-hop-subnet-id |
- |
このレコードではサブネットIDは記録されていない |
next-hop-az-id |
apne1-az4 |
NAT Gateway の AZ |
next-hop-vpc-id |
vpc-0bb0ec1dcd48xxxx |
NAT Gateway が所属する VPC |
next-hop-interface-type |
regional_nat_gateway |
NAT Gateway 経由であることを示す |
next-hop-interface-type が regional_nat_gateway になっているため、この通信がNAT Gatewayを経由していることがフローログだけで判別できます。
今回の検証環境ではリージョナルNAT Gatewayを使用しているため、値がregional_nat_gatewayです。従来のAZ単位のNAT Gatewayを使用している場合はnat_gatewayになります。リージョナルNAT GatewayはAZ障害時に自動フェイルオーバーしますが、通常時は単一AZで処理されます。next-hop-az-idには実際に処理を行ったAZ（この例ではapne1-az4）が記録されていました。
一方、同じENIのIPv6通信はネクストホップが全て - です。
11 7846937xxxxx eni-0ea6b0349fcaxxxx 2406:da14:xxxx:0:xxxx:xxxx:xxxx:xxxx 2406:da60:xxxx:20:0:0:xxx:xxxx 58422 443 6 147 11501 1781243707 1781243723 ACCEPT OK - flowlog%2Dtest%2Dinstance flowlog%2Dtest%2Deni - - - - -
このIPv6通信はNAT Gateway経由ではないため、next-hop-interface-typeはregional_nat_gatewayになりません。この例ではネクストホップ関連フィールドが全て-でした。この例では、IPv4通信はregional_nat_gateway、IPv6通信は-となっており、NAT Gateway経由の有無をフローログ上で区別できました。
EC2 タグフィールドの確認
EC2インスタンスとENIにそれぞれNameタグを付与し、TagFieldSpecificationsでinstance-tagとinterface-tagを記録するフローログを作成しました。先ほどのNAT Gatewayセクションと同じレコードですが、今度はタグフィールドに注目します。
| フィールド | 値 | デコード後 |
|---|---|---|
instance-tag |
flowlog%2Dtest%2Dinstance |
flowlog-test-instance |
interface-tag |
flowlog%2Dtest%2Deni |
flowlog-test-eni |
タグ値はUTF-8パーセントエンコードで記録されます（- → %2D）。
タグフィールドを有効化するには、フローログ作成時に --tag-field-specifications で対象リソースタイプとタグキーを指定します。
aws ec2 create-flow-logs \
--resource-ids vpc-0bb0ec1dcd48xxxx \
--resource-type VPC \
--traffic-type ALL \
--log-destination-type cloud-watch-logs \
--log-group-name /vpc/agentcore-webshell-flow-logs \
--deliver-logs-permission-arn arn:aws:iam::7846937xxxxx:role/agentcore-webshell-flow-logs-role \
--log-format '${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${protocol} ${packets} ${bytes} ${start} ${end} ${action} ${log-status} ${interface-type} ${instance-tag} ${interface-tag} ${next-hop-interface-id} ${next-hop-subnet-id} ${next-hop-az-id} ${next-hop-vpc-id} ${next-hop-interface-type}' \
--tag-field-specifications 'ResourceType=instance,Tags=[{Key=Name}]' 'ResourceType=network-interface,Tags=[{Key=Name}]' \
--max-aggregation-interval 60 \
--region ap-northeast-1
EC2タグフィールドを使うには、タグ参照に必要な権限が必要です。今回の検証では、フローログ配信用IAMロールにec2:DescribeTagsを追加しました。また、サービスリンクロールが未作成の場合は、フローログ作成を実行するIAMプリンシパルにiam:CreateServiceLinkedRoleが必要になる場合があります。
注意事項
- 既存フローログのフォーマットは変更できません。新フィールドを使うには新規フローログの作成が必要です。
--tag-field-specificationsのパラメータでタグを指定するキーはTags配列内のKeyです（パラメータ名がTagKeysではなくTagsであることに注意）。- CloudFormationの
AWS::EC2::FlowLogリソースには現時点でTagFieldSpecificationsプロパティが未実装です。CLIまたはAPIで作成する必要があります。
まとめ
VPC Flow Logsの新メタデータフィールドにより、従来は別途APIで確認していたネクストホップ情報や、事前に指定したタグ値をフローログの1レコード上で確認できるようになりました。特に、クロスAZ通信の相手側AZの確認や、NAT Gateway経由かどうかの判別がログ上で行いやすくなる点は実用的な改善です。既存フローログのフォーマットは変更できないため、新フィールドを使う場合はカスタムフォーマットで新規フローログを作成します。
