Using VPC Flow logs to tighten Security Group Rules

Using AWS VPC Flow logs to tighten Security Group Rules

Securing cloud networks requires more than just blocking external threats – it also demands comprehensive cloud network visibility, careful monitoring and restriction of internal connections. Even if an attacker breaches your perimeter, a well-architected and properly segmented internal network can contain lateral movement and significantly mitigate the impact of the breach. This is why enforcing tight network controls on both inbound (ingress) and outbound (egress) traffic for external-facing and internal workloads is crucial to maintaining a strong security posture.

‍

Challenges with AWS Security Groups

Lack of “hit counter” which leads to the proliferation of unused Rules

Unlike traditional on-premise firewalls, security group rules do not come with a 'hit counters' or 'last used' timestamps. This lack of cloud visibility makes it difficult for DevSecops or security engineers to identify unused access rules and remove them, as highlighted in numerous security forums and discussions.

Inability to Trace Rule-Level traffic matches which leads to overly Permissive Security Group Rules

Security group rules are often misconfigured to allow "All traffic" or an excessively wide range of ports, creating an easy paths for attackers to move laterally within the network or exfiltrate sensitive data.

While VPC Flow Logs provide detailed records of accepted and rejected network traffic, they do not indicate which security group rule was responsible for allowing or denying that traffic. This limitation makes it difficult for security teams to determine whether an overly permissive rule is actually being used, or if it can be safely tightened or removed.

‍

Using VPC Flow Logs to Identify "Unused" Security Group rules and "Tighten" Wide Open rules

Understanding VPC Flow Logs

VPC Flow Logs enable you to capture information about the IP traffic going to and from network interfaces in your VPC. This data provides crucial visibility into your cloud network communications.

A typical VPC flow log record contains these fields:

‍

account-id action az-id bytes dstaddr dstport end flow-direction instance-id interface-id log-status packets pkt-dst-aws-service pkt-dstaddr pkt-src-aws-service pkt-srcaddr protocol region srcaddr srcport start sublocation-id sublocation-type subnet-id tcp-flags traffic-path type version vpc-id

‍

Key Fields for Security Group Analysis

To determine if a communication is successfully established—and therefore if a security group rule is actively used by a specific workload—focus on these fields:

• account-id
• interface-id
• action
• pkt-dstaddr
• dstport
• Pkt-srcaddr
• Tcp-flags
• flow-direction

‍

A practical example

Connection Request

002244369527 ACCEPT use1-az6 11814 10.10.0.73 4000 1738854253 ingress i-03efaa125b5acbd69 eni-027ce9d7c95605b1d OK 22 - 10.10.0.73 - 100.64.0.39 6 us-east-1 100.64.0.39 18762 1738854240 - - subnet-081cfbbbb8bfeb867 2 - IPv4 5 vpc-0d585d9ae3c06759b

This record shows:

• Action: ACCEPT
• TCP flag: 2 (SYN packet)
• Protocol: 6 (TCP)
• Direction: ingress

In other words, 100.64.0.39 (pkt-srcaddr) is trying to establish (TCP Flag 2, SYN) a communication with 10.10.0.73 (pkt-dstaddr) on port 4000 (dstport).

At this point, we cannot confirm that communication is fully established or that the security group rule allowing port 4000 to this ENI (eni-027ce9d7c95605b1d) is actually being used. We need to observe the reply.

‍

Connection Response

002244369527 ACCEPT use1-az6 9025 100.64.0.39 18762 1738854253 egress i-03efaa125b5acbd69 eni-027ce9d7c95605b1d OK 17 - 100.64.0.39 - 10.10.0.73 6 us-east-1 10.10.0.73 4000 1738854240 - - subnet-081cfbbbb8bfeb867 18 1 IPv4 5 vpc-0d585d9ae3c06759b

This record shows:

• Action: ACCEPT
• TCP flag: 18 (SYN-ACK packet)
• Protocol: 6 (TCP)
• Direction: egress

In other words, the host at 10.10.0.73 (pkt-srcaddr) is replying (TCP Flag 18, SYN-ACK) to 100.64.0.39 (pkt-dstaddr) from port 4000.

With this response, we can confirm that the security group rule allowing TCP port 4000 on this workload's ENI (eni-027ce9d7c95605b1d) is actively being used.

For a comprehensive list of TCP flags in vpc flow logs see here (FIX ME article about vpc flow logs flags).

‍

From Analysis to Action

The overall process to analyze VPC flow logs and correlate against security group rules should look like the below

By systematically analyzing VPC Flow Logs, you can:

• Identify which security group rules are actually being used
• Determine which ports are necessary for your workloads
• Detect overly permissive rules that should be tightened

‍

Automating the process with CloudFence

Although you can manually analyze VPC Flow Logs by following the steps above—with a custom function or via AWS Athena—this approach is time‑consuming, error‑prone, and still requires you to correlate flow logs with your security group configuration.

The CloudFence team has developed an automated cloud network security and visibility solution that simplifies VPC Flow Log and Security Group analysis.

‍

Effortlessly Identify Unused Security Group Rules:

Rather than managing complex queries and manual correlation, CloudFence provides:

• ‍Centralized Inactive‑Rule Dashboard
  A single, continuously updated view of every security group’s active and inactive rules—automatically matched against ingested traffic flows.
  
  ‍
• Per‑ENI Activity Timestamps
  Exact “last seen” timestamps for each rule on every Elastic Network Interface, so you know when rules were last exercised.
  
  ‍
• ‍Per‑ENI Hit‑Count Metrics
  Detailed usage counts showing how often each rule is triggered, broken down by ENI for precise visibility.

Lock Down “All Ports” Security Group Rules:

• CloudFence detects overly permissive inbound and outbound rules that open “All ports” and helps you narrow them down to only the ports your applications actually need—ensuring strict adherence to the least‑privilege principle.