Separation of public and internal networks in AWS is a foundational control for meeting FAR 52.204-21 and CMMC 2.0 Level 1 (Control SC.L1-B.1.XI): it prevents public-facing assets from exposing internal systems that process or store Federal Contract Information (FCI) and reduces the attack surface for contractors. This post gives practical, actionable steps — with specific subnet CIDRs, route table behaviors, security group rules, and operational checks — so a small business can implement the separation correctly, document it for audits, and automate verification.
\n\nFAR 52.204-21 requires basic safeguarding of covered contractor information on contractor systems, and CMMC Level 1 maps to similar basic cyber hygiene. From a network perspective, that means ensuring that systems which must be reachable from the Internet (web front-ends, public APIs) are isolated from systems that store or process sensitive contract data. Without separation, a vulnerable public server can be a pivot point into databases and file stores holding FCI; effective separation demonstrates that the organization is addressing confidentiality and integrity requirements and provides evidence for assessments.
\n\nA common, compliant VPC design for small businesses uses a single VPC (e.g., 10.0.0.0/16) with multiple Availability Zone-aware subnets: public subnets for load balancers and NAT gateways (10.0.1.0/24, 10.0.2.0/24), private application subnets (10.0.10.0/24, 10.0.11.0/24), and isolated database subnets (10.0.20.0/24). Attach an Internet Gateway (IGW) to the VPC and place a 0.0.0.0/0 route in the public route table pointing to the IGW. For private subnets that need outbound internet access for patches, use NAT Gateways in public subnets and route 0.0.0.0/0 from the private route table to the NAT; for databases and strictly internal components, use isolated subnets with no route to the internet. Use VPC endpoints (interface and gateway endpoints) for AWS services like S3 and Systems Manager to avoid routing traffic through the internet when accessing those services.
\n\nExample configuration: VPC 10.0.0.0/16; public-a 10.0.1.0/24, public-b 10.0.2.0/24 (ALB, NAT, bastion); app-a 10.0.10.0/24, app-b 10.0.11.0/24 (EC2 / ECS tasks without public IPs); db-a 10.0.20.0/24 (RDS or managed DB with no public endpoint). Create a public route table: 0.0.0.0/0 -> igw-xxxx. Create a private route table for app subnets: 0.0.0.0/0 -> nat-xxxx. For db/isolated subnets, no 0.0.0.0/0 route (or only VPC-local routes), ensuring no direct internet egress. Disable “Auto-assign public IPv4 address” on private subnets and on instance launch for app/db instances.
\n\nSecurity groups (SGs) are stateful and should be the primary control for instance-level filtering. Use small, purpose-named SGs and reference SG IDs rather than broad CIDRs. Recommended baseline rules: ALB/ALB-SG — allow TCP 80/443 from 0.0.0.0/0 (or restricted IP ranges) to the ALB; App-SG — allow inbound 443 (or app port) only from ALB-SG’s security group ID; DB-SG — allow DB port (e.g., TCP 3306 for MySQL) only from App-SG ID; Bastion-SG — allow SSH 22 from company admin public IP(s) only and deny SSH from anywhere else; Egress — restrict to required destinations (for example, app servers allow outbound to S3 endpoints, package repos, and database). Use NACLs only for broad subnet-level protections such as blocking entire IP ranges; remember NACLs are stateless and require both inbound and outbound rules.
\n\nImagine a small contractor hosting an e-commerce demo with FCI in a private database: deploy an Application Load Balancer in public subnets, place web servers in private app subnets (no public IPs), use an RDS instance in the isolated DB subnet, and allow maintenance via a bastion host in a public subnet with SSH limited to the company's static office IP. Configure S3 VPC Gateway Endpoint for asset storage so uploads/downloads don't traverse the internet. Enforce least privilege on SG edits by creating an IAM role and policy that restricts who can modify security groups and require multi-person approval in change control for SG or subnet changes to produce evidence for assessors.
\n\nImplementation checklist (actionable): 1) Create VPC and subnets per design; 2) Create IGW and NAT gateways in public subnets; 3) Create and associate route tables; 4) Create SGs with restrictive rules referencing SG IDs; 5) Configure VPC endpoints for S3/DynamoDB; 6) Disable public IP auto-assign in private subnets; 7) Enable VPC Flow Logs, CloudTrail, and GuardDuty; 8) Implement AWS Config rules such as vpc-flow-logs-enabled, restricted-common-ports, and s3-bucket-public-read-prohibited; 9) Capture evidence (CloudFormation / Terraform templates, screenshots, Config rule evaluations, and CloudTrail logs) for compliance audits. Automate using Terraform or CloudFormation modules and include security group rules and route tables as code so that the architecture is reproducible and auditable.
\n\nIf public and internal resources are not separated, attackers can exploit public-facing hosts to reach internal systems, increasing the chance of data exfiltration of FCI and loss of confidentiality. Non-compliance can lead to contract penalties, loss of government business, and reputational damage. Compliance tips: document the VPC design in a system security plan (SSP) aligned to FAR/CMMC mapping, maintain a change log of network/security group changes, perform periodic SG rule reviews (every 30–90 days), use automated scanning (AWS Config, CIS benchmark scanners), and require multifactor authentication and IAM least privilege for personnel changing networking controls.
\n\nSummary: For FAR 52.204-21 and CMMC 2.0 Level 1 compliance, implement a clear VPC architecture that separates public-facing components from internal systems, use route tables, NAT, IGW, VPC endpoints, and tightly scoped security groups to enforce that separation, and automate and document everything to provide audit evidence. Following the concrete CIDR, routing, and SG examples above — plus logging, AWS Config rules, and change control — gives a small business a practical, defensible path to meet the network separation control SC.L1-B.1.XI.
", "plain_text": "Separation of public and internal networks in AWS is a foundational control for meeting FAR 52.204-21 and CMMC 2.0 Level 1 (Control SC.L1-B.1.XI): it prevents public-facing assets from exposing internal systems that process or store Federal Contract Information (FCI) and reduces the attack surface for contractors. This post gives practical, actionable steps — with specific subnet CIDRs, route table behaviors, security group rules, and operational checks — so a small business can implement the separation correctly, document it for audits, and automate verification.\n\nWhy separating public and internal networks matters for FAR 52.204-21 / CMMC 2.0\nFAR 52.204-21 requires basic safeguarding of covered contractor information on contractor systems, and CMMC Level 1 maps to similar basic cyber hygiene. From a network perspective, that means ensuring that systems which must be reachable from the Internet (web front-ends, public APIs) are isolated from systems that store or process sensitive contract data. Without separation, a vulnerable public server can be a pivot point into databases and file stores holding FCI; effective separation demonstrates that the organization is addressing confidentiality and integrity requirements and provides evidence for assessments.\n\nDesign pattern: VPC, subnets, route tables, NAT, IGW and endpoints\nA common, compliant VPC design for small businesses uses a single VPC (e.g., 10.0.0.0/16) with multiple Availability Zone-aware subnets: public subnets for load balancers and NAT gateways (10.0.1.0/24, 10.0.2.0/24), private application subnets (10.0.10.0/24, 10.0.11.0/24), and isolated database subnets (10.0.20.0/24). Attach an Internet Gateway (IGW) to the VPC and place a 0.0.0.0/0 route in the public route table pointing to the IGW. For private subnets that need outbound internet access for patches, use NAT Gateways in public subnets and route 0.0.0.0/0 from the private route table to the NAT; for databases and strictly internal components, use isolated subnets with no route to the internet. Use VPC endpoints (interface and gateway endpoints) for AWS services like S3 and Systems Manager to avoid routing traffic through the internet when accessing those services.\n\nConcrete subnet & route example\nExample configuration: VPC 10.0.0.0/16; public-a 10.0.1.0/24, public-b 10.0.2.0/24 (ALB, NAT, bastion); app-a 10.0.10.0/24, app-b 10.0.11.0/24 (EC2 / ECS tasks without public IPs); db-a 10.0.20.0/24 (RDS or managed DB with no public endpoint). Create a public route table: 0.0.0.0/0 -> igw-xxxx. Create a private route table for app subnets: 0.0.0.0/0 -> nat-xxxx. For db/isolated subnets, no 0.0.0.0/0 route (or only VPC-local routes), ensuring no direct internet egress. Disable “Auto-assign public IPv4 address” on private subnets and on instance launch for app/db instances.\n\nSecurity groups and network ACLs: practical rule examples\nSecurity groups (SGs) are stateful and should be the primary control for instance-level filtering. Use small, purpose-named SGs and reference SG IDs rather than broad CIDRs. Recommended baseline rules: ALB/ALB-SG — allow TCP 80/443 from 0.0.0.0/0 (or restricted IP ranges) to the ALB; App-SG — allow inbound 443 (or app port) only from ALB-SG’s security group ID; DB-SG — allow DB port (e.g., TCP 3306 for MySQL) only from App-SG ID; Bastion-SG — allow SSH 22 from company admin public IP(s) only and deny SSH from anywhere else; Egress — restrict to required destinations (for example, app servers allow outbound to S3 endpoints, package repos, and database). Use NACLs only for broad subnet-level protections such as blocking entire IP ranges; remember NACLs are stateless and require both inbound and outbound rules.\n\nSmall business real-world scenario\nImagine a small contractor hosting an e-commerce demo with FCI in a private database: deploy an Application Load Balancer in public subnets, place web servers in private app subnets (no public IPs), use an RDS instance in the isolated DB subnet, and allow maintenance via a bastion host in a public subnet with SSH limited to the company's static office IP. Configure S3 VPC Gateway Endpoint for asset storage so uploads/downloads don't traverse the internet. Enforce least privilege on SG edits by creating an IAM role and policy that restricts who can modify security groups and require multi-person approval in change control for SG or subnet changes to produce evidence for assessors.\n\nImplementation steps, automation, and supporting controls\nImplementation checklist (actionable): 1) Create VPC and subnets per design; 2) Create IGW and NAT gateways in public subnets; 3) Create and associate route tables; 4) Create SGs with restrictive rules referencing SG IDs; 5) Configure VPC endpoints for S3/DynamoDB; 6) Disable public IP auto-assign in private subnets; 7) Enable VPC Flow Logs, CloudTrail, and GuardDuty; 8) Implement AWS Config rules such as vpc-flow-logs-enabled, restricted-common-ports, and s3-bucket-public-read-prohibited; 9) Capture evidence (CloudFormation / Terraform templates, screenshots, Config rule evaluations, and CloudTrail logs) for compliance audits. Automate using Terraform or CloudFormation modules and include security group rules and route tables as code so that the architecture is reproducible and auditable.\n\nRisks of not separating networks and compliance tips\nIf public and internal resources are not separated, attackers can exploit public-facing hosts to reach internal systems, increasing the chance of data exfiltration of FCI and loss of confidentiality. Non-compliance can lead to contract penalties, loss of government business, and reputational damage. Compliance tips: document the VPC design in a system security plan (SSP) aligned to FAR/CMMC mapping, maintain a change log of network/security group changes, perform periodic SG rule reviews (every 30–90 days), use automated scanning (AWS Config, CIS benchmark scanners), and require multifactor authentication and IAM least privilege for personnel changing networking controls.\n\nSummary: For FAR 52.204-21 and CMMC 2.0 Level 1 compliance, implement a clear VPC architecture that separates public-facing components from internal systems, use route tables, NAT, IGW, VPC endpoints, and tightly scoped security groups to enforce that separation, and automate and document everything to provide audit evidence. Following the concrete CIDR, routing, and SG examples above — plus logging, AWS Config rules, and change control — gives a small business a practical, defensible path to meet the network separation control SC.L1-B.1.XI." }, "metadata": { "description": "Step-by-step guidance to configure AWS VPC subnets, route tables, NAT/IGW, and security groups to separate public and internal networks and meet FAR 52.204-21 / CMMC 2.0 Level 1 (SC.L1-B.1.XI).", "permalink": "/how-to-implement-aws-vpc-subnets-and-security-groups-to-separate-public-and-internal-networks-far-52204-21-cmmc-20-level-1-control-scl1-b1xi.json", "categories": [], "tags": [] } }