A cloud DMZ (demilitarized zone) isolates public-facing services from internal systems and is a practical way to satisfy boundary-protection and basic safeguarding expectations in FAR 52.204-21 and CMMC 2.0 Level 1 (SC.L1-B.1.XI); this post shows how to design and implement a compliant DMZ in AWS and Azure using Security Groups (SGs), Network ACLs (NACLs) / Network Security Groups (NSGs), logging, and operational controls tailored for small businesses.
Design principles and compliance objectives
At the core of a compliant DMZ are a few simple principles: minimize attack surface, apply defense-in-depth, log network flows and configuration changes, and enforce least privilege. For FAR 52.204-21 and CMMC Level 1 you should be able to demonstrate that public traffic is segregated from internal networks, that access paths are limited and logged, and that administrative and remote access to systems storing or processing Federal Contract Information (FCI) is restricted. Implement these by combining cloud-native stateful controls (Security Groups / NSGs), stateless subnet-level filters (AWS NACLs), perimeter services (WAF, managed firewall), and continuous logging/monitoring.
AWS: practical DMZ architecture and rules
Typical AWS DMZ components: a VPC with public subnet(s) for load balancers or bastion entry points, private subnets for application and data tiers, an Internet Gateway for public subnets, NAT Gateways for outbound-only access from private subnets, an Application Load Balancer (ALB) or CloudFront + WAF in front of web services, Security Groups applied to instances and ALBs, and NACLs applied to subnets. Implementation notes specific to compliance: 1) Keep a default deny posture for SGs and only open required ports; 2) Use NACLs to block obvious bad traffic at the subnet boundary and to create a fail-safe deny-all rule; 3) Enable VPC Flow Logs (send to CloudWatch Logs or S3) and retain them per your data retention policy. Example SG/NACL configuration: Security Group for ALB - inbound TCP 443 from 0.0.0.0/0 (or a restricted set if possible), outbound allow to backend SG on port 443; Backend instance SG - inbound TCP 443 from ALB SG (use the ALB SG ID as source), outbound ephemeral ports 1024-65535 to ALB SG. NACL example for the public DMZ subnet: rule 100 ALLOW TCP 80,443 from 0.0.0.0/0; rule 110 ALLOW ephemeral ports 1024-65535 for ephemeral replies; final rule 32767 DENY ALL. AWS CLI examples: aws ec2 create-security-group --group-name DMZ-ALB --description "ALB SG" --vpc-id vpc-012345 and aws ec2 authorize-security-group-ingress --group-id sg-abc123 --protocol tcp --port 443 --cidr 0.0.0.0/0. For NACLs use aws ec2 create-network-acl and aws ec2 create-network-acl-entry with explicit inbound and outbound rules (remember NACLs are stateless: you must create both directions).
Azure: practical DMZ architecture and rules
In Azure, the equivalent building blocks are Virtual Networks (VNets) with subnets, Network Security Groups (NSGs) as stateful filters attached to subnets or NICs, Azure Firewall or a third-party virtual appliance for centralized policy, Application Gateway with WAF for web protection, and Azure Bastion or Just-In-Time access for administration. Implementation specifics: use NSGs for fine-grained allow/deny rules and Azure Firewall for centralized egress filtering and logging if budget allows. Example NSG rules: priority 100 Allow inbound TCP 443 from Internet to subnet FrontEnd; priority 200 Allow inbound TCP from AppGatewaySubnet to AppSubnet on 443; default rule (higher number) deny all other inbound traffic. Azure CLI example: az network nsg create -g rg-prod -n DMZ-NSG and az network nsg rule create -g rg-prod --nsg-name DMZ-NSG -n Allow-Web --priority 100 --source-address-prefixes Internet --direction Inbound --access Allow --protocol Tcp --destination-port-ranges 443. Enable NSG flow logs in Network Watcher and route logs to a Log Analytics workspace for retention and alerting to satisfy evidence requirements.
Implementation details: stateful vs stateless, rules ordering, and logging
Security Groups (AWS) and NSGs (Azure) are stateful — reply traffic is allowed automatically — so they are the right tool for host-level filtering. NACLs are stateless and evaluate rules by rule number; they are best used as a coarse-grained subnet boundary control and for explicit deny patterns (e.g., block specific botnet IP ranges). Important technical details: in AWS NACLs, lower rule number is evaluated first and you must create both inbound and outbound entries for traffic to flow; include explicit ephemeral port allowances for return traffic. In Azure NSGs, priority is numeric (100 = high priority), and there are default system rules; do not rely on defaults — create explicit allow rules for required flows and then explicit deny rules to lock down everything else. Always enable flow logs (VPC Flow Logs / NSG flow logs) and send them to a centralized store; tie them to automated alerts and keep an immutable retention for the compliance period. Also enable host-level logging (CloudWatch / Azure Monitor) and record IAM changes, security group/NSG/NACL modifications as audit evidence.
Small-business scenario and real-world examples
Example: a small defense contractor hosts a bid submission portal with FCI data. Architecture: ALB in public subnet with WAF → Web servers in private subnets → Database in a separate private subnet. Implementation: ALB SG allows inbound TCP 443 from 0.0.0.0/0 (Web is public) and logs to CloudWatch; Web server SG allows inbound TCP 443 only from ALB SG; DB SG allows MySQL only from Web server SG. NACLs on the public subnet deny known-malicious IP blocks and allow only 80/443 inbound. Administrative access is only via SSM Session Manager (no SSH exposed) or Azure Bastion, with MFA enforced on console accounts. Logging: VPC Flow Logs + CloudTrail for config changes; retention 1 year (or your policy). Demonstrable compliance artifacts: architecture diagram, SG/NSG rule export, flow logs for a retention window, IAM policy attachments showing least privilege, and runbook showing how to respond to a suspected incident.
Compliance tips, best practices, and automation
Practical tips: 1) Use Infrastructure-as-Code (Terraform, CloudFormation, ARM/Bicep) so you can version and produce change history for SG/NSG/NACL rules; 2) Apply tagging standards to map resources to contracts and systems processing FCI; 3) Enforce least privilege with IAM roles and temporary credentials; 4) Use managed services (WAF, DDoS protection, managed Firewalls) where possible to reduce operational burden; 5) Regularly review and prune rules (quarterly reviews are a good cadence); 6) Implement alerting for changes to SG/NSG/NACL rules and for anomalous flow log patterns. For evidence collection build automated exports: daily snapshot of SG/NSG rules plus flow log retention metrics into a compliance bucket or workspace. Finally, document assumed risk: if you accept public traffic, demonstrate compensating controls like WAF and rate limiting to satisfy auditors.
Risks of non-implementation and summary
Not implementing a segregated DMZ with properly scoped SGs/NSGs and NACLs exposes you to lateral movement, data exfiltration, and unauthorized access to systems processing FCI; this can lead to contract penalties, loss of contracts, and regulatory scrutiny. In short: build a minimal public-facing surface, enforce strict SG/NSG rules, use NACLs as a subnet hardening layer, centralize and retain logs, automate deployment and evidence collection, and document controls and review cycles. Following the patterns above will help a small business demonstrate compliance with FAR 52.204-21 and CMMC 2.0 Level 1 control SC.L1-B.1.XI while keeping operational overhead manageable.
