AWS VPC Flow Logs Explained: How to See the Truth About Network Traffic in Your VPC

What are AWS VPC Flow Logs?

AWS VPC Flow Logs are a feature that captures information about IP traffic going to and from network interfaces in your VPC. They are not packet captures. Instead, they record traffic metadata such as source and destination IP, source and destination port, protocol, packet count, byte count, and whether the traffic was accepted or rejected.

This makes Flow Logs especially useful for understanding traffic patterns and troubleshooting connectivity issues without needing full packet-level tools.

Why VPC Flow Logs matter in real AWS environments

Network issues often feel ambiguous. An application says “connection timed out,” but that message alone does not tell you whether the problem is DNS, routing, a security group, a network ACL, a missing route, or an unreachable target.

Flow Logs matter because they help narrow down that uncertainty. They provide evidence about whether traffic reached a network interface, whether it was accepted or rejected, and what addressing and port context was involved.

They are also useful beyond troubleshooting. Security teams use them for traffic analysis, incident review, and visibility into unexpected communication patterns.

How VPC Flow Logs work

Flow Logs can be created at different scopes, including the VPC level, subnet level, or individual network interface level. AWS collects the flow log data outside the actual network traffic path, which means enabling them does not affect throughput or latency.

Once created, the records are delivered to a destination you choose: CloudWatch Logs, Amazon S3, or Amazon Data Firehose.

Understanding flow log records

Flow log records are line-based records containing traffic metadata fields. AWS supports both default and custom formats, and the records can include fields such as source address, destination address, source port, destination port, protocol, packets, bytes, start time, end time, action, and log status.

Example: accepted SSH traffic

Example: rejected RDP traffic

What the key fields mean

ACCEPT vs REJECT traffic: one of the most useful parts of Flow Logs

The `action` field is often the first thing engineers look at. It tells you whether the traffic was accepted or rejected. This becomes especially useful when you are validating whether a security control is blocking a connection.

However, interpretation still matters. ACCEPT does not necessarily mean the application itself succeeded. It means the traffic was allowed at the network level. Similarly, REJECT indicates the network dropped the flow, but you still need to understand whether that was caused by a security group, a network ACL, or another control path.

Using Flow Logs to understand security groups vs network ACLs

One of the strongest troubleshooting uses of Flow Logs is identifying how stateful and stateless controls behave differently. AWS explicitly documents examples showing this with security groups and network ACLs.

Security groups are stateful. If inbound traffic is allowed, the return traffic is also allowed automatically. Network ACLs are stateless. That means response traffic must be explicitly allowed too.

This is where Flow Logs become extremely practical. You can see one ACCEPT for the incoming request and one REJECT for the response path when a network ACL is too restrictive.

CloudWatch Logs, S3, and delivery choices

AWS lets you publish VPC Flow Logs to three destinations: CloudWatch Logs, Amazon S3, and Amazon Data Firehose. Each destination supports a different operational pattern.

Why CloudWatch Logs is often the first choice

For day-to-day engineering troubleshooting, CloudWatch Logs is usually the most convenient destination because teams can search and inspect recent records quickly. For deeper analytics and retention strategies, S3 often becomes the better longer-term location.

Real-world use cases for VPC Flow Logs

1) Troubleshooting SSH or RDP failures

If remote access is failing, Flow Logs can help answer whether traffic to the ENI was rejected, accepted, or never visible at all.

2) Diagnosing restrictive security groups

AWS explicitly lists this as a Flow Logs use case. The records help confirm whether traffic is being blocked more aggressively than intended.

3) Finding direction of traffic

Flow Logs help identify not only whether traffic exists, but whether it is moving into or out of a network interface as expected.

4) Security investigations

When teams need to review suspicious traffic patterns or validate whether unexpected IP communication occurred, Flow Logs provide valuable metadata.

5) Proving network assumptions during incidents

During outages, teams often debate whether the network is involved. Flow Logs help settle that quickly by showing whether the network allowed or blocked the flow.

Common VPC Flow Logs mistakes

• Assuming Flow Logs capture packet payload instead of metadata only
• Looking at ACCEPT and concluding the application is healthy without checking deeper layers
• Ignoring REJECT records during connectivity debugging
• Forgetting that stateful and stateless controls behave differently
• Publishing logs without planning how to search or analyze them later
• Collecting logs broadly but never using them in an operational workflow

Best practices for using VPC Flow Logs well

• Enable Flow Logs for important traffic boundaries and critical workloads
• Use CloudWatch Logs for operational troubleshooting and fast searchability
• Use S3 or downstream pipelines when retention or large-scale analysis matters
• Teach teams how to interpret ACCEPT, REJECT, NODATA, and SKIPDATA properly
• Use Flow Logs alongside security groups, NACL design, and route table validation
• Correlate Flow Logs with CloudWatch metrics, application logs, and incident timelines
• Focus on real operational questions instead of collecting traffic data without purpose