I tried out the new metadata fields (next hop, EC2 tags) in VPC Flow Logs

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/

Traditional VPC Flow Logs (default format v2) record 14 fields including source/destination IP, port, protocol, and byte count. However, to determine "what resource corresponds to the next hop of the communication" or "which AZ the other party is in," it was necessary to look it up separately using describe-network-interfaces and similar commands.

With the newly added fields, for supported communications, you can now check the next hop's ENI, subnet, AZ, and VPC from a single flow log record. The same applies to pre-specified EC2 instance/ENI tag values.

Fields Verified in This Article

In this article, we verify the next-hop-related fields added in addition to the traditional 14 fields, along with interface-type and EC2 tag fields. First, the fields used for next-hop verification are as follows.

EC2 tag fields (instance-tag, interface-tag) will be described later.

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

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

Flow Log Enablement Procedure

Flow logs were added to a VPC in the Tokyo region (ap-northeast-1) running an ALB + ECS Fargate configuration. To use the new fields, create a new flow log with a custom format.

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

Creating 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

Creating 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 next-hop fields such as ${next-hop-interface-id} in --log-format.

After creation, verify that FlowLogStatus shows ACTIVE using describe-flow-logs. Logs will start arriving within 1–2 minutes.

Verification Results

Tracking the Next Hop from ALB to ECS Task

Let's examine the communication record 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 traditional format, the same type of communication 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, making it impossible to determine which ENI was on the other end of this communication. In the new format, next-hop information is appended at the end.

Visualizing Cross-AZ Communication

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

Communication from an 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 -

Communication from an 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 values of next-hop-az-id differ between apne1-az1 and apne1-az4. In this verification, since we know the recording source ECS task ENI is in apne1-az1, records where next-hop-az-id is apne1-az4 can be identified as cross-AZ communication.

Since data transfer between AZs incurs charges, using next-hop-az-id allows you to narrow down records that correspond to cross-AZ communication. By choosing the target ENIs and traffic direction and then aggregating bytes, it becomes easier to visualize the breakdown of cross-AZ transfer volumes. Previously, it was necessary to reverse-look up the subnet of each ENI using describe-network-interfaces to identify the AZ, but that effort is now eliminated.

External Communication via NAT Gateway

Outbound record from an EC2 instance (placed in a private subnet) to an external destination:

This record uses a format that also has the tag fields described later. 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, it is possible to determine from the flow log alone that this communication goes through a NAT Gateway.

In this verification environment, a regional NAT Gateway is used, so the value is regional_nat_gateway. If using a traditional AZ-level NAT Gateway, the value will be nat_gateway. A regional NAT Gateway automatically fails over in the event of an AZ failure, but under normal conditions it is processed in a single AZ. The next-hop-az-id recorded the AZ that actually performed the processing (in this example, apne1-az4).

On the other hand, IPv6 communication from the same ENI has all next-hop fields set to -.

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 communication does not go through a 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 communication shows regional_nat_gateway while IPv6 communication shows -, making it possible to distinguish the presence or absence of NAT Gateway routing in the flow log.

Checking EC2 Tag Fields

A Name tag was assigned to each EC2 instance and ENI, and a flow log was created to record instance-tag and interface-tag via TagFieldSpecifications. This is the same record as in the NAT Gateway section above, but this time we focus on the tag fields.

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

To enable tag fields, specify the target resource type and tag key using --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 EC2 tag fields, the permissions required for tag lookups are necessary. In this verification, ec2:DescribeTags was added to the IAM role used for flow log delivery. Also, if the service-linked role has not yet been created, the IAM principal executing the flow log creation may need iam:CreateServiceLinkedRole.

Notes

• The format of existing flow logs cannot be changed. Creating a new flow log is required to use the new fields.
• The key specified for tags in the --tag-field-specifications parameter is Key inside the Tags array (note that the parameter name is Tags, not TagKeys).
• The AWS::EC2::FlowLog resource in CloudFormation does not currently implement the TagFieldSpecifications property. It must be created using the CLI or API.

Summary

With the new metadata fields in VPC Flow Logs, next-hop information that previously required separate API calls, as well as pre-specified tag values, can now be checked from a single flow log record. In particular, the ability to check the AZ of the other party in cross-AZ communications and to determine whether traffic goes through a NAT Gateway directly from logs are practical improvements. Since the format of existing flow logs cannot be changed, when using the new fields, create a new flow log with a custom format.