This post shows practical, platform-specific steps you can use to implement subnetworks for publicly accessible components in AWS, GCP, and Azure to satisfy FAR 52.204-21 basic safeguarding expectations and CMMC 2.0 Level 1 Control SC.L1-B.1.XI — with small-business examples, concrete network settings, and compliance evidence recommendations.
Why subnetworks matter for FAR 52.204-21 / CMMC 2.0 Level 1
FAR 52.204-21 requires basic safeguards over contractor information systems and CMMC Level 1 expects straightforward security controls for Federal Contract Information (FCI) and public-facing resources; separating publicly accessible components into dedicated subnets reduces attack surface, enables focused security rules (firewall, routes, NAT), and provides discrete logging boundaries for evidence collection. The key objective is to ensure public-facing services are isolated from internal/private systems and that network controls restrict access to only what is necessary.
AWS implementation: practical steps and small-business example
Design: create a VPC (example CIDR 10.0.0.0/16) with at least two subnet groups: public (10.0.1.0/24) for ALB/NAT/ bastion and private (10.0.2.0/24) for application/backend. Attach an Internet Gateway (IGW) and configure a route table for the public subnet with 0.0.0.0/0 -> IGW. Put a NAT Gateway (in the public subnet) and add a route in the private subnet route table 0.0.0.0/0 -> NAT Gateway for outbound egress without public IPs on private instances. Security groups: ALB SG allows inbound 80/443 from 0.0.0.0/0; application targets use an SG that only allows inbound from the ALB SG (use SG reference). For administrative access, create a separate management security group that allows SSH/RDP only from known corporate IPs; never open 22/3389 to 0.0.0.0/0. Enable VPC Flow Logs and CloudTrail for auditing and S3 bucket or CloudWatch log export. Small-business scenario: host a public web app on EC2/ECS with ALB in the public subnet and database in private subnet accessed only by application security group — document the route tables, SG rules, and Flow Logs as compliance evidence.
GCP implementation: practical steps and small-business example
Design: create a custom-mode VPC and split subnets by function (e.g., public-subnet-us-central1 with 10.10.1.0/24, private-subnet-us-central1 with 10.10.2.0/24). For public resources (Compute Engine with external IP, Cloud NAT for private instances), ensure the public subnet has a default route to the Internet Gateway (GCP uses default route via the internet next hop when external IPs are present). To protect backends, do not assign external IPs to private instances and configure Cloud NAT (attached to the VPC) for outbound internet access. Use Firewall rules to allow ingress 80/443 to the load balancer only and create a firewall rule that allows traffic to your backend only from the load balancer health and proxy ranges. Enable VPC Flow Logs, Cloud Audit Logs, and export logs to Cloud Storage or BigQuery for retention. Small-business scenario: host APIs on GKE with an external HTTP(S) Load Balancer in the public subnet, keep backend node pools private (no external IP), use IAM service accounts with limited scopes, and record the VPC and firewall configs for audit.
Azure implementation: practical steps and small-business example
Design: create an Azure Virtual Network (VNet) with subnets such as public-subnet (10.1.0.0/24) containing Application Gateway/Load Balancer and private-subnet (10.1.1.0/24) for VMs and databases. Use a public IP on the Application Gateway in the public subnet; do not assign public IPs to backend VMs. Implement a NAT Gateway or Azure Firewall for controlled egress from private subnets. Use Network Security Groups (NSGs) to restrict inbound rules (allow 443/80 to App Gateway only) and use NSG application rules or Azure Firewall to limit east-west traffic. Enable Network Watcher Flow Logs and Azure Monitor / Activity Log exports for retention. Small-business scenario: host a single-page app in a Storage Static Website served via CDN and place APIs behind Application Gateway with WAF enabled, backend app servers in private subnets with NSG rules allowing only the Application Gateway subnet.
Logging, monitoring, and evidence collection: across all three clouds, enable network-level logs (VPC Flow Logs, VNet Flow Logs), platform audit logs (CloudTrail / Cloud Audit Logs / Azure Activity Log), and resource configuration snapshots (Terraform state, ARM templates, CloudFormation stacks). Retain logs for the period your contract or policy requires; for small businesses a common practical retention is 90–180 days for immediate incident response plus long-term archival for 1+ year where required. Export logs to a centralized storage/account that is immutable or versioned when possible, and tag each resource with contract identifiers so you can produce compliance evidence quickly.
Risks of not implementing: failure to isolate public components exposes internal systems and sensitive data to lateral movement, credential theft, or automated scanners. Non-compliance risks include contract termination, loss of future federal work, and reputational harm. Practically, an exposed management port or database with a public IP is a common route to ransomware or data exfiltration — separation of subnets, strict security group/NSG rules, and NATing private instances reduce these risks substantially.
Compliance tips and best practices (actionable): (1) Use infrastructure-as-code (Terraform/CloudFormation/ARM/Bicep) so network topology is auditable and reproducible. (2) Adopt least-privilege for security groups/NSGs — only open required ports and scopes. (3) Place load balancers or gateways in public subnets and keep stateful services in private subnets without public IPs. (4) Use dedicated management bastion hosts or jumpboxes with MFA and IP whitelisting for administrative access, or better, use cloud provider-managed session managers. (5) Enable WAF and rate-limiting on public endpoints. (6) Document architecture diagrams, route tables, and firewall rules and associate them with your compliance artifacts for FAR/CMMC evidence. (7) Automate periodic scans (CIS Benchmarks, network reachability) and produce reports for internal audit.
Summary: implementing dedicated public subnets with well-defined routing, NATing for private instances, strict security group/NSG rules, logging, and documented infrastructure-as-code satisfies the intent of FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI — and it’s practical for small businesses. Follow the platform-specific steps above, collect logs and configuration snapshots as evidence, and enforce least-privilege access to minimize exposure while keeping your public services reachable and compliant.
