AWS Securityaws vpc flow logs soc 2vpc soc 2 compliancenetwork monitoring soc 2cc7.1 vpc

AWS VPC Flow Logs for SOC 2: Network Monitoring and CC7.1 Evidence

How VPC flow logs satisfy SOC 2 CC7.1 network monitoring requirements, how to enable them across all VPCs, and how to use flow log data as auditor-ready compliance evidence.

SecureSpect Team··5 min

VPC Flow Logs and SOC 2 CC7.1

SOC 2 CC7.1 requires continuous monitoring of system components. For network infrastructure, this translates to capturing and retaining network traffic logs. In AWS, VPC Flow Logs are the primary mechanism for satisfying this requirement.

VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC — source IP, destination IP, source port, destination port, protocol, bytes transferred, and whether traffic was accepted or rejected. This data is essential for:

  • Detecting unauthorized access attempts (rejected connections from unexpected sources)
  • Investigating security incidents (tracing the path of an attack)
  • Verifying that security group rules are operating as intended

SecureSpect checks two VPC conditions that map to CC7.1:

aws.vpc.flow_logs_enabled — CC7.1

Verifies that VPC flow logs are enabled for all VPCs in the account.

A VPC with no flow logs is a monitoring blind spot.

aws.vpc.default_vpc_not_in_use — CC6.6

Verifies that the default VPC has no EC2 instances, no subnets with

running resources, and is not being used for production workloads.

Default VPCs have permissive configurations not suitable for production.

Enabling VPC Flow Logs

Enable flow logs for all VPCs. The most common setup is delivery to CloudWatch Logs:

# Get all VPC IDs in the account

VPC_IDS=$(aws ec2 describe-vpcs --query 'Vpcs[*].VpcId' --output text)

# Create a CloudWatch log group for flow logs

aws logs create-log-group --log-group-name /aws/vpc/flow-logs

# Create IAM role for flow logs to publish to CloudWatch

# (Assume you have a role ARN: arn:aws:iam::123456789:role/vpc-flow-logs-role)

# Enable flow logs for each VPC

for vpc_id in $VPC_IDS; do

aws ec2 create-flow-logs --resource-type VPC --resource-ids $vpc_id --traffic-type ALL --log-destination-type cloud-watch-logs --log-group-name /aws/vpc/flow-logs --deliver-logs-permission-arn arn:aws:iam::123456789:role/vpc-flow-logs-role

echo "Flow logs enabled for $vpc_id"

done

For cost efficiency with high-traffic VPCs, deliver flow logs to S3 instead of CloudWatch Logs — S3 storage is significantly cheaper:

aws ec2 create-flow-logs   --resource-type VPC   --resource-ids vpc-12345678   --traffic-type ALL   --log-destination-type s3   --log-destination arn:aws:s3:::your-flow-logs-bucket/vpc-flow-logs/

Retaining Flow Logs for SOC 2

SOC 2 Type II requires evidence that monitoring was continuous throughout the audit period (6–12 months). This means flow logs must be retained for at least 12 months.

For CloudWatch Logs:

aws logs put-retention-policy   --log-group-name /aws/vpc/flow-logs   --retention-in-days 365

For S3, set an S3 lifecycle policy to move logs to Glacier after 90 days (cheaper) and delete after 365 days.

Using Flow Log Data as Audit Evidence

Flow logs are only useful if someone is monitoring them. For CC7.1, auditors want to see a process for reviewing network anomalies, not just that logs are being captured.

Effective monitoring approaches:

CloudWatch Metrics Filters: Create metric filters that count rejected connections to sensitive ports. Alert on spikes.

aws logs put-metric-filter   --log-group-name /aws/vpc/flow-logs   --filter-name rejected-ssh-attempts   --filter-pattern '[version, account_id, interface_id, srcaddr, dstaddr, srcport, dstport="22", protocol, packets, bytes, windowstart, windowend, action="REJECT", log_status]'   --metric-transformations metricName=RejectedSSHAttempts,metricNamespace=VPCFlowLogs,metricValue=1

Amazon Athena: Query flow logs in S3 with SQL for incident investigation and periodic reporting.

CloudWatch Logs Insights: Ad-hoc querying for security investigations.

The Default VPC Problem

AWS creates a default VPC in every region. The default VPC has a permissive configuration: subnets in every availability zone, an internet gateway attached, and a main route table with a route to the internet. This is convenient for quick experiments — and dangerous for production.

SecureSpect flags default VPCs that are actively being used. The fix: migrate any production resources out of the default VPC into a properly configured VPC with private subnets, NAT gateways, and network ACLs. Then leave the default VPC empty or delete it.

FAQ

Do I need flow logs for every subnet, or just at the VPC level? VPC-level flow logs capture all traffic across the VPC, including all subnets. Subnet-level or ENI-level flow logs provide more granular data but cost more. VPC-level is sufficient for SOC 2.

How much do VPC flow logs cost? CloudWatch Logs ingestion is ~$0.50/GB. A typical startup VPC generates 5–50 GB/month of flow log data — roughly $2.50–$25/month per VPC. Delivering to S3 instead costs roughly 10x less for storage.

Does GuardDuty make VPC flow logs redundant? No. GuardDuty analyzes VPC flow logs automatically, but raw flow log data retained in CloudWatch or S3 is what auditors can directly inspect. GuardDuty surfaces findings from flow log analysis; the flow logs are the underlying evidence trail.

Automate your SOC 2 evidence collection

Connect your AWS and GitHub environments and start collecting audit-ready evidence today. Free to start.

Start Free →More Articles