I Tried Out the New Metadata Fields in VPC Flow Logs (Next Hop and EC2 Tags)

Introduction

On June 10, 2026, new metadata fields were added to VPC Flow Logs.

https://aws.amazon.com/jp/about-aws/whats-new/2026/06/amazon-flow-logs-metadata/

The conventional VPC Flow Logs (default format v2) record 14 fields, including source/destination IP, port, protocol, and byte count. However, to find out "which resource is the next hop of the traffic" or "which AZ the other side is in," you had to investigate separately using describe-network-interfaces or similar.

With the newly added fields, for supported traffic you can check the next hop's ENI, subnet, AZ, and VPC in a single flow log record. The same applies to the tag values of EC2 instances/ENIs that you specify in advance.

Fields verified in this article

In this article, in addition to the conventional 14 fields, we verify the newly added next-hop-related fields, interface-type, and the EC2 tag fields. First, the fields used to check the next hop are as follows.

The EC2 tag fields (instance-tag, interface-tag) are described later.

In the new format, the value of the version field is 11 (previously 2).

https://docs.aws.amazon.com/vpc/latest/userguide/flow-log-records.html

Steps to enable flow logs

For a VPC in the Tokyo region (ap-northeast-1) where an ALB + ECS Fargate setup is running, I added only the flow logs. To use the new fields, you create a new flow log with a custom format.

Create an IAM role

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": "*"
    }]
  }'

Create a log group

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

Create a flow log (with next-hop fields)

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

Specify the next-hop fields such as ${next-hop-interface-id} in --log-format.

After creation, confirm with describe-flow-logs that FlowLogStatus is ACTIVE. Logs start arriving within 1–2 minutes.

Verification results

Tracing the next hop from ALB → ECS task

Let's look at the record of traffic from the ALB's ENI (eni-0bcf1b5ac970xxxx) to the ECS task.

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 -

In the conventional format, the same kind of traffic is recorded with only up to 14 fields, as follows.

2 7846937xxxxx eni-0bcf1b5ac970xxxx 192.168.24.xxx 192.168.25.xxx 60628 3000 6 5 407 1681242505 1681242506 ACCEPT OK

Previously the record ended at 14 fields, so you couldn't tell which ENI was beyond this traffic. In the new format, next-hop information is appended at the end.

Visualizing cross-AZ traffic

Let's look at the records of the ECS task's ENI (eni-0ef3b34b6ff0xxxx). For this ENI, the next-hop-* fields recorded the information of the ALB ENI on the other side of the traffic.

Traffic from the ALB ENI in the same AZ (apne1-az1):

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 -

Traffic from the ALB ENI in a different AZ (apne1-az4):

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 -

The value of next-hop-az-id differs between apne1-az1 and apne1-az4. Since we know that the recording ECS task ENI is in apne1-az1 this time, records where next-hop-az-id is apne1-az4 can be identified as cross-AZ traffic.

Because data transfer between AZs incurs charges, using next-hop-az-id lets you narrow down the records that correspond to cross-AZ traffic. If you decide on the target ENIs and traffic direction and aggregate bytes, it becomes easier to visualize the breakdown of cross-AZ transfer volume. Previously you had to reverse-look up each ENI's subnet with describe-network-interfaces to identify the AZ, but that effort is no longer needed.

External traffic via a NAT Gateway

Record of outbound traffic from an EC2 instance (placed in a private subnet) to the outside:

This record uses a format in which the tag fields described later are also enabled. After interface-type, instance-tag and interface-tag follow, and then the next-hop fields are recorded.

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

Because next-hop-interface-type is regional_nat_gateway, you can tell from the flow log alone that this traffic goes through a NAT Gateway.

Since this verification environment uses a regional NAT Gateway, the value is regional_nat_gateway. If you use a conventional per-AZ NAT Gateway, it will be nat_gateway. A regional NAT Gateway automatically fails over during an AZ failure, but under normal conditions it is processed in a single AZ. In next-hop-az-id, the AZ that actually handled the processing (in this example, apne1-az4) was recorded.

On the other hand, for IPv6 traffic from the same ENI, the next hop is all -.

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 - - - - -

This IPv6 traffic does not go through the NAT Gateway, so next-hop-interface-type does not become regional_nat_gateway. In this example, all next-hop-related fields were -. In this example, IPv4 traffic showed regional_nat_gateway and IPv6 traffic showed -, so whether traffic went via a NAT Gateway could be distinguished in the flow logs.

Checking the EC2 tag fields

I assigned a Name tag to each of the EC2 instance and the ENI, and created a flow log that records instance-tag and interface-tag with TagFieldSpecifications. This is the same record as in the previous NAT Gateway section, but this time we focus on the tag fields.

Tag values are recorded with UTF-8 percent-encoding (- → %2D).

To enable the tag fields, specify the target resource types and tag keys with --tag-field-specifications when creating the flow log.

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

To use the EC2 tag fields, you need the permissions required for tag lookup. In this verification, I added ec2:DescribeTags to the IAM role used for flow log delivery. Also, if the service-linked role has not been created yet, the IAM principal that creates the flow log may need iam:CreateServiceLinkedRole.

Notes

• The format of an existing flow log cannot be changed. To use the new fields, you need to create a new flow log.
• The key that specifies a tag in the --tag-field-specifications parameter is Key inside the Tags array (note that the parameter name is Tags, not TagKeys).
• The CloudFormation AWS::EC2::FlowLog resource does not currently implement the TagFieldSpecifications property. You need to create it via the CLI or API.

Summary

With the new metadata fields of VPC Flow Logs, next-hop information that previously had to be checked separately via APIs, as well as tag values specified in advance, can now be checked in a single flow log record. In particular, being able to more easily confirm the other side's AZ in cross-AZ traffic and determine whether traffic goes through a NAT Gateway from the logs is a practical improvement. Because the format of an existing flow log cannot be changed, when using the new fields you create a new flow log with a custom format.