A security team is auditing two applications deployed across two EKS clusters that use the Amazon VPC CNI. The clusters are in different subnets of the same VPC and use Cluster Autoscaler. The team needs to determine which pod IPs communicate with which services across the VPC, but wants to limit the number of flow logs and only collect traffic for the two applications. Which approach meets the requirements with the LEAST operational overhead?

The correct approach is to create VPC flow logs in a custom format, setting the application subnets as resources, and including pkt-srcaddr and pkt-dstaddr. This is because the Amazon VPC CNI assigns pod IPs directly from the subnet CIDR. By logging at the subnet level, you capture all traffic for pods within those specific subnets. Using pkt-srcaddr and pkt-dstaddr directly exposes the pod IP addresses, which is crucial for identifying which pod IPs are communicating. Logging at the subnet level also minimizes operational overhead by avoiding the need to manage individual EKS node IPs, which can change with Cluster Autoscaler. Incorrect options: Logging EKS nodes as resources or filtering by EKS nodes would capture traffic at the node's ENI level, not the individual pod IPs. The default format does not include pkt-srcaddr and pkt-dstaddr. Filtering by EKS nodes still doesn't directly expose pod IPs without the pkt-srcaddr and pkt-dstaddr fields.