This post shows practical steps for configuring cloud VPC subnets and security groups to meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 (control SC.L1-B.1.XI) — namely, to segregate and protect systems that handle Controlled Unclassified Information (CUI) by restricting network access and minimizing exposure to public networks.
Understanding the control and key objectives
The compliance objective behind FAR 52.204-21 and CMMC Level 1 network-related practices is straightforward: limit network exposure of CUI processing and storage, permit only authorized connections, and document the controls. For a small business this translates into clear design goals: place CUI-bearing systems in private subnets with no direct internet routes, use layered network controls (security groups and optional NACLs) to limit traffic, and provide secure, auditable administrative access. Failure to implement these controls increases the risk of unauthorized access, data exfiltration, loss of contract eligibility, and reputation damage.
Designing your VPC subnet architecture
Start by mapping systems that handle CUI and those that do not. A recommended pattern for small teams is a three-tier subnet model per Availability Zone: (1) public subnet for load balancers or bastions with a route to an Internet Gateway (IGW), (2) private application subnet with no direct IGW route and access to outbound internet via a NAT Gateway/instance if needed, and (3) private data subnet for databases or storage endpoints with the strictest controls and no outbound internet unless required. Place resources across at least two AZs for availability. Example: ALB in public subnets, web/application servers in private app subnets, and RDS or file storage in private data subnets. Ensure RDS instances have public accessibility disabled and are launched in the private subnets' route tables.
Example small-business scenario
Imagine a small contractor running a customer portal that stores CUI in an RDS Postgres database. Implementation steps: create a VPC with 2 AZs, create public subnets with IGW and private subnets with NAT Gateway; deploy an internet-facing Application Load Balancer (ALB) in public subnets (HTTPS only); deploy app servers in private app subnets (no public IPs) behind the ALB; deploy RDS in private data subnets with a subnet group spanning both AZs. This segregation ensures that only the ALB has inbound internet exposure while the app and DB remain inaccessible directly from the public internet.
Implementing security groups and rule examples
Security groups should implement least privilege and use other security groups as sources (not wide CIDR when avoidable). Practical rule examples: ALB_SG ingress: TCP 443 from 0.0.0.0/0 (client traffic), egress: allow to APP_SG on TCP 443. APP_SG ingress: TCP 443 from ALB_SG (reference by SG id), SSH/RDP disabled from the internet — admin access only via a dedicated Admin_SG. DB_SG ingress: TCP 5432 (Postgres) or 3306 (MySQL) from APP_SG only. Avoid security group rules that allow 0.0.0.0/0 to management ports (22, 3389, database ports). Prefer security group references over IP ranges so an ALB or autoscaling group can change IPs without changing firewall rules.
Bastion alternatives and secure admin access
Rather than exposing SSH/RDP through a bastion host with open internet access, use provider-managed methods: AWS Systems Manager Session Manager, Azure Bastion, or ephemeral VPNs combined with conditional access. If you must use a bastion, place it in a public subnet, restrict its SG to management team office IPs (/32 CIDR) or a corporate SASE IP set, and log all sessions. Record connection evidence (CloudTrail/SSM logs) as compliance artifacts.
Network-layer controls: NACLs, VPC endpoints, and flow logs
Use NACLs as a coarse-grained, stateless filter to block uncommon traffic at the subnet level, but do not rely on them for access control (security groups are primary). Use VPC Endpoints (AWS PrivateLink or service endpoints) to avoid routing CUI traffic over the internet — e.g., S3/Gateway endpoints for backups, interface endpoints for KMS or other managed services. Enable VPC Flow Logs to capture accepted/rejected flows and ship them to CloudWatch Logs or S3 for retention and audit. For GCP/Azure equivalents: use VPC Service Controls or Private Endpoints and NSGs/ASGs with equivalent logging and private routing constructs.
Automation, monitoring, and evidence for audits
Automate your network configuration with IaC (Terraform, CloudFormation, ARM/Bicep) so every change is auditable and repeatable. Add automated guards: AWS Config managed rules (e.g., “rds-instance-public-access-check”, “restricted-common-ports”), GuardDuty/ATP for threat detection, and alerting on SG changes (CloudWatch Events/EventBridge triggering SNS). Maintain a network diagram and a change log showing when rules were modified. For evidence, export security group configs, route tables, VPC flow logs, and CloudTrail entries showing administrative actions; these are what auditors will request to demonstrate control SC.L1-B.1.XI is implemented and maintained.
Compliance tips and best practices
Keep a short checklist for each CUI system: private-only subnets verified, no public IPs, security groups restrict traffic to required ports and SG sources, VPC endpoints for cloud services, and admin access via SSM/Bastion with IP whitelists. Tag resources to tie them to contract/CUI designations, enforce tagging with policies, and review security group rules quarterly or on every major change. Train staff on change control and adopt a "deny by default / allow by exception" mindset for network rules. Finally, plan incident response and tabletop scenarios for an exposed subnet so your team can act quickly if a misconfiguration occurs.
In summary, meeting FAR 52.204-21 and CMMC 2.0 Level 1 network expectations requires a clear VPC subnet design that isolates CUI, tightly scoped security group rules that enforce least privilege, use of provider-native private connectivity options, and automated logging and configuration management to produce verifiable evidence. For small businesses, these steps are practical and cost-effective when automated and documented; they significantly reduce risk and help maintain eligibility for government contracts.
