This post gives practical, actionable steps to design and implement physically or logically separated subnetworks in AWS and Azure so small businesses can meet the network-segmentation expectations in FAR 52.204-21 and CMMC 2.0 Level 1 (Control SC.L1-B.1.XI), with examples, implementation notes, and compliance best practices.
Why segmentation matters for FAR 52.204-21 / CMMC 2.0 Level 1
FAR 52.204-21 requires basic safeguarding of contractor information systems, and CMMC 2.0 Level 1 emphasizes basic cyber hygiene for Federal Contract Information (FCI). A core expectation is that you logically or physically separate systems that process or store FCI from public/less-trusted systems to reduce unauthorized access and limit the blast radius of compromise. For small businesses this usually means using cloud-native constructs to isolate FCI, not necessarily physical racks, while documenting the separation in your System Security Plan (SSP) and showing controls like network ACLs, security groups, flow logs, and account boundaries.
High-level implementation approach (Compliance Framework)
Begin by identifying the scope of FCI and mapping it to cloud resources. Decide whether you need physical isolation (dedicated hosts, dedicated tenancy, or provider-hosted private clouds) or logical isolation (VPCs/VNets, subnets, NSGs/security groups). For CMMC Level 1 / FAR basic safeguarding, logical separation is generally acceptable if implemented correctly and documented. Your implementation notes should include which accounts/subscriptions host FCI, what trust boundaries exist, and how traffic is controlled and logged.
AWS practical implementation
Recommended architecture for small-to-medium AWS environments: - Use separate AWS accounts for production (FCI) and non-production (developer/test) under AWS Organizations or Control Tower; if separate accounts are not feasible, use separate VPCs with strong routing and account-level IAM boundaries. - Create a VPC for FCI with segmented subnets: private subnets for application and data tiers, restricted management subnets, and no public IPv4 for data subnets. Use CIDR planning such as 10.0.0.0/16 for the FCI VPC with /24 subnets per AZ (10.0.1.0/24 app, 10.0.2.0/24 data). - Enforce isolation with Security Groups (stateful allow-only rules) and NACLs (stateless additional filtering) and minimize use of overly permissive rules. Implement route tables that prevent east-west access when not required. - Use VPC peering, Transit Gateway, or PrivateLink to connect services; where connectivity is required, restrict routes to explicit endpoints and use Transit Gateway route tables to control which VPCs can talk to each other. - Use VPC Endpoints (Interface & Gateway) and PrivateLink for S3, Secrets Manager, and other AWS services so traffic to AWS services never traverses the public internet. - Deploy AWS Network Firewall or a vendor firewall in the FCI VPC for centralized inspection if budget permits. - Enable CloudTrail, VPC Flow Logs, and AWS Config rules to capture and demonstrate network activity and configuration drift; forward logs to a separate immutable logging account or storage bucket (with restricted access) for retention and auditing.
Azure practical implementation
Recommended Azure approach: - Use separate subscriptions for production (FCI) and non-production. Group subscriptions under Management Groups and apply Azure Policy and RBAC to enforce boundaries. - Create a VNet for FCI resources and divide into subnets by function (web, app, db) using address spaces like 10.1.0.0/16 with /24 subnets per tier. - Use Network Security Groups (NSGs) and Application Security Groups to enforce fine-grained traffic rules; prefer explicit allow rules and deny-by-default posture. - Use Azure Firewall or a Next-Gen virtual appliance in a hub VNet, and connect VNets using VNet peering or Azure Virtual WAN with hub-and-spoke architecture; control which spokes can reach each other via route tables in the hub. - Protect service access with Private Endpoints (for Azure Storage, SQL, Key Vault) so traffic to platform PaaS services remains on the Microsoft backbone. - Enable Azure Monitor (NSG Flow Logs), Azure Activity Logs, and Azure Policy to capture, retain and attest to network configurations and access events. Send logs to a separate Log Analytics workspace or a dedicated subscription for immutable retention.
Real-world small-business scenarios and examples
Example 1 — Small dev shop winning a DoD sub-contract: Create a single FCI subscription/account where all contract-related workloads live. Use a VPC/VNet with private subnets only, PrivateLink/Private Endpoint to connect to S3/Blob and SQL with strict security groups/NSGs, and a bastion host in a management subnet with MFA-protected jump access. Document the boundary in the SSP and show CloudTrail/Flow Logs proving no public access to data subnets.
Example 2 — Cost-conscious shop without separate accounts: Use one AWS account with two VPCs (FCI and Dev). Implement Transit Gateway route tables to block all routes from Dev to FCI. Use VPC Flow Logs and AWS Config rules to detect any accidental peering or route changes. Combine this with strong IAM and tagging so auditors can see logical separation even without physical host isolation.
Compliance tips and best practices
Document everything in your SSP: which resources are in-scope, network diagrams, trust boundaries, and justification for logical vs physical separation. Implement least-privilege for management and automation accounts and use MFA everywhere. Use automated controls (AWS Config/Azure Policy) to prevent drift—examples: deny creation of internet-facing subnets for the FCI subscription, enforce Private Endpoint for storage used by FCI. Keep an evidence repository: screenshots, flow logs, CloudTrail/Azure Activity log exports, and change control records for every networking change.
Risks of not implementing separation
Without proper physical or logical separation you increase risk of data exposure, lateral movement, and uncontrolled exfiltration. For a contractor this can mean failing FAR/CMMC obligations, losing contracts, incurring corrective action plans, or exposing FCI leading to reputational and financial damage. From a technical perspective, improper segmentation makes incident containment harder and increases remediation costs.
Summary: For FAR 52.204-21 and CMMC 2.0 Level 1 compliance, implement clear network boundaries for FCI using cloud-native segmentation (separate accounts/subscriptions, VPC/VNet isolation, NSGs/security groups, private endpoints, centralized firewalls) augmented with logging, policy enforcement, and documentation in your SSP. Small businesses can meet these requirements cost-effectively by focusing on strong logical isolation, automated policy guardrails, and demonstrable audit evidence rather than expensive physical isolation unless contractually required.
