This post explains how to design and implement subnetworks (subnets) in AWS and Azure to host publicly accessible system components while meeting the intent of FAR 52.204-21 and CMMC 2.0 Level 1 control SC.L1-B.1.XI — separating public-facing services from internal resources and producing evidence that the separation and controls exist.
Overview — Compliance objectives and practical approach
The core compliance objective for FAR 52.204-21 and CMMC SC.L1-B.1.XI is to limit exposure of controlled and sensitive information by isolating public-facing resources (web servers, API gateways, load balancers) in tightly controlled network segments, while keeping internal services (databases, management interfaces) in private segments with restricted access and monitoring. Practically this means: create dedicated public subnets for components that must accept internet traffic; route those subnets to an Internet Gateway (AWS) or public IP / route table (Azure); place application servers, data stores, management tools in private subnets with no direct inbound internet route; and enforce traffic flows with Security Groups/NSGs, route tables, NACLs, and firewalls. Document the design and collect evidence (architecture diagrams, subnet IDs, SG/NSG rules, flow logs) to demonstrate compliance during an assessment.
AWS implementation
Design considerations
Start with a clear VPC CIDR plan (for example VPC: 10.0.0.0/16). Reserve public subnets for internet-facing components (e.g., 10.0.1.0/24, 10.0.3.0/24 across AZs) and private subnets for app and data (e.g., 10.0.2.0/24, 10.0.4.0/24). Attach an Internet Gateway (IGW) to the VPC and associate public subnets' route tables to route 0.0.0.0/0 → IGW. Use NAT Gateways in the public subnet to allow private subnets outbound internet access for updates without inbound connectivity. Put load balancers (ALB/NLB) in public subnets, target application servers in private subnets, and place databases (RDS) in private-only subnets. Enforce least privilege on security groups: allow only necessary ports (e.g., ALB SG inbound TCP 443 from 0.0.0.0/0; app servers SG inbound TCP 443 from ALB SG only; DB SG inbound from app SG on DB port only). Use VPC Flow Logs to capture traffic, and ship logs to CloudWatch Logs or S3 as evidence.
Step-by-step (actionable)
1) Create VPC and subnets with explicit CIDR plan. 2) Create an IGW and attach it; create a route table for public subnets with 0.0.0.0/0 → IGW. 3) Create NAT Gateway(s) in public subnets and route private subnets' 0.0.0.0/0 → NAT. 4) Deploy ALB in public subnets, with listeners for needed ports (HTTPS) and TLS certificates managed via ACM. 5) Launch application instances (or ECS/EKS tasks) in private subnets and register with ALB target groups. 6) Harden management: avoid direct SSH/RDP to public instances; use AWS Systems Manager Session Manager or a small bastion in a tightly configured public subnet with SG limited to specific admin IPs and MFA-backed authentication. 7) Configure Security Groups and, optionally, NACLs for defense-in-depth; use explicit deny patterns where appropriate. 8) Enable VPC Flow Logs, AWS Config rules for network ACL/SG drift, and CloudTrail for API changes. For evidence produce: VPC/subnet IDs, route table entries, security group rule screenshots/exports, flow log records showing allowed/denied traffic, and architecture diagram showing public/private separation.
Azure implementation
Design considerations
Azure uses VNets and subnets with the same segregation principle. Example CIDR: VNet 10.1.0.0/16, public subnets 10.1.1.0/24 (for public-facing components), private app/data subnets 10.1.2.0/24, 10.1.3.0/24. Place Azure Load Balancer or Application Gateway (with a WAF if needed) in the public subnet with public IPs, and put app services, VMs or AKS nodes in private subnets. Use Azure NAT Gateway for outbound connectivity from private subnets. Protect management access using Azure Bastion or Just-In-Time VM Access via Azure Security Center, and apply Network Security Groups (NSGs) on subnets and NICs to restrict traffic. Use Azure Firewall or third-party appliances as a centralized east-west/east-north security boundary if your environment requires more controls. Enable NSG flow logs and Azure Monitor diagnostic logs for evidence collection.
Step-by-step (actionable)
1) Create VNet and subnets with consistent CIDR allocations. 2) Deploy an Application Gateway (or Azure Front Door for global scale) in the public subnet and attach a public IP. 3) Configure route tables so only the public subnet has a route to the internet; private subnets should route outbound through a NAT Gateway in a public subnet if they need updates. 4) Apply NSGs: allow inbound HTTP/HTTPS to the Application Gateway from Internet, allow only the gateway or load balancer to reach backend pools, and restrict DB subnets to accept traffic only from app subnets. 5) Configure Azure Bastion or JIT for admin access; avoid public IPs on management VMs. 6) Turn on NSG Flow Logs, Azure Activity Logs, and retain logs per your retention policy to demonstrate controls. 7) Record resource IDs, routing tables, NSG rules, and sample logs as artifacts for compliance review.
Compliance tips and best practices
Automate the design with IaC (Terraform, CloudFormation, ARM/Bicep) so network architecture is versioned and reproducible; include output artifacts (subnet IDs, SG/NSG rules) in deployment records. Maintain an architecture diagram with public/private distinctions and update it when changes are requested; tie change requests to approved configuration changes in your CMDB. Use least-privilege rules for inbound/outbound traffic, centralize TLS termination at the load balancer to manage certificates securely, and use managed services for databases to reduce attack surface. Implement logging and retention policies (e.g., 90–365 days depending on contract) and periodically audit rules with automated scanners (AWS Config/Azure Policy, custom scripts). For small businesses, leverage managed solutions (AWS ALB + RDS, Azure App Service + Azure SQL) to reduce operational overhead while still isolating public endpoints in controlled subnets.
Risks of not implementing subnet separation
Failing to separate publicly accessible components from internal resources increases the risk of lateral movement after a breach, accidental data exposure of contractor information, and non-compliance findings. A compromised web server in an unsegmented network can be used to pivot to databases or management consoles; lack of flow logs and documented subnet configurations makes it difficult to show assessors that you applied required safeguards under FAR and CMMC. Operationally, you also face higher remediation costs, potential contract penalties (for government contractors), and reputational damage.
In summary, implementing subnetworks for public-facing components in AWS and Azure is a straightforward, high-impact control to meet FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI: design clear public/private CIDR plans, use IGW/NAT or Azure equivalents, enforce access with Security Groups/NSGs and centralized load balancers, enable logging (VPC Flow Logs/NSG Flow Logs) and automation via IaC, and collect architecture and log evidence to demonstrate compliance. For small businesses, using managed platform services and automation will reduce complexity while meeting the control’s intent.
