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.
Design and implementation approach for Compliance Framework
At 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.
Subnet layout and routing
Use 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.
Security groups: rules and patterns
Security 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.
Example CLI and IaC snippets
Below are short examples you can adapt. CLI to create a security group and allow application SG to reach DB port:
# Create a security group for the app
aws ec2 create-security-group --group-name app-sg --description "App servers" --vpc-id vpc-01234567
# Create a security group for the DB
aws ec2 create-security-group --group-name db-sg --description "Database servers" --vpc-id vpc-01234567
# Allow app-sg to access PostgreSQL on db-sg (replace IDs)
aws ec2 authorize-security-group-ingress --group-id sg-db --protocol tcp --port 5432 --source-group sg-app
For Infrastructure-as-Code use Terraform to enforce reviewable changes; example (condensed):
resource "aws_security_group" "app" {
name = "app-sg"
vpc_id = var.vpc_id
ingress { from_port=80 to_port=80 protocol="tcp" cidr_blocks=["10.0.0.0/16"] } # internal ALB only
egress { from_port=0 to_port=0 protocol="-1" cidr_blocks=["0.0.0.0/0"] } # tighten if needed
}
resource "aws_security_group" "db" {
name = "db-sg"
vpc_id = var.vpc_id
ingress {
from_port = 5432
to_port = 5432
protocol = "tcp"
security_groups = [aws_security_group.app.id]
}
}
Access control, logging, and automation
To 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.
Real-world small business example
Example: 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.
Compliance tips and best practices
Concrete 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.
Risk of not implementing the requirement
Failing 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.
Summary: 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.
