This practical guide shows how to configure AWS VPC subnetworks for public-facing assets to meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 (SC.L1-B.1.XI) — isolating publicly reachable services, restricting exposure, and producing evidence for auditors while keeping your services available.
Why this control matters (risk summary)
FAR 52.204-21 and CMMC Level 1 require basic safeguarding of Controlled Unclassified Information (CUI) and contractor systems; a common failure is improperly exposing internal services to the public internet. Without correct subnet design and controls, attackers can discover and exploit open ports, pivot from public hosts to internal systems, or exfiltrate data — resulting in data breaches, contract loss, regulatory penalties, and reputational harm to small businesses that handle government-related data.
Design principles to satisfy the control
Follow three core principles: separate public-facing workloads into dedicated public subnets, keep sensitive resources in private subnets with tightly controlled outbound access (NAT), and enforce least-privilege network access with security groups and network ACLs. Also ensure logging, monitoring, and documentation (AWS Config, VPC Flow Logs, CloudTrail) so you can demonstrate compliance during audits.
Practical steps — network topology and basic setup
Create an Internet Gateway and public route table
Typical public-facing topology: VPC -> public subnets (for ALB / NAT gateway / bastion) -> private subnets (for application and data). Example AWS CLI commands to create the core pieces: create an Internet Gateway, attach it to the VPC, create a route table, add a 0.0.0.0/0 route to the IGW, and associate the route table with the public subnet. Example commands:
aws ec2 create-internet-gateway --query 'InternetGateway.InternetGatewayId' && aws ec2 attach-internet-gateway --internet-gateway-id igw-xxxx --vpc-id vpc-xxxx
aws ec2 create-route-table --vpc-id vpc-xxxx --query 'RouteTable.RouteTableId' && aws ec2 create-route --route-table-id rtb-xxxx --destination-cidr-block 0.0.0.0/0 --gateway-id igw-xxxx
aws ec2 associate-route-table --subnet-id subnet-public-1 --route-table-id rtb-xxxx
Configure subnet attributes and deployment patterns
Set the public subnet to auto-assign public IPs for instances that must be directly reachable: aws ec2 modify-subnet-attribute --subnet-id subnet-public-1 --map-public-ip-on-launch. Use an ALB (in public subnets across Availability Zones) to terminate TLS with ACM certificates and route traffic to targets in private subnets — this keeps servers and databases off the public internet. For private subnets that need outbound internet access, place a NAT Gateway in a public subnet and add a route in the private route table: aws ec2 create-nat-gateway --subnet-id subnet-public-1 --allocation-id eipalloc-xxxx. Note NAT gateway costs; for very small budgets use a NAT instance with strict hardening and monitoring as an alternative.
Network controls: Security Groups, NACLs, and additional AWS services
Security groups are stateful and should be your primary access control: create an ALB security group allowing inbound 443/80 from 0.0.0.0/0 and tighten instance security groups to only accept traffic from the ALB SG and known management IPs. Example inbound SG rules: 443 from 0.0.0.0/0 (ALB), 22 from your office IP only (or better: disable SSH and use Session Manager/SSM). Network ACLs can provide an additional stateless filter at the subnet level (deny known bad IP ranges, block Telnet/NetBIOS), but avoid relying on NACLs for fine-grained host-level access because they are harder to manage. Enable AWS WAF in front of the ALB to block common web attacks and AWS Shield for DDoS protection if you host public services.
Monitoring, automation, and audit evidence
Enable VPC Flow Logs (to CloudWatch Logs or S3), AWS Config rules, and CloudTrail to capture configuration and access history required for FAR/CMMC evidence. Use managed Config rules or custom rules to flag: (a) subnets with a route to an IGW, (b) instances with public IPs, and (c) overly permissive security groups (e.g., 0.0.0.0/0 on SSH). Example AWS Config checks: evaluate resources for 'publicly accessible' flags and create remediation runbooks or automated Lambda remediations tied to Config or CloudWatch Events to remove unauthorized public exposure.
Small business scenario — concrete example
Example: a small e-commerce company (ContractCo) must host an order portal and store PII in a private database. Implement an ALB in two public subnets, terminate TLS using ACM, and route to EC2/ECS tasks in private subnets. The database (RDS) sits in private subnets with no public IP and access controlled by a DB security group limited to the application SG only. Management access uses AWS Systems Manager Session Manager (no SSH/RDP over the internet). Tag network resources (env=prod, project=orders) and record architecture diagrams and Config rule outputs to include in the compliance package.
Compliance tips and best practices
Document the default baseline (VPC design, subnet CIDRs, security groups, NACLs), perform periodic review of public IP allocation, and include automated checks in CI/CD pipelines (Terraform plan checks, CloudFormation Guard) to prevent accidental exposure. Maintain an exceptions register for any approved public exposure and require time-boxed reviews. Finally, train personnel to use least-privilege patterns (no blanket 0.0.0.0/0 SSH, use SSM instead) and incorporate alerts for newly attached IGWs, public IPs, or changes to route tables that open 0.0.0.0/0.
Summary: Configure dedicated public subnets with an Internet Gateway and ALB/NAT placements, keep sensitive workloads in private subnets, enforce access with security groups and NACLs, enable Flow Logs/Config/CloudTrail for evidence, and automate detection/remediation. These technical controls — when documented and actively monitored — align with FAR 52.204-21 and CMMC 2.0 Level 1 requirements and substantially reduce the risk of inadvertent public exposure for small businesses hosting government-related assets.
