This post gives practical, actionable steps for configuring AWS VPC subnets and Security Groups to meet the Compliance Framework requirement associated with FAR 52.204-21 and CMMC 2.0 Level 1 (Control SC.L1-B.1.XI), focusing on limiting and controlling network communications to protect Covered Contractor Information (CCI) and Controlled Unclassified Information (CUI).
Understanding the requirement and key objectives
At a high level the Compliance Framework practice addressed by SC.L1-B.1.XI requires that you restrict inbound and outbound network access to only authorized connections and components. Key objectives are network segmentation to separate public-facing workloads from CUI-processing components, least-privilege network access (only necessary ports and IPs), and logging/monitoring to produce evidence of enforced controls. For a small business this means designing a VPC that prevents accidental exposure of CUI, documents network controls, and produces auditable logs for compliance reviews.
Designing your VPC: subnets, route tables and NAT
Start with a simple but secure VPC topology: a 10.0.0.0/16 VPC with at least two AZs (if budget allows) and three tiers of subnets per AZ—public (/24), private-application (/24), and private-data (/24). Public subnets hold load balancers and a bastion (if used), private-application subnets host web/app servers, and private-data subnets host databases or storage that handles CUI. Route tables: public subnets route 0.0.0.0/0 to an Internet Gateway (igw), private subnets route 0.0.0.0/0 to a NAT Gateway (for outbound updates) or to no internet route if you use VPC endpoints for all AWS service traffic. For small businesses concerned about cost, a single-NAT per region is acceptable but document the availability trade-off; for stronger resilience, deploy NAT Gateways in each AZ.
Small-business example topology
Example: VPC 10.0.0.0/16 with the following subnets—10.0.1.0/24 (public-AZ1), 10.0.2.0/24 (private-app-AZ1), 10.0.3.0/24 (private-data-AZ1). Place an Application Load Balancer (ALB) in the public subnet (HTTPS termination), app servers in private-app subnets accessible only from the ALB, and an RDS instance in private-data subnets with no direct internet route. Use S3 Gateway endpoints (com.amazonaws.
Configuring Security Groups and NACLs (practical rules)
Security Groups (SGs) are your primary enforcement for SC.L1-B.1.XI—stateful, attached to ENIs, and follow least privilege. Example rules: ALB-SG inbound TCP 443 from 0.0.0.0/0 (or a tighter customer IP range if you host to specific customers); App-SG inbound TCP 443 only from ALB-SG (reference ALB-SG by ID as the source); App-SG inbound management (SSH/3389) blocked except from a management SG or a fixed management CIDR (e.g., your office IP /32). DB-SG inbound on DB port (e.g., 5432) only from App-SG. For egress, avoid the default “allow all” where possible—limit App-SG egress to 443 to required external services or, better, to VPC endpoints. Use Network ACLs (stateless) as an additional layer: deny 0.0.0.0/0 ephemeral ports at the subnet boundary if you need stricter segmentation, but rely on SGs for host-level rules.
Implementation notes and specific commands (AWS CLI / Terraform guidance)
Implementation should be automated and version-controlled. Example AWS CLI to create a Security Group: aws ec2 create-security-group --group-name app-sg --description "App SG" --vpc-id vpc-0123456789abcdef0. Add a rule to allow DB access only from App SG (replace IDs): aws ec2 authorize-security-group-ingress --group-id sg-db --protocol tcp --port 5432 --source-group sg-app. In Terraform, define SGs with security_group_rule resources referencing AWS security_group ids so changes are tracked in state. Use AWS Config managed rules like vpc-default-security-group-closed and restricted-common-ports (or write custom rules) to continuously evaluate compliance, and run your Terraform plan as an auditable change request to produce evidence for FAR/CMMC audits.
Monitoring, logging and producing compliance evidence
To satisfy the Compliance Framework you must show that network restrictions are active and monitored. Enable VPC Flow Logs (to CloudWatch Logs or S3) for subnets hosting CUI to capture traffic flows, enable AWS CloudTrail for API activity, and record Security Group changes with AWS Config (config rule evaluation history). Use GuardDuty for anomalous network activity and create alerting (SNS/Lambda/CIS dashboards). Maintain network diagrams, describe your subnet CIDRs, route tables, and security groups in your System Security Plan (SSP), and attach revision-controlled Terraform/CloudFormation templates and change requests as evidence.
Risks, common pitfalls and compliance tips
Risks of not implementing these controls include accidental exposure of CUI (publicly routable databases, overly permissive SGs), lateral movement after compromise, data exfiltration, and loss of contracts or fines under FAR. Common pitfalls: leaving default security groups open, using public subnets for components that store or process CUI, relying solely on NACLs without SGs, and not logging SG changes. Tips: (1) enforce least-privilege SGs and use SG references instead of CIDRs where possible; (2) prefer VPC endpoints to reduce egress; (3) require multi-person approval (PR/Change Control) for SG changes; (4) schedule periodic SG reviews and run automated “open ports” reports; (5) document exceptions and compensating controls in the SSP.
In summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI using AWS is primarily about proper VPC segmentation, least-privilege Security Group rules, minimizing internet egress with NAT and VPC endpoints, and having logging/automation to prove controls are enforced. Small businesses should start with a simple public/app/data subnet model, harden SGs by referencing other SGs and management CIDRs, enable VPC Flow Logs and AWS Config, and keep all network definitions in version-controlled IaC to produce clean audit evidence and reduce the risk of CUI exposure.
