Segregated subnetworks (network segmentation) are a practical, low-complexity control that small businesses can implement to meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 (SC.L1-B.1.XI): to limit network exposure of Federal Contract Information (FCI) and reduce the blast radius of a compromise. This post walks through design goals, concrete AWS and Azure implementation patterns, a deployment checklist, and realistic testing and monitoring advice you can apply today.
Key objectives and mapping to Compliance Framework
The primary objectives are: isolate systems that store or process FCI from general-purpose networks, restrict and log network flows between trust zones, and provide demonstrable evidence of network controls for auditors. Practically, this means creating at least three logical trust zones (public-facing, internal application, and sensitive/management), enforcing least-privilege network rules, and enabling flow logging/alerting so you can show who accessed what and when.
Design: network segmentation strategy (practical details)
Start with an address plan and trust zones. Example for a small environment: allocate a /16 for the account (10.0.0.0/16 for AWS, 10.1.0.0/16 for Azure) and carve it into /24 or /26 subnets. Sample layout: 10.0.1.0/24 = public (load balancers), 10.0.2.0/24 = application tier, 10.0.3.0/24 = database/sensitive, 10.0.4.0/28 = management/bastion. Use private subnets for app & DB with NAT or PrivateLink/Private Endpoint for outbound storage access. Design route tables so traffic between zones must traverse a controlled hop (firewall or security appliance) instead of default allow-all routing.
AWS-specific implementation notes
In AWS, use a single VPC per environment (prod/dev) with Availability Zone subnets for resilience. Implement Security Groups (SGs) as instance-level allow-lists and Network ACLs (NACLs) for coarse subnet controls. Example SG rules: app-SG allows 443 from ALB-SG, db-SG allows 3306 only from app-SG. Use VPC Flow Logs (delivered to CloudWatch Logs or S3) and AWS Config rules (e.g., vpc-flow-logs-enabled, restricted-security-groups) to record and demonstrate compliance. For cross-account segmentation, prefer Transit Gateway or VPC peering with explicit route table controls; avoid letting peering create flat routing that bypasses controls. Where possible use AWS PrivateLink for service endpoints (S3 Gateway/Interface endpoints) so sensitive subnets never traverse the public internet.
Azure-specific implementation notes
On Azure, create a hub-and-spoke (hub VNet for shared services + spoke VNets per environment/team) or a single VNet with subnets for small shops. Apply Network Security Groups (NSGs) to subnets and NICs with a default deny inbound rule and only permit required ports (e.g., allow 443 to frontend-subnet from the internet, allow SQL ports only from app-subnet). Use Azure Firewall or a third-party NVA in the hub to centralize egress and inter-spoke filtering; use Private Endpoints for Azure Storage/SQL to keep traffic off the public internet. Enable NSG flow logs to a Log Analytics workspace and use Azure Policy to enforce required network controls and to generate compliance evidence.
Deployment checklist: step-by-step actions
Concrete steps you can follow: 1) Define CIDR blocks and zones (public/app/db/mgmt). 2) Create VPC/VNet and subnets across AZs. 3) Create and attach route tables—ensure private subnets route to NAT/Firewall. 4) Implement SG/NSG rules with deny-by-default posture—document each rule with justification (who/what/why). 5) Deploy bastion access—use AWS Systems Manager Session Manager or Azure Bastion to avoid opening SSH/RDP to the internet. 6) Configure PrivateLink/Private Endpoint for storage & managed services. 7) Enable flow logs, audit logs, and continuous compliance (AWS Config / Azure Policy). 8) Automate via IaC (Terraform, CloudFormation, or ARM/Bicep) so your deployment is repeatable and auditable—example tags: "compliance:fcidata=yes".
Testing, validation, and monitoring
Validate segmentation with both functional and negative tests: from the public subnet verify only allowed ports respond; from inside the app subnet attempt to access the DB from unauthorized hosts to confirm it's blocked. Use nmap or netcat internally and check that logs (VPC Flow Logs / NSG Flow Logs) record deny events. Configure alerts in CloudWatch/CloudWatch Alarms or Azure Monitor for unusual flows (e.g., large outbound traffic from sensitive subnets). Maintain an evidence pack: network diagrams, IaC templates, SG/NSG lists, and a sampling of flow logs showing denied traffic tied to test runs—auditors expect reproducible proof.
Risks of not implementing segmentation and best practices
Without segmentation you increase the blast radius: a compromised web server on a single flat network can pivot to databases and management interfaces, exfiltrating FCI and risking contract loss or regulatory penalties. Best practices include: enforce least privilege on network and IAM, keep management interfaces off public subnets, rotate credentials and use MFA for privileged accounts, use ephemeral tunnels (Session Manager/Bastion) rather than static SSH keys, and review SG/NSG rules quarterly. For small businesses with limited budget, prioritize private endpoints and flow logging over expensive NGFWs—many compliance objectives can be met with correctly applied SGs/NSGs plus logging and change control.
Segregated subnetworks are a high-impact, low-cost control that maps directly to the intent of FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI: isolate sensitive assets, control traffic paths, and provide auditable evidence. By following the design patterns above—clear CIDR planning, deny-by-default security rules, private endpoints, bastionless management, and robust logging—you can implement defensible segmentation in AWS or Azure and produce the documentation auditors expect. Start small (one environment), automate with IaC, and iterate toward a repeatable, auditable network architecture that protects your FCI and your contracts.
