This post explains how to design AWS VPC subnets and security groups to meet the intent of FAR 52.204-21 and the CMMC 2.0 Level 1 control SC.L1-B.1.XI by implementing network separation, least-privilege access, and auditable controls—providing practical steps, example configs, and small-business scenarios you can implement today.
\n\nAt a high level, the Compliance Framework expects contractors to protect Federal Contract Information (FCI) and basic CUI handling by limiting network exposure, segregating public-facing and internal resources, and controlling inbound/outbound flows. Your VPC should implement a tiered network: public subnets for load balancers and bastion endpoints (if used), private subnets for application servers, and isolated subnets for databases and backups. Route tables, NAT gateways, and VPC endpoints should be used to keep private resources from direct Internet exposure while still allowing necessary outbound access for updates and APIs.
\n\nUse clear CIDR planning (for a small business a single VPC such as 10.0.0.0/16 is typical) and split into smaller subnets per Availability Zone (AZ) for resiliency, e.g., public subnets 10.0.0.0/24 and 10.0.2.0/24, private app subnets 10.0.1.0/24 and 10.0.3.0/24, and database subnets 10.0.4.0/26 per AZ. Attach an Internet Gateway (IGW) only to the route tables for the public subnets. For private subnets, route Internet-bound traffic through a NAT Gateway deployed in the public subnet to avoid public IP assignment to private instances. If your systems interact with AWS services (S3, Secrets Manager) for backups or configuration, create VPC endpoints (Gateway/Interface) to avoid egress to the public Internet and reduce the attack surface.
\n\nSecurity Groups (SGs) are stateful and should be your primary mechanism for host-to-host access control. Adopt these patterns: 1) default-deny inbound (no 0.0.0.0/0 except where explicitly required), 2) allow only required ports—e.g., ALB -> app on 80/443 or app-specific ports, app -> db on database port (e.g., 5432 for Postgres) using SG references rather than CIDR, and 3) restrict outbound traffic where appropriate (do not leave egress wide-open if endpoints/processes don't need it). Use SG references so the application SG is the only allowed source for the DB SG (source = sg-application) rather than opening the DB to a CIDR block.
\n\nBelow are short examples you can adapt. CLI to create a security group and allow application SG to reach DB port:
\n# Create a security group for the app\naws ec2 create-security-group --group-name app-sg --description \"App servers\" --vpc-id vpc-01234567\n\n# Create a security group for the DB\naws ec2 create-security-group --group-name db-sg --description \"Database servers\" --vpc-id vpc-01234567\n\n# Allow app-sg to access PostgreSQL on db-sg (replace IDs)\naws ec2 authorize-security-group-ingress --group-id sg-db --protocol tcp --port 5432 --source-group sg-app\nFor Infrastructure-as-Code use Terraform to enforce reviewable changes; example (condensed):
\nresource \"aws_security_group\" \"app\" {\n name = \"app-sg\"\n vpc_id = var.vpc_id\n\n ingress { from_port=80 to_port=80 protocol=\"tcp\" cidr_blocks=[\"10.0.0.0/16\"] } # internal ALB only\n egress { from_port=0 to_port=0 protocol=\"-1\" cidr_blocks=[\"0.0.0.0/0\"] } # tighten if needed\n}\n\nresource \"aws_security_group\" \"db\" {\n name = \"db-sg\"\n vpc_id = var.vpc_id\n\n ingress {\n from_port = 5432\n to_port = 5432\n protocol = \"tcp\"\n security_groups = [aws_security_group.app.id]\n }\n}\nTo meet compliance and auditability expectations, avoid manual SG edits in the console. Enforce SG changes via a source-controlled IaC pipeline (Terraform/CloudFormation) and require code review. Use AWS Systems Manager Session Manager for administrative access to instances rather than opening SSH/RDP to the Internet—this removes the need for public bastions and reduces port exposure. Enable CloudTrail for API auditing, VPC Flow Logs for traffic monitoring, and AWS Config rules (e.g., restricted-common-ports, restricted-security-group-ingress) to detect wide-open security groups. Forward logs to a centralized, immutable store (S3 with MFA Delete or an encrypted log archive) for retention policies required by contract.
\n\nExample: a 12-person MSP hosts a web app containing limited CUI for a DoD contractor. They deploy an ALB in public subnets, app servers in private subnets, and a PostgreSQL RDS in isolated DB subnets. The ALB allows 0.0.0.0/0 only for HTTP/HTTPS; app servers accept traffic only from the ALB SG. RDS accepts traffic only from the app SG and is not publicly accessible. Patch management is performed through an SSM Automation document via SSM endpoints (no direct Internet access), and all backups go to an S3 bucket through a VPC Gateway endpoint with a bucket policy limiting access to the VPC endpoint principal. The company enforces SG changes via Terraform PRs to ensure every change is reviewed and logged.
\n\nConcrete tips: 1) Implement a baseline SG template and require PRs for changes, 2) Use SG descriptions and consistent tags (Environment, Owner, Purpose) for audits, 3) Use VPC endpoints where possible to avoid crossing the public Internet, 4) Restrict egress for workloads processing CUI to approved destinations, 5) Schedule quarterly reviews of security groups and NACLs and keep an audit trail, and 6) Automate detection of risky SGs (0.0.0.0/0 on admin ports) with AWS Config, Security Hub, or a simple Lambda that emails Slack/Teams on detection.
\n\nFailing to implement subnet isolation and restrictive security groups increases the likelihood of data exposure, lateral movement after compromise, and unauthorized access to sensitive information. Operationally this can mean ransomware propagation from a web server into private databases or exfiltration of FCI. From a compliance perspective, nonconformance with FAR 52.204-21 and CMMC Level 1 practices can result in contract penalties, disqualification from future bids, and reputational damage—risks that are disproportionate for small businesses working with government customers.
\n\nSummary: Implementing a clear VPC subnet architecture combined with least-privilege security groups, VPC endpoints, SSM-based access, automated IaC workflows, and monitoring satisfies the intent of FAR 52.204-21 / CMMC 2.0 Level 1 SC.L1-B.1.XI and materially reduces risk for small businesses—start with a baseline design, enforce changes through code review, enable logging, and periodically validate configurations with AWS Config and manual audits to maintain continuous compliance.
", "plain_text": "This post explains how to design AWS VPC subnets and security groups to meet the intent of FAR 52.204-21 and the CMMC 2.0 Level 1 control SC.L1-B.1.XI by implementing network separation, least-privilege access, and auditable controls—providing practical steps, example configs, and small-business scenarios you can implement today.\n\nDesign and implementation approach for Compliance Framework\nAt a high level, the Compliance Framework expects contractors to protect Federal Contract Information (FCI) and basic CUI handling by limiting network exposure, segregating public-facing and internal resources, and controlling inbound/outbound flows. Your VPC should implement a tiered network: public subnets for load balancers and bastion endpoints (if used), private subnets for application servers, and isolated subnets for databases and backups. Route tables, NAT gateways, and VPC endpoints should be used to keep private resources from direct Internet exposure while still allowing necessary outbound access for updates and APIs.\n\nSubnet layout and routing\nUse clear CIDR planning (for a small business a single VPC such as 10.0.0.0/16 is typical) and split into smaller subnets per Availability Zone (AZ) for resiliency, e.g., public subnets 10.0.0.0/24 and 10.0.2.0/24, private app subnets 10.0.1.0/24 and 10.0.3.0/24, and database subnets 10.0.4.0/26 per AZ. Attach an Internet Gateway (IGW) only to the route tables for the public subnets. For private subnets, route Internet-bound traffic through a NAT Gateway deployed in the public subnet to avoid public IP assignment to private instances. If your systems interact with AWS services (S3, Secrets Manager) for backups or configuration, create VPC endpoints (Gateway/Interface) to avoid egress to the public Internet and reduce the attack surface.\n\nSecurity groups: rules and patterns\nSecurity Groups (SGs) are stateful and should be your primary mechanism for host-to-host access control. Adopt these patterns: 1) default-deny inbound (no 0.0.0.0/0 except where explicitly required), 2) allow only required ports—e.g., ALB -> app on 80/443 or app-specific ports, app -> db on database port (e.g., 5432 for Postgres) using SG references rather than CIDR, and 3) restrict outbound traffic where appropriate (do not leave egress wide-open if endpoints/processes don't need it). Use SG references so the application SG is the only allowed source for the DB SG (source = sg-application) rather than opening the DB to a CIDR block.\n\nExample CLI and IaC snippets\nBelow are short examples you can adapt. CLI to create a security group and allow application SG to reach DB port:\n# Create a security group for the app\naws ec2 create-security-group --group-name app-sg --description \"App servers\" --vpc-id vpc-01234567\n\n# Create a security group for the DB\naws ec2 create-security-group --group-name db-sg --description \"Database servers\" --vpc-id vpc-01234567\n\n# Allow app-sg to access PostgreSQL on db-sg (replace IDs)\naws ec2 authorize-security-group-ingress --group-id sg-db --protocol tcp --port 5432 --source-group sg-app\n\nFor Infrastructure-as-Code use Terraform to enforce reviewable changes; example (condensed):\nresource \"aws_security_group\" \"app\" {\n name = \"app-sg\"\n vpc_id = var.vpc_id\n\n ingress { from_port=80 to_port=80 protocol=\"tcp\" cidr_blocks=[\"10.0.0.0/16\"] } # internal ALB only\n egress { from_port=0 to_port=0 protocol=\"-1\" cidr_blocks=[\"0.0.0.0/0\"] } # tighten if needed\n}\n\nresource \"aws_security_group\" \"db\" {\n name = \"db-sg\"\n vpc_id = var.vpc_id\n\n ingress {\n from_port = 5432\n to_port = 5432\n protocol = \"tcp\"\n security_groups = [aws_security_group.app.id]\n }\n}\n\n\nAccess control, logging, and automation\nTo meet compliance and auditability expectations, avoid manual SG edits in the console. Enforce SG changes via a source-controlled IaC pipeline (Terraform/CloudFormation) and require code review. Use AWS Systems Manager Session Manager for administrative access to instances rather than opening SSH/RDP to the Internet—this removes the need for public bastions and reduces port exposure. Enable CloudTrail for API auditing, VPC Flow Logs for traffic monitoring, and AWS Config rules (e.g., restricted-common-ports, restricted-security-group-ingress) to detect wide-open security groups. Forward logs to a centralized, immutable store (S3 with MFA Delete or an encrypted log archive) for retention policies required by contract.\n\nReal-world small business example\nExample: a 12-person MSP hosts a web app containing limited CUI for a DoD contractor. They deploy an ALB in public subnets, app servers in private subnets, and a PostgreSQL RDS in isolated DB subnets. The ALB allows 0.0.0.0/0 only for HTTP/HTTPS; app servers accept traffic only from the ALB SG. RDS accepts traffic only from the app SG and is not publicly accessible. Patch management is performed through an SSM Automation document via SSM endpoints (no direct Internet access), and all backups go to an S3 bucket through a VPC Gateway endpoint with a bucket policy limiting access to the VPC endpoint principal. The company enforces SG changes via Terraform PRs to ensure every change is reviewed and logged.\n\nCompliance tips and best practices\nConcrete tips: 1) Implement a baseline SG template and require PRs for changes, 2) Use SG descriptions and consistent tags (Environment, Owner, Purpose) for audits, 3) Use VPC endpoints where possible to avoid crossing the public Internet, 4) Restrict egress for workloads processing CUI to approved destinations, 5) Schedule quarterly reviews of security groups and NACLs and keep an audit trail, and 6) Automate detection of risky SGs (0.0.0.0/0 on admin ports) with AWS Config, Security Hub, or a simple Lambda that emails Slack/Teams on detection.\n\nRisk of not implementing the requirement\nFailing to implement subnet isolation and restrictive security groups increases the likelihood of data exposure, lateral movement after compromise, and unauthorized access to sensitive information. Operationally this can mean ransomware propagation from a web server into private databases or exfiltration of FCI. From a compliance perspective, nonconformance with FAR 52.204-21 and CMMC Level 1 practices can result in contract penalties, disqualification from future bids, and reputational damage—risks that are disproportionate for small businesses working with government customers.\n\nSummary: Implementing a clear VPC subnet architecture combined with least-privilege security groups, VPC endpoints, SSM-based access, automated IaC workflows, and monitoring satisfies the intent of FAR 52.204-21 / CMMC 2.0 Level 1 SC.L1-B.1.XI and materially reduces risk for small businesses—start with a baseline design, enforce changes through code review, enable logging, and periodically validate configurations with AWS Config and manual audits to maintain continuous compliance." }, "metadata": { "description": "Step-by-step guidance to design AWS VPC subnets and security groups that satisfy FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI requirements for protecting controlled unclassified information.", "permalink": "/how-to-configure-aws-vpc-subnets-and-security-groups-to-meet-far-52204-21-cmmc-20-level-1-control-scl1-b1xi.json", "categories": [], "tags": [] } }