This post gives actionable instructions for designing and deploying public subnets in AWS and Azure that meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 Control SC.L1-B.1.XI: provide controlled, justified public network access while protecting Covered Defense Information (CDI) and other controlled data. It focuses on practical steps, sample configurations, small-business scenarios, monitoring and evidence you can present to an assessor.
Understanding the control and key objectives
The Compliance Framework objective for SC.L1-B.1.XI is to ensure system connections to external networks are intentional, limited, and monitored so that sensitive or controlled information is not inadvertently exposed. For a small business this means: (1) only place workloads in a public subnet when they must directly accept inbound internet connections; (2) use perimeter controls (WAF, security groups/NSGs, ALBs) to filter traffic; and (3) capture configuration and network logs as evidence of protection. Implementation notes include documenting the business justification for each public IP or publicly routable service and demonstrating that controls are in place to limit access.
AWS: how to build a compliant public subnet
Core components for a compliant AWS public subnet are: a VPC, one or more public subnets mapped to AZs, an Internet Gateway (IGW) attached to the VPC, a Route Table with 0.0.0.0/0 routed to the IGW, explicit Security Group rules, and VPC Flow Logs for monitoring. Use these steps: (1) create a VPC with a CIDR (for small businesses 10.0.0.0/16 is common); (2) create a public subnet (e.g., 10.0.1.0/24) and enable "auto-assign public IPv4" for the subnet if you want EC2 to get public IPs; (3) attach an IGW and add a route in the subnet's route table to 0.0.0.0/0 -> igw-xxxx; (4) create Security Groups that whitelist only required inbound ports (e.g., 80/443 for web) and use NACLs only when you need stateless filtering across the subnet boundary; (5) enable VPC Flow Logs to an S3 bucket or CloudWatch Logs with retention policy aligned to your evidence retention (90 days is a common baseline for Level 1); (6) front public workloads with an ALB and WAF where possible to centralize filtering and logging, and place application servers in private subnets behind the ALB.
Example AWS considerations and commands: create a NAT Gateway (in the public subnet) to allow private instances outbound internet access while keeping them private, and prefer AWS Systems Manager Session Manager for administrative access instead of opening SSH/RDP. Sample IAM and Security Group evidence will show least-privilege rules (e.g., only 443/tcp from 0.0.0.0/0 to the ALB; backend SG allowing 443 only from the ALB SG). Demonstrate CloudTrail, VPC Flow Logs, and ALB access logs in your compliance artefacts.
Azure: how to build a compliant public subnet
In Azure the equivalent components are: a Virtual Network (VNet), subnets marked for public-facing resources, Public IP addresses assigned to NICs or Load Balancers, Network Security Groups (NSGs) attached to subnets or NICs, Azure Firewall or NAT Gateway for controlled outbound, and Diagnostic Logs (Network Watcher NSG flow logs, Azure Monitor) for auditing. Steps: (1) create a VNet (e.g., 10.1.0.0/16) and a public subnet (10.1.1.0/24); (2) deploy an Azure Load Balancer or Application Gateway with a public IP to front services; (3) attach NSGs to the subnet/NIC and explicitly allow only necessary inbound ports; (4) if backend VMs need outbound internet, use a NAT Gateway placed in the public subnet or use Azure Firewall to centralize outbound filtering; (5) enable NSG Flow Logs to Log Analytics and retain logs per your retention policy; (6) use Azure Bastion or Azure AD + Just-in-Time access (via Azure Security Center) rather than exposing management ports.
Practical Azure tips: prefer Application Gateway with WAF to exposing web servers directly; use Private Endpoints/Service Endpoints for PaaS resources so you avoid placing them in public subnets; record ARM/terraform templates as evidence of the intended network design; leverage Azure Policy to prevent creation of public IPs without tags and documented justification.
Small-business scenarios and real-world examples
Example 1: a small defense contractor hosts a customer-facing portal. Put the ALB/Application Gateway in a public subnet and keep the web app servers in private subnets. Justify the public subnet in documentation, restrict inbound traffic to 443, enable WAF, and retain access and flow logs. Example 2: you need a third-party SFTP for vendor deliveries. Instead of placing SFTP servers in a public subnet, use a public-facing managed service (SFTP on S3 Transfer Family or Azure Blob SFTP) or host an SFTP gateway in a public subnet but restrict source IP ranges, use MFA for admin access, and log sessions. Example 3: developer test VMs — avoid giving them public IPs; use SSM/Session Manager or Azure Bastion so the public subnet doesn’t grow with unmanaged endpoints.
Compliance tips, evidence and best practices
Document a risk-based justification for each public subnet and public IP address, include that documentation in your System Security Plan (SSP), and attach change-control tickets to any public exposure changes. Maintain IaC templates (Terraform/ARM) in version control as configuration evidence. Enable and retain CloudTrail/Activity Log, VPC Flow Logs/NSG flow logs, ALB/Application Gateway logs, and show that logs are reviewed or sent to a SIEM/Log Analytics workspace. Restrict and review Security Group/NSG rules quarterly, and implement least privilege for IAM and RBAC roles. During assessment, provide network diagrams, route tables, security rule snapshots, and log retention policies as artifacts.
Risks of not implementing the requirement
If public subnets are misconfigured or overused you increase the attack surface: exposed management ports, data exfiltration paths, and unmonitored internet-facing services that could host or leak CDI. Non-compliance can lead to lost contracts, corrective action plans, and reputational damage. Practically, an exposed admin port or missing flow logs means you cannot demonstrate control or detect intrusions—both are red flags for FAR and CMMC assessors.
In summary, building compliant public subnets in AWS and Azure requires minimizing public exposure, applying perimeter controls (ALB/WAF, Security Groups/NSGs, Firewalls), enabling robust logging and retention, and maintaining documentation and IaC as evidence. For small businesses, lean towards managed front doors (ALB/Application Gateway), use NAT for private outbound, adopt session-manager/Bastion for admin access, and keep a tight change-control and review cadence to satisfy FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI.
