This post explains how to build a dedicated cloud VPC subnetwork for public-facing services in a way that satisfies the intent of FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI — namely, segregating publicly accessible resources and controlling access while preserving necessary public reachability for customer-facing systems.
Why segregate public services (compliance objectives)
FAR 52.204-21 requires basic safeguarding of contractor information, and CMMC Level 1 expects basic protections on systems handling Federal Contract Information (FCI). Separating public services into a distinct subnetwork reduces the blast radius of a compromise, simplifies monitoring and firewalling, and supports auditability: you can show that internet-exposed assets are isolated, have limited allowed ports, and are subject to focused logging and patching. For a small business this is a straightforward, cost-efficient step toward demonstrable compliance.
Design principles and implementation notes
Design principles are: (1) place internet-facing endpoints in a dedicated public subnet(s) with a minimal exposure footprint, (2) place backend systems (databases, application servers, admin hosts) in private subnets with no direct internet routability, (3) use infrastructure-level controls (IGW/NAT, route tables, security groups/NSGs, load balancers) to strictly limit allowed traffic, and (4) enable logging and automated enforcement (VPC Flow Logs / NSG flow logs, CloudTrail / Azure Activity Logs, and policy-as-code). Implementation notes: choose clear CIDR segmentation (e.g., 10.0.0.0/16 for the VPC, public subnets 10.0.1.0/24 and 10.0.2.0/24 across AZs), keep subnets small but sufficient, and automate creation with Terraform/CloudFormation/Bicep to produce repeatable, auditable assets.
AWS example (concrete steps)
AWS pattern: create a VPC (10.0.0.0/16), two public subnets (10.0.1.0/24 and 10.0.2.0/24) in different AZs for high availability, and two private subnets for application/data. Attach an Internet Gateway (IGW) and associate a route table for the public subnets with 0.0.0.0/0 → IGW. Deploy an internet-facing Application Load Balancer (ALB) in the public subnets and register targets that are in private subnets. For egress, place a NAT Gateway in a public subnet with an Elastic IP and route private subnet traffic to the NAT. Use Security Groups so ALB allows inbound 80/443 from 0.0.0.0/0, application servers allow inbound only from the ALB security group (not the internet), and administrative ports (SSH/RDP) are restricted to known management IPs or a bastion host in a dedicated management subnet. Enable VPC Flow Logs to CloudWatch/CloudWatch Logs or S3, enable AWS Config and CloudTrail, and put WAF in front of the ALB. For static content consider S3 with Block Public Access and CloudFront + Origin Access Identity so the bucket itself is not directly public.
Azure example (concrete steps)
Azure pattern: create a Virtual Network (10.1.0.0/16), add public subnets (10.1.1.0/24) for internet-facing resources and private subnets (10.1.2.0/24) for back-end. Attach a Public IP and an Internet-facing Application Gateway or Azure Load Balancer in the public subnet. Use Network Security Groups (NSGs) to allow HTTP/HTTPS with a rule priority 100 allowing TCP 80/443 from any source and then a priority 200 explicit deny for other inbound traffic to the public subnet. Back-end subnets should have NSGs that deny direct inbound internet access and only permit traffic from the Application Gateway subnet. Use Azure NAT Gateway for controlled outbound connections from private subnets instead of giving VMs public IPs. Apply Azure Policy to enforce tagging, disallow creation of public IPs outside approved resources, and send NSG flow logs + Diagnostic Settings to Log Analytics for retention and auditing.
Small-business scenarios, examples and operational tips
Scenario A: small contractor hosts a customer-facing portal that displays non-sensitive FCI (e.g., contract status). Implement an ALB/Application Gateway for TLS termination, host app servers in private subnets, and use managed databases with private endpoints. Scenario B: static marketing site — use object storage (S3/Azure Blob) with CDN (CloudFront/Azure CDN) and an origin access control to avoid making the storage account public. Operational tips: document the VPC/subnet map in your System Security Plan (SSP), perform quarterly access reviews of security groups/NSGs, rotate keys and restrict console access with MFA/roles, and keep automated tests to verify that private subnets do not have a route to IGW. Use IaC templates to produce the same architecture in each environment (dev/stage/prod) so audits examine consistent artifacts.
Compliance tips, best practices and automation
Practical compliance tips: maintain a runbook that demonstrates how public subnet resources are approved and onboarded; require change ticket references in IaC pull requests; tag resources with classification and environment; set CloudWatch/Log Analytics alerts for unusual outbound traffic and failed administrative logins. Enforce least privilege by using security group referencing (allow only ALB SG → app SG) rather than port-wide opens. Automate checks with CIS benchmarks, Terraform Sentinel/OPA policies, or AWS Config rules / Azure Policy to prevent accidental public exposure (e.g., S3 buckets with public access blocked). Keep logs for a period aligned with your contractual obligations and document retention policies in your SSP.
Risk of not implementing the requirement
If you leave public services mixed with private/back-end resources or fail to lock down public subnets, the risks include unauthorized data access, lateral movement after compromise, and inability to demonstrate to auditors that you isolated FCI. For small businesses this can mean loss of contracts, mandatory incident reporting, reputational damage, and fines. From a technical standpoint, improperly configured public IPs, overly-permissive security groups, or missing monitoring make detection of exfiltration slow or impossible.
Summary: segregating internet-facing services into a purpose-built public subnetwork, applying strict ingress/egress rules, using managed load balancers and NAT patterns, enabling logging, and enforcing the design with automation and policy will meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI for small businesses; implement the concrete AWS/Azure steps above, document them in your SSP and runbooks, and automate enforcement to keep exposure minimal and auditable.
