Segregating public-facing systems into dedicated cloud subnets is a straightforward, high-impact control that reduces attack surface, limits lateral movement, and provides auditable evidence to meet FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI requirements.
Why this control matters for Compliance Frameworks
The core objective of FAR 52.204-21 and CMMC Level 1 network controls is to ensure that controlled unclassified information (CUI) and other sensitive resources aren't unintentionally exposed through publicly reachable systems. Placing web servers, API gateways, and load balancers in clearly defined public subnets — while keeping databases, admin consoles, and internal services in private subnets — demonstrates intentional design, simplifies access control, and generates the configuration artifacts auditors expect (subnet CIDRs, route tables, security group/NSG rules, and flow logs).
Cloud-specific implementation details
AWS (VPC, subnets, IGW / NAT)
In AWS, create a VPC and allocate separate subnets for "public" and "private" tiers (e.g., 10.0.0.0/24 public, 10.0.1.0/24 private). Attach an Internet Gateway (IGW) to the VPC and associate a route table that sends 0.0.0.0/0 to the IGW for public subnets only. Private subnets should route outbound Internet through a managed NAT Gateway (or NAT instance) in a public subnet. Use Security Groups to allow only required inbound ports (e.g., 80/443 from 0.0.0.0/0 to the load balancer, but deny direct SSH from the Internet) and NACLs as an additional stateless filter if needed. Enable VPC Flow Logs and AWS Config rules (e.g., vpc-default-route-to-igw) to produce audit evidence.
# minimal Terraform: public subnet + route table
resource "aws_subnet" "public" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.0.0/24"
map_public_ip_on_launch = true
}
resource "aws_route_table" "public_rt" {
vpc_id = aws_vpc.main.id
route {
cidr_block = "0.0.0.0/0"
gateway_id = aws_internet_gateway.igw.id
}
}
resource "aws_route_table_association" "public_assoc" {
subnet_id = aws_subnet.public.id
route_table_id = aws_route_table.public_rt.id
}
Azure (VNet, subnets, NSG, Azure Firewall)
On Azure, create a Virtual Network with separate subnets for "Internet-facing" resources and "Internal" resources. Assign a Public IP and Application Gateway or Azure Load Balancer in the public subnet. Use Network Security Groups (NSGs) on subnets and/or NICs to restrict inbound traffic and deny by default, allowing only the necessary ports and sources. For outbound traffic from private subnets, prefer Azure Firewall or Azure NAT Gateway. Enable NSG flow logs (via Network Watcher) and Activity Logs to capture changes for compliance evidence.
GCP (VPC, subnets, Cloud NAT, Cloud Armor)
In GCP, use a VPC with regional subnets and separate an internet-facing subnet (where Compute Engine instances fronting users or an external HTTP(S) load balancer live) from private subnets that host databases or internal APIs. GCP implicitly provides an internet gateway, so enforce public exposure via external IPs and firewall rules. Use Cloud NAT for controlled outbound from private instances and Cloud Armor / GCP WAF in front of load balancers for DDoS and application-layer protections. Enable VPC Flow Logs and Cloud Audit Logs for evidence.
Practical steps for small businesses (Key objectives & Implementation notes)
Start with a simple design: one VPC/VNet with two subnet groups (public + private) per availability zone or region. Key objectives: (1) Only place services that require direct Internet access in the public subnet (load balancers, bastion hosts if needed), (2) Ensure stateful firewall rules allow only required traffic, (3) Use NAT for outbound traffic from private systems, and (4) Collect logs and configuration snapshots for audits. Implementation notes: standardize naming (env-app-role-subnet), tag resources for discoverability, codify everything in IaC (Terraform/ARM/Bicep/Cloud Deployment Manager) so you can show reproducible configs. Small businesses should reuse managed services (managed DBs in private subnets, cloud load balancers) to reduce operational burden and simplify evidence collection.
Evidence and audit artifacts to collect
For compliance evidence produce: network diagrams showing CIDR allocations and subnet roles; IaC templates (Terraform files or ARM templates) with subnet/route table definitions; screenshots or exported JSON of route tables, IGW/NAT configuration, and NSG/Security Group/firewall rules; VPC Flow Logs/NSG Flow Logs for a representative period; and change-control tickets or git history showing the design decision. Map each artifact to the control language in your assessment workbook (e.g., "SC.L1-B.1.XI: public systems in subnet 'public-web' with route to IGW; private DB subnet without public IPs").
Compliance tips and best practices
Adopt a deny-by-default posture (no inbound allowed unless explicit), minimize the number of public-facing IPs (use load balancers and CDN), restrict management access to a hardened bastion with MFA and conditional access, automate drift detection (AWS Config / Azure Policy / Forseti or Config Validator), and retain logs for the required retention period. Use tagging and a small set of approved Terraform modules so reviewers can quickly verify conformance. Run periodic pen-tests and simple scans (e.g., external port scans) to confirm only intended services are reachable.
Risk of not implementing subnet segregation
If public-facing systems are mixed with internal services, you increase the risk of accidental data exposure, privilege escalation, and lateral movement that can lead to data exfiltration or ransomware. From a compliance perspective, lack of clear segregation and missing logs often results in failed assessments, corrective action plans, or loss of contract eligibility under FAR and CMMC requirements. For small businesses, a single misconfigured public instance can put the entire environment at risk and damage reputation and revenue.
Summary: Implementing segregated public subnets is an achievable, low-cost control that materially reduces risk and provides concrete artifacts for FAR 52.204-21 and CMMC 2.0 Level 1 audits — design public/private subnet pairs, enforce access with security groups/NSGs/firewalls, use NAT and managed services for private workloads, enable flow and configuration logging, and codify the setup in IaC for repeatable evidence. Following these steps gives you both improved security and a clear audit trail to demonstrate compliance.
