AWS Builder Center

AWS VPC Flow Logs: A Practical Guide to Understanding Network Traffic

"What is actually happening to the network traffic?" Security Groups and Network ACLs determine whether traffic is allowed, but understanding the traffic itself can be challenging.

Introduction

When troubleshooting network connectivity or investigating suspicious activity in AWS, one of the first questions is often:
"What is actually happening to the network traffic?"
Security Groups and Network ACLs determine whether traffic is allowed, but understanding the traffic itself can be challenging.
This is where VPC Flow Logs become useful.
VPC Flow Logs allow you to capture information about IP traffic going to and from network interfaces in your VPC. They can help with network troubleshooting, security investigations, traffic analysis, and monitoring.
In this article, we'll understand how VPC Flow Logs work and walk through a practical example.

What Are VPC Flow Logs?

VPC Flow Logs are records of network traffic flowing to and from network interfaces in your VPC.
They don't capture the actual contents of network packets. Instead, they provide metadata about the traffic, such as:
  • Source IP address
  • Destination IP address
  • Source port
  • Destination port
  • Protocol
  • Number of packets
  • Number of bytes
  • Start and end time
  • Whether the traffic was accepted or rejected
A simplified example looks like:
1
2
3
Source IP Destination IP Port Action
10.0.1.25 10.0.2.10 443 ACCEPT
10.0.1.25 10.0.2.10 22 REJECT
This information can be extremely useful when troubleshooting connectivity.

How VPC Flow Logs Fit Into a VPC

Consider a simple AWS environment:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
Internet
|
v
Internet Gateway
|
v
+-------------+
| VPC |
| |
| Subnet |
| | |
| EC2 |
| | |
+-------------+
|
Flow Logs
|
v
CloudWatch / S3
Flow Logs can send captured records to supported destinations such as Amazon CloudWatch Logs or Amazon S3.
This gives you a central location where network traffic information can be analyzed.

ACCEPT vs REJECT

One of the most useful fields in a flow-log record is the traffic action.
For example:
1
ACCEPT
indicates that the traffic was permitted by the relevant network controls.
A record containing:
1
REJECT
indicates that the traffic was not permitted.
This can be extremely helpful when troubleshooting.
Suppose an application server cannot connect to a database:
1
2
3
4
5
Application Server
|
| TCP 3306
v
Database
Instead of guessing whether the problem is a Security Group, NACL, routing configuration, or something else, flow logs can provide evidence about whether traffic is reaching the network interface and whether it is being accepted or rejected.

A Practical Troubleshooting Example

Imagine we have two EC2 instances:
1
2
3
4
5
6
7
Web Server
10.0.1.10
|
| TCP 8080
v
Application Server
10.0.2.20
The application server isn't responding.
We can inspect the relevant flow logs.
Suppose we find:
1
2
3
10.0.1.10 → 10.0.2.20
Destination Port: 8080
Action: REJECT
Now we know that the traffic is being rejected somewhere in the network path.
We can then investigate:
  • Security Group rules
  • Network ACL rules
  • Route tables
  • Subnet configuration
  • Instance configuration
Instead of troubleshooting blindly, we now have a useful data point.

Flow Logs and Security Investigations

VPC Flow Logs can also be useful during security investigations.
For example, imagine an EC2 instance suddenly starts communicating with an unfamiliar external IP address.
Flow Logs can help identify:
1
2
3
4
5
6
7
8
9
10
11
Source:
10.0.1.15

Destination:
203.0.113.50

Destination Port:
443

Protocol:
TCP
By analyzing traffic patterns over time, security teams can investigate unusual communication.
However, Flow Logs alone don't tell you exactly what was inside the packets. They provide traffic metadata, not packet contents.
This distinction is important.

What VPC Flow Logs Don't Capture

VPC Flow Logs are not packet captures.
They don't provide the complete contents of network packets.
For example, they won't show:
1
2
3
4
HTTP request body
Password
Application payload
Full packet contents
Instead, they provide information about the connection itself.
Think of them as:
"Who communicated with whom, using which protocol and port, and was the traffic accepted or rejected?"
rather than:
"What exactly was inside the packet?"

Flow Logs vs Packet Capture

It's useful to understand the difference.
FeatureVPC Flow LogsPacket Capture
Source/destination IP✅✅
Port information✅✅
Protocol✅✅
Accepted/rejected information✅Depends
Full packet contents❌✅
Useful for network troubleshooting✅✅
Storage/analysis overheadGenerally lowerCan be significantly higher
For many initial troubleshooting scenarios, Flow Logs provide enough information without requiring a full packet capture.

Using Flow Logs for Security Monitoring

Flow Logs can become even more useful when combined with other AWS services.
For example:
1
2
3
4
5
6
7
8
9
10
11
12
VPC
|
v
VPC Flow Logs
|
+--------+--------+
| |
v v
CloudWatch S3
| |
v v
Monitoring Long-term analysis
Organizations can also build detection and alerting workflows around network traffic patterns.
For example, suspicious patterns might include:
  • Unexpected connections to external IP addresses
  • Repeated connection attempts
  • Unexpected ports
  • Large amounts of outbound traffic
  • Communication between resources that normally shouldn't communicate
The important point is that Flow Logs provide the network-level evidence that can support these investigations.

Common Mistakes

1. Assuming Flow Logs capture packet contents

They don't.
Flow Logs provide metadata about traffic rather than complete packet contents.

2. Assuming REJECT always means the Security Group rejected it

A rejected flow should be investigated in the context of the entire network path and AWS configuration. Don't immediately assume one specific control is responsible.

3. Ignoring timestamps

Network investigations depend heavily on timing.
Always correlate flow-log events with:
  • Application logs
  • CloudTrail events
  • EC2 logs
  • Security alerts
  • Other monitoring data

4. Collecting logs without a retention strategy

Flow Logs can generate significant amounts of data in busy environments.
Define appropriate retention and analysis requirements before enabling large-scale logging.

Best Practices

When implementing VPC Flow Logs:

Use them strategically

Enable logging where it provides meaningful visibility, particularly for important workloads and troubleshooting scenarios.

Centralize analysis

Sending logs to a centralized destination makes investigation easier across multiple workloads.

Correlate with other logs

Flow Logs become much more useful when combined with application, authentication, and AWS API activity.

Protect your logs

Network logs can contain sensitive infrastructure information, so access should be controlled appropriately.

Monitor unusual patterns

Don't just collect logs—use them to identify unexpected traffic and investigate anomalies.

Conclusion

VPC Flow Logs are an important visibility tool for AWS networking.
They can help answer questions such as:
  • Where is traffic coming from?
  • Where is it going?
  • Which port and protocol are being used?
  • Was the traffic accepted or rejected?
  • When did the communication occur?
They don't replace Security Groups, NACLs, or packet-capture tools. Instead, they provide another layer of visibility that helps cloud engineers and security teams understand what's happening inside their AWS network.
The key takeaway is:
When network connectivity doesn't behave as expected, don't just change rules—first look at the traffic and gather evidence.
Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article