Controls3 May 2026 6 min read

VPC Security Controls for SOC 2 Compliance

Secure your AWS VPC for SOC 2. Covers subnet segmentation, security groups, NACLs, flow logs, and how VPC architecture maps to CC6 access controls.

Key Takeaways

VPC subnet segmentation (public/private) enforces network-level access controls required by CC6.1.
Security groups should follow least-privilege: allow only specific ports from specific sources.
VPC Flow Logs provide network-level audit trails and anomaly detection evidence for CC7.2.
Disable default VPC in all regions — it is a common misconfiguration that exposes resources.
AWS Network Firewall or WAF should be deployed at the perimeter for defense in depth.

In this guide

VPC Architecture and SOC 2
Public vs Private Subnet Design
Security Group Best Practices
VPC Flow Logs for CC7.2
Eliminating Default VPC Risk
VPC Evidence for SOC 2

VPC Architecture and SOC 2

Your VPC architecture is the network-level implementation of access controls. CC6.1 (least privilege), CC6.6 (protection of information assets), and CC7.1 (baseline configurations) all have VPC-level implications. Auditors evaluate whether your network design prevents unauthorized lateral movement and restricts access to sensitive resources.

A well-designed VPC for SOC 2 keeps databases and internal services in private subnets with no direct internet access, exposes only load balancers and API gateways in public subnets, and uses security groups as micro-segmentation controls between tiers.

Public vs Private Subnet Design

A three-tier subnet architecture is the standard for SOC 2-compliant AWS deployments: (1) Public subnets: contain only internet-facing resources — Application Load Balancers, NAT Gateways, bastion hosts (ideally replaced by SSM). (2) Application subnets (private): contain compute resources — ECS tasks, EC2 instances, Lambda functions in VPC. (3) Data subnets (private): contain databases — RDS, ElastiCache, Elasticsearch. No route from the internet to these subnets.

Each subnet tier should be in at least two Availability Zones for high availability. Private subnets route outbound internet traffic through a NAT Gateway in the public subnet — this allows egress (for software updates, external API calls) without allowing inbound connections.

Security Group Best Practices

Security groups act as instance-level firewalls. Apply least privilege: allow only the ports and protocols required. Avoid "allow all" ingress rules (0.0.0.0/0 on any port). Use security group references rather than CIDR blocks where possible — reference the application server security group as the source for database security group rules, rather than the entire VPC CIDR.

Specific rules for a standard three-tier app: Load balancer SG: inbound 443 from 0.0.0.0/0, inbound 80 from 0.0.0.0/0 (redirect to 443). Application SG: inbound 8080 (or app port) from load balancer SG only. Database SG: inbound 5432 (PostgreSQL) or 3306 (MySQL) from application SG only. No inbound SSH/RDP from 0.0.0.0/0.

AWS Config rule "restricted-ssh" alerts on security groups allowing unrestricted SSH access. "vpc-sg-open-only-to-authorized-ports" is a customizable rule for port-specific checks. Enable these and evidence compliant results.

VPC Flow Logs for CC7.2

VPC Flow Logs capture information about IP traffic going to and from network interfaces in your VPC. They are essential for CC7.2 network anomaly detection — identifying unusual traffic patterns, port scans, data exfiltration attempts, and communication with known malicious IPs.

Enable VPC Flow Logs for your VPC, capturing all traffic (accepted and rejected). Publish to CloudWatch Logs for real-time analysis or to S3 for long-term retention. For SOC 2, capture at least the default fields: version, account-id, interface-id, srcaddr, dstaddr, srcport, dstport, protocol, packets, bytes, action.

Use CloudWatch Log Insights or Athena to query flow logs for investigation. GuardDuty also analyzes VPC Flow Logs automatically — enabling GuardDuty and VPC Flow Logs together provides both raw evidence and automated anomaly detection.

Eliminating Default VPC Risk

AWS creates a default VPC in every region with a fully permissive security group (all traffic inbound from within the VPC) and subnets that auto-assign public IP addresses. Launching resources in the default VPC is a common misconfiguration that can expose them more broadly than intended.

Delete the default VPC in all regions: VPC console > Your VPCs > select default VPC > Actions > Delete VPC. In regions where you don't run workloads, this eliminates the risk of a developer accidentally launching a resource there. Enable AWS Config rule "vpc-default-security-group-closed" to alert if the default VPC security group allows traffic.

VPC Evidence for SOC 2

(1) VPC architecture diagram showing public, application, and data subnet tiers with routing tables. (2) Security group configurations for key resources showing least-privilege rules. (3) AWS Config findings for "restricted-ssh" — compliant. (4) VPC Flow Logs enabled screenshot for each VPC. (5) Sample Flow Log query results showing investigation of specific traffic or period. (6) Default VPC deletion confirmation (or justification if retained).

Frequently Asked Questions

Do we need a VPC for Lambda functions, or is the default AWS network sufficient?

Lambda functions not in a VPC cannot access private VPC resources (RDS in private subnets). If your Lambda functions need to access private databases or internal services, deploy them in your VPC in application subnets. For SOC 2, Lambda functions handling sensitive data should be in a VPC to enforce network-level access controls and capture traffic in VPC Flow Logs.

What is AWS Network Firewall and when do we need it for SOC 2?

AWS Network Firewall is a managed firewall service for VPCs that provides stateful packet inspection, intrusion prevention (Suricata-compatible rules), and domain-based egress filtering. It is needed for SOC 2 when you want to inspect and control traffic beyond what security groups offer — particularly egress filtering to known malicious domains and intrusion detection. It's a SOC 2 CC7.2 strengthening control rather than a baseline requirement.

Can we use NACLs instead of security groups for access control?

Use both. Security groups are stateful and operate at the instance level — they are the primary access control. NACLs are stateless and operate at the subnet level — use them as a secondary layer to deny specific IP ranges (known malicious ranges, geographic blocks) or to enforce explicit deny rules. NACLs are harder to manage but add defense in depth.

VPC peering vs Transit Gateway — which is more secure for SOC 2?

Both can be configured securely. VPC peering is simpler and doesn't route through a central hub, which limits blast radius if one VPC is compromised. Transit Gateway provides centralized routing and is better for large multi-VPC environments. For SOC 2, the key is that routing tables in peered VPCs or Transit Gateway route tables enforce least-privilege network access between environments.

How do VPC Flow Logs differ from CloudTrail for SOC 2 purposes?

CloudTrail logs AWS API calls (management plane) — who created, modified, or deleted AWS resources. VPC Flow Logs log network traffic (data plane) — IP-level traffic between resources. Both are needed: CloudTrail for control plane audit trail, VPC Flow Logs for network-level anomaly detection. GuardDuty consumes both.