This post explains how to design and deploy a secure DMZ (demilitarized zone) in AWS and Azure to isolate public-facing components, meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 Control SC.L1-B.1.XI, and produce the technical evidence auditors expect from a small business.
What the control requires and a small-business scenario
At Level 1 the goal of SC.L1-B.1.XI is straightforward: public-facing systems (websites, APIs, load balancers) must be isolated from internal systems that process, store, or transmit Controlled Unclassified Information (CUI) or other sensitive assets. For a small SaaS business this typically means: put public web servers and reverse proxies in a DMZ, keep app servers and databases in private subnets, and strictly control and log the traffic that crosses those boundaries. The minimal evidence auditors look for includes architecture diagrams, network rules (security groups/NSGs), proof of logging/monitoring, and documented access control practices.
AWS: practical DMZ architecture and implementation steps
Design: create a VPC with at least three subnet tiers (public DMZ subnets for ALB/ALBs, private application subnets for app servers, and database subnets for RDS). Put an Internet Gateway (IGW) on the VPC and route only the DMZ subnets to the IGW. Place an ALB (Application Load Balancer) or CloudFront + ALB in the DMZ; ALB targets are private EC2s or ECS tasks in private subnets. For controlled egress use a NAT Gateway in a dedicated public subnet so private subnets can reach the internet for patching without exposing inbound connections. Use Security Groups to allow only required ports (e.g., ALB: 80/443; app SG: allow inbound from ALB SG only on app ports; DB SG: allow inbound from app SG only). Add NACLs as a secondary, stateless filter if you need whitelisting by IP ranges.
AWS specific technical details and tips
Enable AWS WAF on the ALB (or CloudFront) and use AWS Shield Standard (automatically enabled) for basic DDoS protection. Avoid SSH/ RDP exposure—use Session Manager (SSM) for shell access to EC2 without public IPs. Turn on VPC Flow Logs and send them to CloudWatch Logs or S3, enable CloudTrail for account activity, and enable ALB access logs to an encrypted S3 bucket. Use IAM least-privilege for service roles and Secrets Manager for DB credentials. Sample commands: create VPC Flow Logs with the CLI (aws ec2 create-flow-logs ...) and start a secure session with SSM (aws ssm start-session --target i-0123456789abcdef0) instead of opening port 22 to the world.
Azure: practical DMZ architecture and implementation steps
Design in Azure follows similar principles using Virtual Networks (VNets). Create separate subnets for the DMZ (Application Gateway/WAF or Azure Front Door), application tier, and data tier. Use an Application Gateway with WAF v2 in the DMZ subnet to terminate TLS and forward traffic to backend pools in private subnets. For outbound connectivity from private subnets, use NAT Gateway or forced tunneling through Azure Firewall (or a network virtual appliance) rather than giving VMs public IPs. Use Azure Bastion or Privileged Access Workstations plus Just-In-Time (JIT) if you must support RDP/SSH access.
Azure specific technical details and tips
Apply Network Security Groups (NSGs) to subnet and/or NIC level with deny-by-default rules, and consider layered filtering with Azure Firewall or an NVA to centralize logging and allow FQDN-based filtering for PaaS access. Use Private Link for PaaS resources (Azure SQL, Storage) so services remain on the Microsoft backbone. Enable Azure Diagnostic Logs, NSG flow logs to Log Analytics, and retain logs for the period mandated by FAR/CMMC policy. Use Azure Policy to enforce forbidden configurations (e.g., no public IP on DB servers) and record compliance state as audit evidence.
Operational controls, automation, and audit evidence
Operationalize the DMZ with these actions: enforce identity controls (MFA for console access, RBAC/least privilege), automated patching for hosts or use managed services (ECS/Fargate, Azure App Service) to reduce patch burden, regular vulnerability scanning of public endpoints, and scheduled penetration testing on the DMZ. Automate deployments with Infrastructure as Code (Terraform, ARM/Bicep) to produce versioned artifacts auditors can review. Use policy-as-code (AWS Config rules, Azure Policy initiatives) to continuously detect drift and produce compliance reports. Maintain runbooks and incident response playbooks that include DMZ isolation steps and log-retention evidence.
Risk of not isolating public components
Failing to implement a DMZ increases the risk of lateral movement from a compromised public host to internal systems, data exfiltration, and accidental exposure of sensitive data. Real-world impacts include lost contracts, regulatory fines, and reputational damage—examples include web servers with misconfigured security groups that allowed direct DB access or leaked credentials in instance metadata leading to cloud resource takeover. For small businesses, even a single breach can cause contract termination under FAR clauses and loss of eligibility for government work.
Compliance tips and best practices
Keep your evidence checklist handy: network diagrams showing subnets and routing, screenshots or CSV export of security group/NSG rules, log configuration and retention settings, WAF rule sets and alerts, IAM/RBAC policy snapshots, and vulnerability scan or pentest reports. Use least-privilege and remove default wide-open rules. Prefer managed services (CloudFront/Front Door + WAF, RDS/Azure SQL with no public endpoint) to reduce the audit surface. Schedule quarterly reviews, and maintain a one-page mapping of design elements to SC.L1-B.1.XI so auditors quickly see how you isolate public components.
In summary, building a secure DMZ for FAR 52.204-21 / CMMC 2.0 Level 1 compliance is achievable for small businesses by applying clear segmentation (public DMZ, private app, DB tiers), strict ingress/egress controls (security groups/NSGs, WAF, NAT/Gateway), comprehensive logging and monitoring, and automation to produce repeatable, auditable evidence. Implementing these measures reduces risk and creates the artifacts auditors require to demonstrate that public-facing components are isolated from internal systems.
