This post gives practical, actionable guidance for architecting AWS subnets and security groups so a small business can meet FAR 52.204-21 obligations and the CMMC 2.0 Level 1 control SC.L1-B.1.XI by isolating covered contractor information (CCI/CUI), limiting external access, and producing the documentation needed for assessment.
Understand the compliance objective and map it to AWS constructs
At a high level FAR 52.204-21 and CMMC Level 1 require contractors to protect controlled unclassified information by implementing basic safeguardingâthis maps directly to network boundary and access controls in AWS: use VPC subnet segmentation, route table controls, security groups (SGs) and network ACLs (NACLs) to limit who can reach resources that process or store CCI/CUI, and produce evidence (network diagrams, rule inventories, logs) for the Compliance Framework assessment. For your System Security Plan (SSP) and evidence package, record the mapping: which subnet holds CCI, which SGs enforce access, what monitoring proves enforcement.
Design a clear subnet topology with intent
Start with a simple, documented CIDR plan and availability-zone-aware subnets. Example for a small business: VPC 10.0.0.0/16 with three AZs, each with a public subnet (10.0.1.0/24, 10.0.3.0/24, 10.0.5.0/24) for load balancers and NAT gateways, and corresponding private subnets for application and database tiers (10.0.2.0/24, 10.0.4.0/24, 10.0.6.0/24). Tag subnets with keys like "Environment", "Tier", and "Compliance" (Compliance=CMMC_L1) and publish a single-page network diagram that highlights which subnets contain CCI. Ensure auto-assign public IPv4 is disabled on private subnets to prevent accidental exposure.
Public vs private placement and controlled egress
Place internet-facing components (ALBs, NAT Gateways, bastion/management jump hosts if needed) in public subnets with routes to an Internet Gateway (IGW). Place application servers, functions, and databases that handle CCI in private subnets with routes only to a NAT Gateway or VPC endpoints for necessary egress. For small shops concerned about NAT Gateway cost, a well-maintained NAT instance can be acceptable, but document hardening and HA tradeoffs. Prefer VPC endpoints (Interface and Gateway endpoints) for AWS services (S3, Secrets Manager, SSM) to avoid Internet egress for critical operations.
Security group strategy: least privilege and tiered referencing
Use security groups as the primary access control for instances and services. Apply a one-SG-per-tier pattern and use security-group referencing instead of open IP ranges whenever possible: for example, ALB-SG allows inbound 443 from 0.0.0.0/0 (or a restricted customer CIDR if appropriate); App-SG allows inbound 443 from ALB-SG; DB-SG allows inbound 3306 (or the DB port) only from App-SG; Management-SG allows SSH (22) or RDP (3389) only from a Bastion-SG which itself only allows access from a documented corporate IP range or, better, from no public IPs and uses SSM Session Manager. Because security groups are stateful, you only need ingress rules to control who can initiate connections; be explicit about allowed egress rules, and restrict egress where feasible (for example allow only specific endpoints or ports to reduce risk of data exfiltration). Name and tag SGs consistently, and maintain a rules spreadsheet or automated inventory that maps each rule to a compliance requirement in the Framework evidence.
Small-business example: secure web app handling CUI
Imagine a small contractor running a customer portal that displays limited CUI. Use an ALB in public subnets (HTTPS only), ECS/EKS or EC2 app servers in private subnets with App-SG, and RDS in private subnets with DB-SG. Disable SSH/RDP access entirely by leveraging SSM Session Manager and give SSM's role permission only to specific admin users. Configure an RDS parameter to disallow public accessibility and ensure the DB subnet group only contains private subnets. Turn on VPC Flow Logs for the VPC, send them to CloudWatch Logs, and enable an AWS Config rule such as ârds-public-access-checkâ and ârestricted-common-portsâ to detect accidental exposureâinclude screenshots or Config rule outputs in your compliance evidence bundle.
Operational controls, automation and evidence collection
Compliance Framework reviewers will expect not just design but operational proof. Enable CloudTrail organization-wide, capture VPC Flow Logs, and feed findings to Security Hub or a SIEM. Automate network and SG deployment via CloudFormation/Terraform modules so rule drift is minimized and changes are auditable. Implement AWS Config rules or custom Lambda checks that enforce tagging, detect public subnets with CCI workloads, and validate that Security Groups do not allow broad management ports from 0.0.0.0/0. Collect change history (CloudTrail) and periodic exported inventories (aws ec2 describe-security-groups, aws config snapshots) to demonstrate continuous adherence to the Compliance Framework practice.
Failing to properly segment subnets and lock down security groups increases the risk of unauthorized access, data exfiltration, and public exposure of CCIâconsequences that can include mandated incident reporting under FAR 52.204-21, loss of contracts, reputational harm, and regulatory penalties. From a technical viewpoint, misconfigured SGs (e.g., management ports open to the world) or placing CCI-processing servers in public subnets are the most common and highest-impact risks for small organizations.
In summary, map the Compliance Framework requirement to a simple, documented VPC topology; isolate CCI in private subnets; use tiered security groups with SG-to-SG references; prefer VPC endpoints to avoid unnecessary Internet egress; automate deployment and monitoring (CloudTrail, VPC Flow Logs, AWS Config); and retain evidence (network diagrams, rule inventories, logs) in your SSP. These practical steps will put a small business in a strong position to demonstrate compliance with FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI during assessment.
