FAR 52.204-21 and CMMC 2.0 Level 1 Control SC.L1-B.1.XI require covered contractor information systems to isolate publicly accessible components from internal systems; implementing cloud-based subnetworks (a simple DMZ pattern) is a practical way for small businesses to meet that requirement while maintaining a clear audit trail and defensible architecture.
What this control expects and how it maps to cloud design
The expectation is straightforward: place resources that must be reachable from the public internet—web servers, API gateways, public load balancers, static content endpoints—into a logically separated network zone and limit their ability to directly reach or be reached by systems that store Controlled Unclassified Information (CUI). For compliance evidence you will need architecture diagrams, route/security rule listings, and logging showing traffic flow controls; for cloud deployments that translates to VPC/VNet/subnet design, route tables, security groups/NSGs/firewall rules, and network logging (Flow Logs/NSG Flow logs/Firewall logs).
Provider-specific implementation notes
AWS (recommended DMZ pattern)
Create a VPC (e.g., 10.0.0.0/16) and define at least one public subnet (10.0.1.0/24) and one private subnet (10.0.2.0/24). Attach an Internet Gateway (IGW) and associate a route table to the public subnet with 0.0.0.0/0 -> IGW. Place load balancers (ALB/NLB) or public-facing EC2 instances in the public subnet, but host application servers and CUI storage (RDS, S3 with VPC endpoints) in private subnets. Use a NAT Gateway (Elastic IP + NAT) in the public subnet so private instances can egress to the internet without public IPs. Harden security with Security Groups (allow only required ports from ALB or specific IP ranges) and optional NACLs. Enable VPC Flow Logs (CloudWatch Logs or S3) and CloudTrail for network/elevation audit trails. Example CLI: aws ec2 create-nat-gateway --subnet-id subnet-abc --allocation-id eipalloc-123.
Azure (VNet and subnet segmentation)
Create an Azure Virtual Network (e.g., 10.1.0.0/16) and partition it into subnets: a public DMZ subnet (10.1.1.0/24) and private subnets (10.1.2.0/24). Deploy an Azure Application Gateway or Azure Load Balancer with a public IP in the DMZ subnet, and host backend App Service or VMs in private subnets with no public IPs. Control access using Network Security Groups (NSGs) bound to subnets and/or NICs, and use Azure Firewall or Azure Virtual WAN for centralized outbound filtering or forced-tunneling. Use Azure Bastion for secure RDP/SSH access to private VMs instead of exposing RDP/SSH ports. Turn on NSG flow logs (Azure Monitor / Storage) and enable Diagnostic settings for Application Gateway and Firewall for compliance evidence. CLI example: az network vnet create --name ProdVNet --resource-group Rg --address-prefix 10.1.0.0/16.
GCP (VPC, subnets, Cloud NAT, and external load balancers)
GCP uses a global VPC with regional subnets—create a public-facing subnet and private subnets (e.g., 10.2.0.0/16 with 10.2.1.0/24 DMZ). Place the external HTTP(S) Load Balancer or Cloud Run/Cloud Functions with serverless NEG in front of backends located in private subnets. Use Cloud NAT for controlled egress from private instances so they can reach patch servers or APIs without public IP addresses. Implement Firewall rules that restrict ingress to only required ports and sources (e.g., 80/443 from 0.0.0.0/0 only to the load balancer, not to backend VMs). Enable VPC Flow Logs and Cloud Logging and configure Cloud Armor for DDoS/WAF capabilities. CLI example: gcloud compute networks subnets create dmz-subnet --network=prod-vpc --range=10.2.1.0/24 --region=us-central1.
Design patterns, small-business scenarios, and technical specifics
For a small business hosting a public website and internal admin portal, a practical topology is: public ALB/Application Gateway in the DMZ subnet receiving internet traffic; backend app servers and the database in private subnets with no public IPs; NAT for patching egress; and a bastion host or managed service (Azure Bastion, AWS Session Manager) for admin access. Use CIDR planning like VPC 10.0.0.0/16, DMZ 10.0.1.0/24, app 10.0.2.0/24, db 10.0.3.0/24. When using IaC (Terraform/ARM/Bicep), tag resources with contract identifiers and control mappings so evidence is traceable to the FAR/CMMC control during an assessment. Example Terraform pattern: put ALB in aws_subnet.public[*], backend in aws_subnet.private[*], and define aws_security_group rules to only allow ALB -> backend on port 443.
Operational controls, logging, and evidence collection
To satisfy auditors: enable and retain VPC Flow Logs, CloudTrail/Cloud Audit Logs, load balancer access logs, and host OS logs (centralized to a logging workspace/S3 bucket with restricted access). Maintain route table screenshots or JSON exports, security group/NSG/firewall rule exports, and an architecture diagram showing subnet boundaries and data flow. Implement automated checks (AWS Config/Azure Policy/GCP Forseti or Organization Policy) that enforce no public IPs on backend instances and require Flow Logs enabled. Document change management and evidence of periodic review for network rules and firewall exceptions.
Risks of not implementing and practical compliance tips
Failing to separate public components risks direct exposure of CUI-hosting systems, lateral movement after a compromise, and loss of contractual eligibility; a public-facing database or misconfigured security group is a common root cause for breaches. Practical tips: apply least privilege network rules (deny all, then allow required), minimize attack surface by placing only load balancers in the public subnet, use managed services (CloudFront, Azure CDN, GCP Cloud CDN) to front public assets when possible, enforce multi-factor admin access and use ephemeral admin sessions, and routinely verify architecture drift with automated IaC scans. Keep an evidence package (diagram, rule listings, logs, policy assertions) ready and link each item to the specific control ID (FAR 52.204-21 and SC.L1-B.1.XI) in your compliance binder.
Summary: Implementing cloud-based subnetworks for publicly accessible components is a practical, high-impact control to satisfy FAR 52.204-21 and CMMC 2.0 SC.L1-B.1.XI—use a DMZ/subnet pattern, provider-specific constructs (IGW/NAT/ALB/NSG/Cloud NAT), centralized logging, and automated policy enforcement; document the design and retain logs as evidence to demonstrate that public-facing systems cannot directly access CUI-hosting resources and that you are actively monitoring and controlling network boundaries.
