This post provides step-by-step, practical guidance for configuring AWS VPC subnetworks to host public-facing systems while meeting the intent of FAR 52.204-21 and CMMC 2.0 Level 1 control SC.L1-B.1.XI—separating public traffic from internal systems and restricting inbound access to authorized protocols and ports.
\n\nThe core objective for FAR 52.204-21 and CMMC SC.L1-B.1.XI in this context is to ensure public-facing systems are logically and operationally separated from internal networks and that inbound access is limited to only the protocols and ports required for the service. For implementation, that means you must demonstrate a consistent network architecture, documented configuration, and evidence that only authorized traffic reaches internal resources.
\n\nA standard, auditable pattern is: place load balancers (ALB/NLB) in public subnets that have a route to an Internet Gateway (IGW); place application servers and databases in private subnets that do not have public IPs and route outbound traffic through NAT Gateways in public subnets. Use security groups so the ALB is the only component accepting 0.0.0.0/0 traffic on ports 80 and 443, and configure application security groups to accept traffic only from the ALB security group. This pattern enforces separation and reduces blast radius.
\n\nTechnically implement the pattern by creating two or more AZ-spread public subnets and two or more private subnets. Attach an Internet Gateway to the VPC and create a public route table that routes 0.0.0.0/0 to the IGW; associate that route table with public subnets. Create a NAT Gateway (with an Elastic IP) in a public subnet and configure a private route table that routes 0.0.0.0/0 to the NAT Gateway for private subnets. Ensure map_public_ip_on_launch is true for public subnets (for ALBs you typically do not need instance public IPs) and false for private subnets (application and database instances should never have public IPs). Name and tag resources consistently to make evidence collection straightforward (for example: vpc-prod, rt-public, rt-private-app, natgw-prod-1).
\n\nImplement security groups and NACLs defensively: ALB SG allows inbound TCP 80/443 from 0.0.0.0/0 and outbound to the application SG on application ports (for example 8080). Application SG only allows inbound from the ALB SG and outbound to database SG on DB ports (for example TCP 5432). Database SG only allows inbound from application SG. Avoid overly permissive rules like 0.0.0.0/0 for management ports; if SSH/RDP is needed for troubleshooting, restrict it to a single admin IP or a dedicated bastion host in a management subnet. Consider stateless Network ACLs to block common malicious ports at the subnet boundary but rely primarily on security groups for east-west controls.
\n\nFor enforcement and automation, codify the design in Infrastructure-as-Code (CloudFormation or Terraform) and deploy AWS Config rules to continuously check for deviations. Useful managed Config rules include vpc-default-security-group-closed, restricted-common-ports, and ec2-instance-no-public-ip. Enable AWS CloudTrail, VPC Flow Logs (sent to an S3 bucket or CloudWatch Logs with appropriate retention and encryption), and an automated evidence snapshot that captures route tables, subnet attributes (map_public_ip_on_launch), security group rules, and NAT/IGW attachments on a scheduled cadence for audit artifacts.
\n\nSmall business scenario: imagine a company runs an e-commerce storefront and an internal admin dashboard. Place the storefront's ALB in public subnets and the storefront application instances in private subnets behind the ALB; the admin dashboard should be in a different private subnetwork with access restricted to the corporate office IP range or VPN. Use an Application Load Balancer with AWS WAF in front of the public endpoints to block common web threats and reduce the risk of exploitation. Do not assign public IPs to app or admin EC2 instances—instead, use a bastion host or AWS Systems Manager Session Manager (recommended) for administrative access. This keeps public and internal surfaces separated and defensible while meeting compliance intent.
\n\nThe risk of not implementing these controls includes increased exposure to internet-borne attacks, unauthorized lateral movement into internal systems, potential loss or exfiltration of controlled unclassified information (CUI), and noncompliance with FAR and CMMC requirements. For contractors, noncompliance could result in contract penalties, loss of contract eligibility, and reputational damage. From an operational perspective, poorly segregated networks also increase incident response complexity and recovery time.
\n\nCompliance tips and best practices include: maintain a documented network diagram that maps public/private subnets to route tables and security groups; retain configuration snapshots and VPC Flow Logs for at least the retention period required by your contract; implement least-privilege security group rules and avoid CIDR 0.0.0.0/0 except where explicitly needed (for the ALB); use SSM Session Manager to avoid exposing SSH/RDP; automate evidence collection with Config rules and a periodic IAM-privileged report; and use tags and naming conventions so auditors can quickly verify which subnets and resources are public-facing vs internal. Finally, perform periodic penetration testing or vulnerability scans of the public-facing endpoints and document remediation actions as part of your compliance file.
\n\nIn summary, meeting FAR 52.204-21 and CMMC SC.L1-B.1.XI for public-facing systems on AWS requires a repeatable VPC architecture that separates public and private subnets, tightly restricts inbound traffic using security groups and route tables, avoids public IPs on internal resources, and produces auditable evidence via logging and automated configuration checks. By codifying the pattern in IaC, enabling AWS Config and logging, and following the least-privilege principle, small businesses can effectively reduce risk and demonstrate compliance during audits.
", "plain_text": "This post provides step-by-step, practical guidance for configuring AWS VPC subnetworks to host public-facing systems while meeting the intent of FAR 52.204-21 and CMMC 2.0 Level 1 control SC.L1-B.1.XI—separating public traffic from internal systems and restricting inbound access to authorized protocols and ports.\n\nUnderstanding the Compliance Objective\nThe core objective for FAR 52.204-21 and CMMC SC.L1-B.1.XI in this context is to ensure public-facing systems are logically and operationally separated from internal networks and that inbound access is limited to only the protocols and ports required for the service. For implementation, that means you must demonstrate a consistent network architecture, documented configuration, and evidence that only authorized traffic reaches internal resources.\n\nRecommended VPC Architecture Pattern\nA standard, auditable pattern is: place load balancers (ALB/NLB) in public subnets that have a route to an Internet Gateway (IGW); place application servers and databases in private subnets that do not have public IPs and route outbound traffic through NAT Gateways in public subnets. Use security groups so the ALB is the only component accepting 0.0.0.0/0 traffic on ports 80 and 443, and configure application security groups to accept traffic only from the ALB security group. This pattern enforces separation and reduces blast radius.\n\nConcrete AWS Configuration Steps\nTechnically implement the pattern by creating two or more AZ-spread public subnets and two or more private subnets. Attach an Internet Gateway to the VPC and create a public route table that routes 0.0.0.0/0 to the IGW; associate that route table with public subnets. Create a NAT Gateway (with an Elastic IP) in a public subnet and configure a private route table that routes 0.0.0.0/0 to the NAT Gateway for private subnets. Ensure map_public_ip_on_launch is true for public subnets (for ALBs you typically do not need instance public IPs) and false for private subnets (application and database instances should never have public IPs). Name and tag resources consistently to make evidence collection straightforward (for example: vpc-prod, rt-public, rt-private-app, natgw-prod-1).\n\nImplement security groups and NACLs defensively: ALB SG allows inbound TCP 80/443 from 0.0.0.0/0 and outbound to the application SG on application ports (for example 8080). Application SG only allows inbound from the ALB SG and outbound to database SG on DB ports (for example TCP 5432). Database SG only allows inbound from application SG. Avoid overly permissive rules like 0.0.0.0/0 for management ports; if SSH/RDP is needed for troubleshooting, restrict it to a single admin IP or a dedicated bastion host in a management subnet. Consider stateless Network ACLs to block common malicious ports at the subnet boundary but rely primarily on security groups for east-west controls.\n\nFor enforcement and automation, codify the design in Infrastructure-as-Code (CloudFormation or Terraform) and deploy AWS Config rules to continuously check for deviations. Useful managed Config rules include vpc-default-security-group-closed, restricted-common-ports, and ec2-instance-no-public-ip. Enable AWS CloudTrail, VPC Flow Logs (sent to an S3 bucket or CloudWatch Logs with appropriate retention and encryption), and an automated evidence snapshot that captures route tables, subnet attributes (map_public_ip_on_launch), security group rules, and NAT/IGW attachments on a scheduled cadence for audit artifacts.\n\nSmall business scenario: imagine a company runs an e-commerce storefront and an internal admin dashboard. Place the storefront's ALB in public subnets and the storefront application instances in private subnets behind the ALB; the admin dashboard should be in a different private subnetwork with access restricted to the corporate office IP range or VPN. Use an Application Load Balancer with AWS WAF in front of the public endpoints to block common web threats and reduce the risk of exploitation. Do not assign public IPs to app or admin EC2 instances—instead, use a bastion host or AWS Systems Manager Session Manager (recommended) for administrative access. This keeps public and internal surfaces separated and defensible while meeting compliance intent.\n\nThe risk of not implementing these controls includes increased exposure to internet-borne attacks, unauthorized lateral movement into internal systems, potential loss or exfiltration of controlled unclassified information (CUI), and noncompliance with FAR and CMMC requirements. For contractors, noncompliance could result in contract penalties, loss of contract eligibility, and reputational damage. From an operational perspective, poorly segregated networks also increase incident response complexity and recovery time.\n\nCompliance tips and best practices include: maintain a documented network diagram that maps public/private subnets to route tables and security groups; retain configuration snapshots and VPC Flow Logs for at least the retention period required by your contract; implement least-privilege security group rules and avoid CIDR 0.0.0.0/0 except where explicitly needed (for the ALB); use SSM Session Manager to avoid exposing SSH/RDP; automate evidence collection with Config rules and a periodic IAM-privileged report; and use tags and naming conventions so auditors can quickly verify which subnets and resources are public-facing vs internal. Finally, perform periodic penetration testing or vulnerability scans of the public-facing endpoints and document remediation actions as part of your compliance file.\n\nIn summary, meeting FAR 52.204-21 and CMMC SC.L1-B.1.XI for public-facing systems on AWS requires a repeatable VPC architecture that separates public and private subnets, tightly restricts inbound traffic using security groups and route tables, avoids public IPs on internal resources, and produces auditable evidence via logging and automated configuration checks. By codifying the pattern in IaC, enabling AWS Config and logging, and following the least-privilege principle, small businesses can effectively reduce risk and demonstrate compliance during audits." }, "metadata": { "description": "Practical step-by-step guidance for designing AWS VPC subnetworks so public-facing systems are isolated and access is restricted to meet FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI requirements.", "permalink": "/how-to-configure-aws-vpc-subnetworks-for-public-facing-systems-to-comply-with-far-52204-21-cmmc-20-level-1-control-scl1-b1xi.json", "categories": [], "tags": [] } }