This post walks through a practical, Terraform-centric approach to implementing AWS subnetworks (public-facing and internal) to satisfy the FAR 52.204-21 / CMMC 2.0 Level 1 control SC.L1-B.1.XI requirement that public-facing systems be logically separated and properly configured, focusing on small-business scenarios, concrete Terraform examples, validation steps, and operational best practices.
\n\nSC.L1-B.1.XI in the context of CMMC 2.0 Level 1 (and the related FAR 52.204-21 basic safeguarding expectations) requires that systems exposed to the public internet be isolated from internal systems and that access be controlled and auditable. In AWS this is typically implemented using a VPC with segregated public and private subnets, an Internet Gateway (IGW) attached only to public subnets via route tables, NAT Gateway(s) for private-subnet egress, security groups and Network ACLs (NACLs) enforcing least-privilege, and limited management access paths (for example, SSM Session Manager instead of direct SSH/RDP from the internet).
\n\nFor a small business hosting a customer portal and a back-end database, adopt a three-tier minimal pattern: public subnets for load balancers or NAT-proxy endpoints, private application subnets for API servers, and private data subnets for databases. Static assets should be served via S3 + CloudFront where possible to minimize public compute exposure. Use an Application Load Balancer (ALB) in public subnets to terminate TLS, apply AWS WAF for basic layer-7 protections, and keep RDS and other data stores in private subnets with no direct internet route. This separation meets the key objective of isolating public-facing services while allowing controlled egress and management.
\n\nBelow is a minimal Terraform snippet demonstrating the core pieces: VPC, public/private subnet, Internet Gateway, route table association, and a security group that limits public traffic to HTTPS. Use this as a scaffold — expand subnets across AZs and add NAT Gateway(s) for production.
\n\nresource \"aws_vpc\" \"main\" {\n cidr_block = \"10.0.0.0/16\"\n tags = { Name = \"sbx-vpc\" }\n}\n\nresource \"aws_subnet\" \"public_a\" {\n vpc_id = aws_vpc.main.id\n cidr_block = \"10.0.1.0/24\"\n availability_zone = \"us-east-1a\"\n map_public_ip_on_launch = true\n tags = { Name = \"sbx-public-a\" }\n}\n\nresource \"aws_subnet\" \"private_a\" {\n vpc_id = aws_vpc.main.id\n cidr_block = \"10.0.2.0/24\"\n availability_zone = \"us-east-1a\"\n tags = { Name = \"sbx-private-a\" }\n}\n\nresource \"aws_internet_gateway\" \"igw\" {\n vpc_id = aws_vpc.main.id\n tags = { Name = \"sbx-igw\" }\n}\n\nresource \"aws_route_table\" \"public_rt\" {\n vpc_id = aws_vpc.main.id\n route { cidr_block = \"0.0.0.0/0\", gateway_id = aws_internet_gateway.igw.id }\n tags = { Name = \"sbx-public-rt\" }\n}\n\nresource \"aws_route_table_association\" \"public_assoc\" {\n subnet_id = aws_subnet.public_a.id\n route_table_id = aws_route_table.public_rt.id\n}\n\nresource \"aws_security_group\" \"web_sg\" {\n name = \"sbx-web-sg\"\n vpc_id = aws_vpc.main.id\n ingress {\n description = \"HTTPS\"\n from_port = 443\n to_port = 443\n protocol = \"tcp\"\n cidr_blocks = [\"0.0.0.0/0\"]\n }\n egress { from_port = 0; to_port = 0; protocol = \"-1\"; cidr_blocks = [\"0.0.0.0/0\"] }\n tags = { Name = \"sbx-web-sg\" }\n}\nKey implementation notes: (1) set map_public_ip_on_launch only for public subnets so instances receive public IPs when needed; (2) put ALBs in public subnets, EC2/RDS in private subnets; (3) use NAT Gateway(s) in the public subnet for private-subnet egress during OS/agent updates — ensure NAT Gateway is in a highly available setup for production; (4) enforce least-privileged security-group rules (only 443/80 or specific management ports from tightly-scoped IP ranges); and (5) avoid opening port 22/3389 to 0.0.0.0/0 — prefer SSM Session Manager and IAM roles for management.
\n\nFor compliance evidence, capture Terraform plan/apply logs, maintain git history of Terraform code, and export resource identifiers and configuration JSON for auditors. Implement AWS Config rules to check “publicly accessible” flags (for example, “rds-public-access-check”, “s3-bucket-public-read-prohibited”), enable VPC Flow Logs for public subnets and flow log aggregation to a centralized S3 bucket or CloudWatch Logs, and enable CloudTrail to record API activity. Use automated tests (Terratest or InSpec) as part of CI to assert that public-facing subnets are limited to ALB/IGW routes only, that RDS is private, and that no EC2 instances in private subnets have public IPs. These outputs form the basis of an audit package for FAR/CMMC reviewers.
\n\nOperationalize the controls with these practices: (1) enforce infrastructure-as-code (Terraform) with code review and branch protection so network changes are auditable; (2) tag resources consistently to link environment, owner, and control mappings (e.g., tag \"cmmc_level=1\" or \"control=SC.L1-B.1.XI\"); (3) implement drift detection using terraform plan in CI and AWS Config rules; (4) restrict who can modify networking via IAM IAM policies and use AWS Organizations SCPs if you have multiple accounts; and (5) enable MFA and session recording for console/API access to create an evidentiary trail.
\n\nFailing to properly isolate public-facing systems risks unauthorized access to internal resources, lateral movement after compromise, data exfiltration of Controlled Unclassified Information (CUI), and failing FAR/CMMC assessment criteria — which can lead to contract termination, loss of future government work, and reputational / financial damage for a small business. Additionally, unsegmented networks make incident response slower and increase blast radius for malware or misconfigurations.
\n\nIn summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI for public-facing systems on AWS is achievable for small businesses by designing a clear public/private subnet topology, enforcing least-privilege access controls, using Terraform for repeatable, auditable deployments, and collecting the right logs and evidence (Terraform state/plans, AWS Config, VPC Flow Logs, CloudTrail). Apply the Terraform scaffolding above, expand it for HA and multi-AZ production, adopt SSM for management, and bake automated validation into CI/CD to maintain continuous compliance and reduce the risk of costly noncompliance.
", "plain_text": "This post walks through a practical, Terraform-centric approach to implementing AWS subnetworks (public-facing and internal) to satisfy the FAR 52.204-21 / CMMC 2.0 Level 1 control SC.L1-B.1.XI requirement that public-facing systems be logically separated and properly configured, focusing on small-business scenarios, concrete Terraform examples, validation steps, and operational best practices.\n\nImplementation overview — how the control maps to AWS networking\nSC.L1-B.1.XI in the context of CMMC 2.0 Level 1 (and the related FAR 52.204-21 basic safeguarding expectations) requires that systems exposed to the public internet be isolated from internal systems and that access be controlled and auditable. In AWS this is typically implemented using a VPC with segregated public and private subnets, an Internet Gateway (IGW) attached only to public subnets via route tables, NAT Gateway(s) for private-subnet egress, security groups and Network ACLs (NACLs) enforcing least-privilege, and limited management access paths (for example, SSM Session Manager instead of direct SSH/RDP from the internet).\n\nDesign patterns and small-business scenario\nFor a small business hosting a customer portal and a back-end database, adopt a three-tier minimal pattern: public subnets for load balancers or NAT-proxy endpoints, private application subnets for API servers, and private data subnets for databases. Static assets should be served via S3 + CloudFront where possible to minimize public compute exposure. Use an Application Load Balancer (ALB) in public subnets to terminate TLS, apply AWS WAF for basic layer-7 protections, and keep RDS and other data stores in private subnets with no direct internet route. This separation meets the key objective of isolating public-facing services while allowing controlled egress and management.\n\nConcrete Terraform implementation example\nBelow is a minimal Terraform snippet demonstrating the core pieces: VPC, public/private subnet, Internet Gateway, route table association, and a security group that limits public traffic to HTTPS. Use this as a scaffold — expand subnets across AZs and add NAT Gateway(s) for production.\n\nresource \"aws_vpc\" \"main\" {\n cidr_block = \"10.0.0.0/16\"\n tags = { Name = \"sbx-vpc\" }\n}\n\nresource \"aws_subnet\" \"public_a\" {\n vpc_id = aws_vpc.main.id\n cidr_block = \"10.0.1.0/24\"\n availability_zone = \"us-east-1a\"\n map_public_ip_on_launch = true\n tags = { Name = \"sbx-public-a\" }\n}\n\nresource \"aws_subnet\" \"private_a\" {\n vpc_id = aws_vpc.main.id\n cidr_block = \"10.0.2.0/24\"\n availability_zone = \"us-east-1a\"\n tags = { Name = \"sbx-private-a\" }\n}\n\nresource \"aws_internet_gateway\" \"igw\" {\n vpc_id = aws_vpc.main.id\n tags = { Name = \"sbx-igw\" }\n}\n\nresource \"aws_route_table\" \"public_rt\" {\n vpc_id = aws_vpc.main.id\n route { cidr_block = \"0.0.0.0/0\", gateway_id = aws_internet_gateway.igw.id }\n tags = { Name = \"sbx-public-rt\" }\n}\n\nresource \"aws_route_table_association\" \"public_assoc\" {\n subnet_id = aws_subnet.public_a.id\n route_table_id = aws_route_table.public_rt.id\n}\n\nresource \"aws_security_group\" \"web_sg\" {\n name = \"sbx-web-sg\"\n vpc_id = aws_vpc.main.id\n ingress {\n description = \"HTTPS\"\n from_port = 443\n to_port = 443\n protocol = \"tcp\"\n cidr_blocks = [\"0.0.0.0/0\"]\n }\n egress { from_port = 0; to_port = 0; protocol = \"-1\"; cidr_blocks = [\"0.0.0.0/0\"] }\n tags = { Name = \"sbx-web-sg\" }\n}\n\n\nKey implementation notes: (1) set map_public_ip_on_launch only for public subnets so instances receive public IPs when needed; (2) put ALBs in public subnets, EC2/RDS in private subnets; (3) use NAT Gateway(s) in the public subnet for private-subnet egress during OS/agent updates — ensure NAT Gateway is in a highly available setup for production; (4) enforce least-privileged security-group rules (only 443/80 or specific management ports from tightly-scoped IP ranges); and (5) avoid opening port 22/3389 to 0.0.0.0/0 — prefer SSM Session Manager and IAM roles for management.\n\nValidation, evidence, and monitoring\nFor compliance evidence, capture Terraform plan/apply logs, maintain git history of Terraform code, and export resource identifiers and configuration JSON for auditors. Implement AWS Config rules to check “publicly accessible” flags (for example, “rds-public-access-check”, “s3-bucket-public-read-prohibited”), enable VPC Flow Logs for public subnets and flow log aggregation to a centralized S3 bucket or CloudWatch Logs, and enable CloudTrail to record API activity. Use automated tests (Terratest or InSpec) as part of CI to assert that public-facing subnets are limited to ALB/IGW routes only, that RDS is private, and that no EC2 instances in private subnets have public IPs. These outputs form the basis of an audit package for FAR/CMMC reviewers.\n\nCompliance tips and best practices\nOperationalize the controls with these practices: (1) enforce infrastructure-as-code (Terraform) with code review and branch protection so network changes are auditable; (2) tag resources consistently to link environment, owner, and control mappings (e.g., tag \"cmmc_level=1\" or \"control=SC.L1-B.1.XI\"); (3) implement drift detection using terraform plan in CI and AWS Config rules; (4) restrict who can modify networking via IAM IAM policies and use AWS Organizations SCPs if you have multiple accounts; and (5) enable MFA and session recording for console/API access to create an evidentiary trail.\n\nRisk of not implementing network separation and controls\nFailing to properly isolate public-facing systems risks unauthorized access to internal resources, lateral movement after compromise, data exfiltration of Controlled Unclassified Information (CUI), and failing FAR/CMMC assessment criteria — which can lead to contract termination, loss of future government work, and reputational / financial damage for a small business. Additionally, unsegmented networks make incident response slower and increase blast radius for malware or misconfigurations.\n\nIn summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI for public-facing systems on AWS is achievable for small businesses by designing a clear public/private subnet topology, enforcing least-privilege access controls, using Terraform for repeatable, auditable deployments, and collecting the right logs and evidence (Terraform state/plans, AWS Config, VPC Flow Logs, CloudTrail). Apply the Terraform scaffolding above, expand it for HA and multi-AZ production, adopt SSM for management, and bake automated validation into CI/CD to maintain continuous compliance and reduce the risk of costly noncompliance." }, "metadata": { "description": "Step-by-step guidance to design and deploy AWS public and private subnetworks with Terraform to meet FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI requirements while maintaining practical security controls.", "permalink": "/how-to-implement-aws-subnetworks-for-public-facing-systems-to-satisfy-far-52204-21-cmmc-20-level-1-control-scl1-b1xi-terraform-and-best-practices.json", "categories": [], "tags": [] } }