This post provides practical, actionable steps for configuring AWS VPC subnets, route tables, and security groups to help small businesses meet the network segmentation and access control expectations implied by FAR 52.204-21 and CMMC 2.0 Level 1 (Control SC.L1-B.1.XI).
Overview & objectives
The primary goal for this control is to ensure covered data (e.g., Federal Contract Information or low-impact Controlled Unclassified Information) is isolated, only accessible via explicitly authorized paths, and protected with least-privilege network controls. Implementation focuses on: designing public and private subnets, using route tables and NAT for controlled outbound access, providing secure inbound access paths (bastion/ALB), and applying security groups (SGs) as stateful, least-privilege filters. For small businesses that host simple web applications or store contractor data, this architecture limits exposure while remaining operationally practical.
Design principles
Start with a few core principles: (1) deny-by-default network access; (2) separate publicly reachable resources (web tiers) from data-storing resources (databases, file stores) using private subnets; (3) restrict cross-tier communication using SG references rather than wide CIDR ranges; (4) eliminate direct Internet access to hosts that store or process covered data by placing them in private subnets with no IGW route; and (5) use VPC endpoints for AWS service access to avoid sending traffic over the public Internet.
Implementation: subnet and routing setup
Example subnet plan for a production VPC (small business): a /22 VPC (10.0.0.0/22) with three AZs, each AZ having one public and one private subnet: - public subnets: 10.0.0.0/26, 10.0.1.0/26, 10.0.2.0/26 - private subnets: 10.0.0.64/26, 10.0.1.64/26, 10.0.2.64/26 Public subnets are associated with a route table that has a route to an Internet Gateway (IGW). Private subnets have a route to a NAT Gateway (in a public subnet) for controlled outbound Internet access. For AWS service calls (S3, Secrets Manager), prefer Gateway VPC Endpoints (S3/DynamoDB) or Interface Endpoints (EC2, SSM) so private hosts never require Internet egress for common operations.
AWS CLI example: create a private route to a NAT gateway
After creating a NAT Gateway (nat-0123456789abcdef0) and a route table for private subnets, add a route to 0.0.0.0/0 via the NAT:
aws ec2 create-route --route-table-id rtb-0abcd1234 --destination-cidr-block 0.0.0.0/0 --nat-gateway-id nat-0123456789abcdef0Implementation: security groups and least privilege
Use security groups as your primary in-VPC access control: create a distinct SG for each tier and reference SGs (not CIDR blocks) when allowing cross-tier traffic. Example SGs: - sg-web (allow inbound TCP 80/443 from 0.0.0.0/0 to ALB) - sg-app (allow inbound TCP 8080 from sg-web only) - sg-db (allow inbound TCP 3306 from sg-app only) - sg-bastion (allow SSH/SSM only from a fixed admin IP or use Session Manager to avoid SSH entirely) Security groups are stateful — you only need to allow the initiating inbound or outbound portion. Always avoid opening management ports (22, 3389) to 0.0.0.0/0; prefer SSM Session Manager or a restricted bastion host in a public subnet with admin IP restrictions.
Security group creation examples (CLI)
Create an application SG and allow only traffic from web SG (replace IDs):
aws ec2 create-security-group --group-name sg-app --description "App tier" --vpc-id vpc-0abc12345
aws ec2 authorize-security-group-ingress --group-id sg-app_id --protocol tcp --port 8080 --source-group sg-web_idMonitoring, logging, and enforcement
Enable VPC Flow Logs for every VPC and send logs to CloudWatch Logs or S3 for retention and review. Turn on AWS Config rules that evaluate network configurations (e.g., restricted security group rules, presence of VPC endpoints). For small shops, create alerting on high-risk flows (e.g., inbound RDS traffic, SSH attempts from unexpected IPs). Use IAM policies to restrict who can edit SGs and route tables — treat network configuration as a sensitive administrative capability, and record changes in CloudTrail for audit and investigation.
Real-world small-business scenario
A small contractor hosts a public marketing site and a CUI intake application. The marketing site runs behind an ALB in public subnets (sg-web). The intake application runs on EC2/ECS in private subnets (sg-app) and writes to an RDS instance in a separate private subnet (sg-db). S3 access uses a Gateway VPC Endpoint, IAM policies restrict the S3 bucket to the VPC endpoint, and backups go to S3 with server-side encryption. Admins use SSM Session Manager to access EC2 for maintenance; no SSH is permitted from the Internet. This configuration keeps CUI off Internet-accessible hosts and ensures only the application tier can reach the database — satisfying the segregation and minimized exposure expected by FAR/CMMC guidance.
Risks of not implementing these controls
Failing to implement subnet segmentation, SG least-privilege, and restricted egress increases the risk of accidental exposure of covered data, lateral movement after compromise, and data exfiltration. For contractors, that can mean contract penalties, loss of federal business, and regulatory scrutiny. From an operational perspective, broad SG rules also increase blast radius for misconfigured instances and make incident response harder because noisy, unexpected paths exist into sensitive systems.
Compliance tips and best practices
Practical best practices: use template IaC (Terraform/CloudFormation) to enforce consistent VPC/subnet/Security Group creation; peer-review and automated scans (e.g., AWS Config, third-party IaC scanners) before changes are applied; rotate NAT/ALB and endpoint configurations across environments (dev/test/prod); tag network resources with environment and owner for auditability; and document the allowed data flows in a simple network data-flow diagram as part of your compliance artifacts. Finally, prefer cloud-managed controls (VPC Endpoints, SSM, ALBs) over ad hoc self-managed access methods whenever they simplify compliance.
Summary: By designing a simple, repeatable VPC architecture with public/private subnet separation, least-privilege security groups, controlled egress via NAT and VPC endpoints, and thorough logging and IAM controls, a small business can materially meet the network segmentation and access-control expectations in FAR 52.204-21 and CMMC 2.0 Level 1 (SC.L1-B.1.XI). Implement via IaC, enforce via automated checks, and document your decisions so audits and operational teams can validate your controls quickly.
