VPC Flow Logs – Everything you need to know
Why VPC Flow Log Configuration Matters
In our investigative experience, we have observed that the default fields in VPC Flow Logs often provide limited visibility into network connections. This constraint hampers deep-dive investigations during incident response or threat hunting.
That’s why understanding and optimizing your VPC Flow Log configuration isn’t just a nice-to-have; it’s foundational to effective threat detection, troubleshooting, and cost control.
Therefore, we strongly recommend implementing proper logging configurations in VPC Flow Logs tailored to your environment and use cases.
In this document, we analyze the fields available in AWS VPC Flow Logs to evaluate their role in security, observability, and operational use. Each parameter was reviewed to understand what insight it provides, how it supports detection and troubleshooting, and whether it is essential in most environments.
By clearly identifying which fields deliver the most value, we help you build a smarter, more efficient logging strategy. We categorized fields as essential, recommended, or optional helping guide decisions on what to retain and what can be safely excluded to reduce logging volume and cost.
We previously published a blog covering common use cases of VPC Flow Logs and out-of-the-box detections available in Coralogix.
The blog can be accessed here .
Common Gaps in VPC Flow Log Configurations :
- Overlogging: Collecting all fields by default leads to high cost with limited added value.
- Missing NAT Context: Omitting pkt-srcaddr / pkt-dstaddr in NAT or EKS environments hides true endpoints.
- Dropped Visibility Fields: Fields like action, flow-direction, and traffic-path are often skipped, reducing clarity on traffic intent and exposure.
- Container Blindness: Important ECS-specific fields are left out, making it hard to trace service-level activity.
These gaps show why default setups are rarely enough. Tailored configurations are the most effective way to ensure both visibility and efficiency.
The Role of VPC Flow Log Fields
VPC Flow Logs offer dozens of fields that can be included in each log record, but not all are created equal. Some fields are crucial for identifying suspicious behavior, tracking traffic patterns, or troubleshooting issues, while others are more situational or redundant.
To help you strike the right balance between visibility and efficiency, we’ve grouped fields based on their value across security, observability, and cost.
High-Value Fields to Retain
These fields are considered essential for any VPC Flow Log configuration and should be consistently enabled. They provide visibility into network activity and are critical for security detection, forensics, and traffic analysis.
| Field | Description | Security Use Case |
| version | Log format version used | Cannot be disabled |
| account-id | AWS account owning the interface | Attribute traffic to specific accounts in multi-account environments; support tenant-aware detection. |
| interface-id | Network interface ID | Helps trace traffic to ENIs (e.g., NAT gateways, load balancers); useful in identifying misconfigured routes or abused endpoints. |
| instance-id | Linked instance ID | Drop if instance attribution isn’t needed |
| srcaddr | Source IP of traffic | Pinpoints traffic origin; enables geo-IP lookups, anomaly detection (e.g., access from unusual countries), and IP-based threat intel matching. |
| dstaddr | Destination IP of traffic | Identifies which systems or services were targeted; critical in tracking lateral movement or identifying protected asset exposure. |
| srcport | Source port used | Detects unusual port usage or port scans from external sources; highlights ephemeral port behaviors often seen in malware C2. |
| dstport | Destination port used | Identifies attempts to reach sensitive services (e.g., SSH, RDP, databases); supports port-based threat models. |
| protocol | Protocol number (e.g. TCP, UDP) | Flags suspicious or non-standard protocol usage (e.g., ICMP abuse, stealthy exfiltration via UDP). |
| region | AWS Region of resource | Drop in single-region setups |
| tcp-flags | TCP handshake/termination flags | Drop unless deep behavioral detection needed |
| pkt-srcaddr | Original (pre-NAT) source IP | Drop if not using NAT/EKS |
| pkt-dstaddr | Original (pre-NAT) destination IP | Same as above |
| action | ACCEPT or REJECT decision | Identifies blocked attacks vs. successful connections; useful for tuning firewall rules and alert triage. |
| flow-direction | Ingress or Egress indicator | Helps distinguish between inbound scans and outbound C2/beaconing; crucial for DLP and egress filtering. |
| traffic-path | Egress path from the VPC | Reveals whether traffic exited via internet, VPN, or peering; useful for identifying unapproved exposure routes. |
| ecs-cluster-arn | ARN of ECS cluster | Maps traffic to specific container clusters; supports container-aware security monitoring. |
| ecs-cluster-name | Name of ECS cluster | Human-readable cluster name for correlating flows in dashboards and alerts. |
| reject-reason | Why traffic was rejected (e.g. BPA) | Explains blocked attempts; particularly useful in enforcing AWS BPA (Block Public Access) policies. |
Lightweight Fields for Selective Use
These fields are not strictly required for baseline visibility and detection, and can be trimmed to reduce ingestion volume and cost. However, they offer additional insights for specific use cases such as network performance tuning, environment tagging, or deep forensic analysis. If you’re focused primarily on cost optimization, these are good candidates to drop – but each comes with a tradeoff depending on your monitoring goals.
| Field | Description | Tradeoff |
| packets | Packets transferred | Drop if performance tracking is unnecessary |
| start | Start time of the flow | Drop if timing isn’t critical |
| end | End time of the flow | Same as above |
| log-status | Log collection health indicator | Drop if not tracking ingestion gaps |
| vpc-id | ID of the associated VPC | Drop in single-VPC setups |
| subnet-id | ID of the associated subnet | Drop if not subnet-aware |
| type | Traffic type (IPv4/IPv6/EFA) | Drop if IP type can be inferred from addresses |
| az-id | Availability Zone ID | Drop if zone-level tracking not needed |
| sublocation-type | Edge location type (Outpost, etc) | Drop if not using wavelength/local zones |
| sublocation-id | ID of edge infrastructure zone | Same as above |
| pkt-src-aws-service | AWS service associated with source IP | Drop unless detailed AWS service tracking is needed |
| pkt-dst-aws-service | AWS service associated with destination IP | Same as above |
| ecs-container-instance-arn | ECS container instance (ARN) | Drop if Fargate-only or not using ECS |
| ecs-container-instance-id | ECS container instance ID | Same as above |
| ecs-container-id | Docker ID of first container | Drop unless deep ECS visibility needed |
| ecs-second-container-id | Docker ID of second container | Same as above |
| ecs-service-name | ECS service name | Drop if service-level mapping isn’t needed |
| ecs-task-definition-arn | ECS task definition ARN | Drop if not needed |
| ecs-task-arn | ARN of running ECS task | Drop unless container visibility required |
| ecs-task-id | ECS task ID | Drop in Fargate/basic ECS setups |
Customizing VPC Flow Log Record Format
There are two ways to define the log record format for AWS VPC Flow Logs:
- Default Format
This includes a fixed set of fields defined by AWS. It is easy to enable and provides baseline network visibility but offers no control over which fields are included. The version for default format is always set to 2. - Custom Format
This allows you to explicitly specify which fields to include in your flow logs. Custom format gives you fine-grained control over the log content, making it ideal for cost optimization, security-specific logging, or adapting logs to match your SIEM or analytics pipeline.
Step by Step Customization:
- Head over to the VPC Dashboard in the AWS Console.
- Select the VPC for which you want to enable flow logs.
- Click on the Flow Logs tab and choose Create flow log (or Edit if modifying an existing one).
- Configure all the required fields as per your requirement.
- Under Log record format, choose Custom from the dropdown.
- In the text box that appears, enter your desired field list (e.g., srcaddr dstaddr srcport dstport protocol bytes action).
- Click Create flow log to save and activate the configuration.
Conclusion
By customizing VPC Flow Logs, organizations can significantly improve network visibility, enhance security posture, and optimize logging costs. Moving beyond default configurations allows for precise control over data collection, ensuring that critical information for security detection, incident response, and operational analysis is retained, while extraneous data is excluded. This tailored approach is crucial for building a robust and efficient monitoring strategy within AWS environments.
Book a demo
Complete this form to speak with one of our sales representatives.