4.1.2. VPC Flow Logs for IP Traffic Monitoring

VPC Flow Logs capture detailed IP traffic information for network interfaces in your Amazon VPC, providing essential visibility for network monitoring, troubleshooting, and security analysis.

Scenario: You need to troubleshoot intermittent network connectivity issues between your application's EC2 instances and its database. You also need to monitor for suspicious outbound network activity (e.g., to unusual IP addresses) for security purposes.

VPC Flow Logs are a powerful feature that enables network specialists to monitor the IP traffic going to and from network interfaces in their Amazon VPC. They are crucial for network diagnostics, security incident response, and compliance auditing.

Key Features of VPC Flow Logs:

• Traffic Capture: Records information about IP traffic, including source/destination IP address, port, protocol, packets, bytes, and action (ACCEPT or REJECT). This provides a detailed record of every network "flow."
• Scope: Can be enabled for an entire VPC, a subnet, or a specific Elastic Network Interface (ENI) (attached to EC2 instances, load balancers, NAT Gateways, etc.).
• Destinations: Flow log records can be published to Amazon CloudWatch Logs or Amazon S3 for storage and analysis, or streamed to Amazon Data Firehose for near-real-time delivery to a SIEM, data lake or custom consumer.
• Use Cases:
  • Network Diagnostics: Debugging connectivity issues between EC2 instances or to external networks.
  • Security Analysis: Identifying unusual traffic patterns, unauthorized access attempts, data exfiltration attempts, or potential DDoS attacks.
  • Compliance Auditing: Providing an audit trail of network traffic for regulatory compliance.
  • Performance Optimization: Identifying high-traffic flows or unexpected data transfer.
• Format: Log records are plain text and can be easily parsed.
• Default vs. Custom Format: The default format holds only the version 2 fields (account, ENI, 5-tuple, packets, bytes, start/end, action, log-status). Fields such as vpc-id, subnet-id, instance-id, tcp-flags, pkt-srcaddr/pkt-dstaddr (the original addresses behind a NAT gateway or other intermediate hop), flow-direction and traffic-path appear only if you define a custom format that lists them. There is no "verbose" switch.
• Reading action and tcp-flags: REJECT means the flow was not allowed by a security group or a network ACL — NACL denies are logged too, and the record does not say which control. ACCEPT at the destination ENI plus a client-side "connection refused" means the network allowed the packet and nothing is listening on the port. With tcp-flags, a SYN (2) that never gets a SYN-ACK (18) back means the reply is being dropped or never sent.
• Delivery and Permissions: CloudWatch Logs delivery uses an IAM role the flow log service assumes; S3 delivery — including cross-account to a central log-archive bucket — is authorized by the bucket policy, which must allow the delivery.logs.amazonaws.com service principal to write.
• Querying at Scale: For flow logs in S3, use Amazon Athena: define a database and a table in the AWS Glue Data Catalog that describe the log schema and S3 location, then run SQL. Pair it with S3 lifecycle rules (e.g., transition to Glacier) for multi-year retention. For logs in CloudWatch Logs, use Logs Insights for interactive queries; metric filters turn log patterns into metrics, and subscription filters stream events onward.
• Transit Gateway Flow Logs: A separate flow log created on the transit gateway itself. Fields include tgw-attachment-id (the attachment the record is for) and tgw-pair-attachment-id (the other attachment of the flow, ingress or egress per flow-direction), plus tgw-src-vpc-id/tgw-dst-vpc-id and the packets-lost-no-route, packets-lost-blackhole and packets-lost-mtu-exceeded counters.
• VPC Flow Logs vs. VPC Traffic Mirroring: Flow logs record metadata, never payload. VPC Traffic Mirroring copies the actual packets from a source ENI (Nitro-based instances) for deep packet inspection, IDS and forensics:
  • A traffic mirror session ties together the source ENI, a mirror target and a mirror filter (accept/reject rules by direction, protocol, CIDR and port). A target and filter with no session mirror nothing.
  • Supported targets are a network interface, a Network Load Balancer (needs a UDP listener on port 4789; recommended for a fleet of appliances) or a Gateway Load Balancer endpoint — not an S3 bucket or a DNS name. The target can be in another VPC or account.
  • Mirrored packets are VXLAN-encapsulated (UDP 4789): the outer header runs from the source ENI to the target, the original packet sits inside, and TLS payloads stay encrypted. The target's security group must allow UDP 4789 from the source, and the source subnet needs a route to the target. Mirrored outbound traffic is not subject to the source's outbound security group rules; inbound traffic already dropped by the source's inbound SG or NACL is not mirrored.

Practical Implementation: Querying VPC Flow Logs in CloudWatch Logs Insights

# Example query to find rejected traffic between two IPs
fields @timestamp, @message
| filter action = "REJECT"
| filter srcAddr = "10.0.1.10" and dstAddr = "10.0.2.20"
| sort @timestamp desc
| limit 20

# Example query to find top talkers (most bytes transferred)
fields @timestamp, @message
| parse @message "* * * * * * * * * * * * * * * *" as accountId, interfaceId, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, start, end, action, logstatus, vpcId, subnetId, instanceId
| stats sum(bytes) as totalBytes by srcaddr, dstaddr
| sort totalBytes desc
| limit 10

⚠️ Common Pitfall: Not enabling Flow Logs at the correct scope (VPC, subnet, or ENI) or not sending them to an accessible destination for analysis. Without proper configuration, you'll lack the necessary visibility.

Key Trade-Offs:

• Granularity of Logs vs. Cost: Capturing all traffic (ALL) provides the most detailed information but incurs higher costs for log ingestion and storage compared to capturing only rejected traffic (REJECT).

Reflection Question: How do VPC Flow Logs, by capturing detailed IP traffic information for network interfaces and publishing it to CloudWatch Logs or S3, provide essential visibility for network monitoring, enabling you to troubleshoot connectivity issues and analyze traffic for security threats?