Analyzing Network Traffic with VPC Flow Logs

Learned how VPC Flow Logs, Security Groups, and Network ACLs work together to monitor and control network traffic.

Trần Đồng

Cloud Engineer | AWS | Generative AI & Agentic AI

Published Oct 4, 2026

Last modified Oct 4, 2026

I recently completed another AWS SimuLearn lab, this time focused on analyzing and controlling network traffic inside an Amazon VPC.

The biggest takeaway for me was finally understanding how Security Groups, Network ACLs, and VPC Flow Logs work together.

Before going deeper, this is how I now think about them:

1
2
3
4
VPC Flow Logs   = records network traffic metadata
Security Group  = stateful firewall for ENIs/resources
Network ACL     = stateless firewall for subnets
ENI             = network interface used by AWS resources

Architecture

The simplified traffic flow looks like this:

1
2
3
4
5
6
7
8
9
10
11
12
Internet
   |
   v
Network ACL
(subnet level)
   |
   v
Security Group
(ENI / resource level)
   |
   v
EC2

And for monitoring:

1
2
3
4
5
6
7
8
9
10
11
Network Traffic
      |
      v
VPC Flow Logs
      |
      v
Amazon S3
      |
      v
Analyze source IP, destination IP,
ports, protocol, ACCEPT / REJECT

1. Understanding Security Groups

A Security Group acts as a firewall around resources such as EC2 network interfaces.

The important thing is that Security Groups are stateful.

For example:

1
Client → EC2:443

If the inbound request is allowed, the response:

1
EC2 → Client

is automatically allowed as part of the same connection.

Another important concept is that Security Groups only contain ALLOW rules.

There is no explicit DENY rule.

1
2
3
4
5
Matching ALLOW rule
→ traffic is allowed

No matching ALLOW rule
→ traffic is implicitly denied

This is called implicit deny.

A simple way I remember it:

1
2
Security Group
= "If you are not explicitly allowed, you cannot enter."

2. Understanding Network ACLs

A Network ACL, or NACL, operates at the subnet level.

Unlike Security Groups, NACLs are stateless.

This means inbound and outbound traffic are evaluated independently.

For example:

1
Client → EC2

requires an inbound NACL rule.

The response:

1
EC2 → Client

must also match an outbound NACL rule.

The NACL does not remember that the response belongs to an existing connection.

Another major difference is that NACLs support both:

1
2
ALLOW
DENY

This makes them useful when we explicitly want to block a specific IP address.

3. How NACL Rules Are Evaluated

NACL rules have rule numbers.

For example:

1
2
3
100  DENY   1.2.3.4/32
200  ALLOW  0.0.0.0/0
*    DENY   ALL

AWS evaluates the lowest rule number first.

For traffic coming from:

1
1.2.3.4

the first matching rule is:

1
100 → DENY

The evaluation stops there.

The final:

1
* → DENY ALL

is the default catch-all rule.

So if traffic does not match an earlier ALLOW rule, it is denied.

One thing I found important is that rule order matters.

This would not work as expected:

1
2
100  ALLOW  0.0.0.0/0
200  DENY   1.2.3.4/32

Because 1.2.3.4 already matches rule 100, so the later deny rule is never evaluated.

4. Security Group vs Network ACL

This lab made the difference much clearer to me:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Security Group
-----------------------------
Level       = ENI / resource
State       = Stateful
Rules       = ALLOW only
Evaluation  = All rules together
Default     = Implicit deny

Network ACL
-----------------------------
Level       = Subnet
State       = Stateless
Rules       = ALLOW + DENY
Evaluation  = Lowest rule number first
Default     = * DENY

Traffic must pass both layers:

1
2
3
4
5
6
7
8
NACL ALLOW + SG ALLOW
→ allowed

NACL DENY + SG ALLOW
→ blocked

NACL ALLOW + SG no matching ALLOW
→ blocked

So even if the Security Group allows traffic, the NACL can still block it.

5. Monitoring Traffic with VPC Flow Logs

The next important concept was VPC Flow Logs.

Flow Logs record metadata about network traffic going through network interfaces.

A typical record contains fields such as:

1
2
3
4
5
6
7
8
9
srcaddr
dstaddr
srcport
dstport
protocol
packets
bytes
action
interface-id

For example:

1
2
3
4
5
6
srcaddr   = 13.217.79.129
dstaddr   = 10.10.0.20
srcport   = 443
dstport   = 59892
protocol  = 6
action    = ACCEPT

This tells us:

1
2
3
4
Source IP      = 13.217.79.129
Destination IP = 10.10.0.20
Protocol       = TCP
Result         = ACCEPT

VPC Flow Logs do not capture the actual packet contents.

Instead, they capture metadata about the network flow.

That makes them useful for:

1
2
3
4
5
Troubleshooting
Traffic analysis
Security investigation
Finding suspicious IP addresses
Checking ACCEPT / REJECT traffic

6. Detecting and Blocking a Problematic IP

The main workflow of the lab was:

1
2
3
4
5
6
7
8
9
10
11
12
13
VPC Flow Logs
      |
      v
Analyze traffic
      |
      v
Identify problematic public IP
      |
      v
Create NACL DENY rule
      |
      v
Block the traffic

This was where the relationship between monitoring and access control became clear.

Flow Logs tell us:

What traffic is happening?

NACL tells us:

What traffic should be allowed or denied?

7. Verifying That the Rule Works

The lab also created another Flow Log configured with:

1
Filter = REJECT

This means the log captures only rejected traffic.

So after adding the NACL deny rule, the flow becomes:

1
2
3
4
5
6
7
8
9
10
Problematic IP
      |
      v
Network ACL
      |
    DENY
      |
      v
VPC Flow Logs
Filter = REJECT

If the rejected traffic appears in the Flow Logs, we can verify that the NACL rule is working.

This was a useful example of using observability not only to detect a problem, but also to confirm that a security change actually fixed it.

What I Learned

The biggest takeaway from this lab was understanding that network security in a VPC is built from multiple layers:

1
2
3
4
5
6
7
8
VPC Flow Logs
= observe the traffic

Network ACL
= control traffic at subnet level

Security Group
= control traffic at resource level

And the traffic path is:

1
2
3
4
5
6
7
Internet
   ↓
Network ACL
   ↓
Security Group
   ↓
ENI / EC2

The mental model I now use is:

1
2
3
NACL = outer subnet firewall
SG   = resource firewall
Flow Logs = network visibility

Once I understood the difference between stateful vs stateless and implicit deny vs explicit deny, VPC traffic control became much easier to reason about.

This lab was a useful hands-on exercise for understanding how AWS combines network visibility and layered access control inside a VPC.

Lab: AWS SimuLearn – Analyzing Network Traffic
https://skillbuilder.aws/learn/UW5N4TESBX/aws-simulearn-analyzing-network-traffic/T1N45WD97V?parentId=67BBEU3C7N

# aws-academy

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

Builder Center

Analyzing Network Traffic with VPC Flow Logs

Trần Đồng

Architecture

1. Understanding Security Groups

2. Understanding Network ACLs

3. How NACL Rules Are Evaluated

4. Security Group vs Network ACL

5. Monitoring Traffic with VPC Flow Logs

6. Detecting and Blocking a Problematic IP

7. Verifying That the Rule Works

What I Learned