Separating publicly accessible components from internal networks inside an AWS VPC is a foundational control for meeting FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI: you must design your network so internet-facing resources (load balancers, web servers) are isolated from internal assets (application servers, databases, management interfaces) to reduce attack surface and protect Controlled Unclassified Information (CUI) or other sensitive data.
Core architecture and implementation steps
Start with a multi-AZ VPC design using a private RFC1918 CIDR (for example 10.0.0.0/16). Create at least two public subnets (one per AZ) for internet-facing components and two private subnets (one per AZ) for application servers and databases. Attach an Internet Gateway (IGW) to the VPC and associate a dedicated public route table where 0.0.0.0/0 routes to the IGW. For private subnets, create a separate route table that routes 0.0.0.0/0 to a NAT Gateway placed in a public subnet to allow outbound internet access for updates without exposing private instances to inbound internet traffic.
Concrete subnet CIDR example for a small business
Example CIDR layout for small organizations: VPC = 10.0.0.0/16; Public subnets = 10.0.1.0/24 (us-east-1a), 10.0.3.0/24 (us-east-1b); Private subnets = 10.0.2.0/24 (us-east-1a), 10.0.4.0/24 (us-east-1b). Put an Application Load Balancer (ALB) in the public subnets (with a security group allowing 80/443 from the internet). Place EC2 app servers or ECS tasks in private subnets (only reachable via the ALB and internal security group rules) and databases in a further restricted private subnet with a security group permitting access only from the app servers on the necessary port (for example MySQL 3306).
Security groups, NACLs and VPC endpoints
Use security groups as the primary access control: follow least-privilege rules (ALB SG: allow 80/443 from 0.0.0.0/0; App SG: allow 443 from ALB SG; DB SG: allow 3306 from App SG). Avoid over-permissive 0.0.0.0/0 rules on private resources. Use Network ACLs for coarse-grained, stateless filtering if needed, but do not rely on NACLs as your only control. For service traffic that shouldn't traverse the internet (S3, DynamoDB), create VPC Gateway or Interface Endpoints (S3 Gateway Endpoint or AWS PrivateLink) to keep traffic on the AWS network — this also helps meet compliance expectations of minimizing exposure to the public internet.
Operational details and cost tradeoffs
Small businesses should weigh NAT Gateway cost vs. managing a NAT instance: NAT Gateways are highly available within an AZ and simpler to manage but have hourly and data-processing charges. For production compliance environments, prefer NAT Gateways in each AZ for HA and attach private subnets to NAT Gateways in their AZ’s route table via propagated routes. Also enable source/destination checks only on instances that require them; disable for NAT instances. Tag subnets, route tables, NAT gateways, and security groups with standard taxonomy (environment:prod, compliance:FAR52.204-21) to make evidence collection and auditing straightforward.
Monitoring, logging and evidence for compliance
Implement VPC Flow Logs to capture IP traffic for the VPC and store logs in an S3 bucket with lifecycle policies and strict bucket policies. Enable CloudTrail for API activity, and Security Hub/GuardDuty for threat detection. For compliance evidence collect: network diagrams, subnet and route table screenshots/exports, security group rules, VPC Flow Logs for a defined retention period, and change-control tickets showing when network modifications were made. These artefacts directly support FAR 52.204-21 and CMMC request for demonstrable network separation and monitoring.
Automation and reproducibility
Automate the VPC, subnet, and security group provisioning using IaC (Terraform or CloudFormation) so changes are trackable and repeatable. Example Terraform snippet to create a public subnet and route to an IGW:
# Terraform (abbreviated)
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
tags = { Name = "corp-vpc" }
}
resource "aws_subnet" "public_a" {
vpc_id = aws_vpc.main.id
cidr_block = "10.0.1.0/24"
availability_zone = "us-east-1a"
map_public_ip_on_launch = true
tags = { Name = "public-a" }
}
resource "aws_internet_gateway" "igw" {
vpc_id = aws_vpc.main.id
}
resource "aws_route_table" "public" {
vpc_id = aws_vpc.main.id
route { cidr_block = "0.0.0.0/0", gateway_id = aws_internet_gateway.igw.id }
}
Risks of not separating public and internal networks
If you do not properly separate public and internal components you dramatically increase the attack surface: direct compromise of internet-exposed servers can lead to lateral movement into application and database tiers, data exfiltration of CUI, and failure to meet FAR and CMMC control requirements. Non-compliance can result in contract penalties, loss of government work, and reputational harm. Operational risks include uncontrolled outbound traffic from private instances, lack of traceability, and difficulty demonstrating least-privilege access during audits.
Compliance tips and best practices
Maintain at least these items for compliance readiness: (1) documented network diagrams showing public/private separation and route tables, (2) named and tagged resources for quick evidence queries, (3) VPC Flow Logs and CloudTrail retained for the period required by contract (confirm your FAR clause or DFARS flow-down), (4) use VPC endpoints to avoid unnecessary internet egress, (5) conduct periodic reviews of security groups to remove unused rules, and (6) perform penetration tests targeting the boundary and internal segmentation to validate controls.
In summary, implementing a well-architected VPC that isolates internet-facing resources in public subnets while keeping application and data tiers in private subnets — with correct route tables, NAT, security groups, VPC endpoints, and logging — is a practical, auditable approach to meeting FAR 52.204-21 and CMMC 2.0 Level 1 SC.L1-B.1.XI requirements. Use automation, clear tagging, and monitoring so your small business can demonstrate continuous compliance and minimize the risk of data exposure.
