This post shows practical, audit-oriented steps to design and configure AWS and Azure subnets for public-facing systems so small businesses can meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 Control SC.L1-B.1.XI: separate and protect internet-exposed assets from internal systems while providing required services to the public.
\n\nThe key objective of this Control is to reduce attack surface and limit lateral movement: place internet-facing services in a tightly controlled logical perimeter (a \"DMZ\" or public subnet) and ensure internal systems (datastores, admin consoles) are unreachable directly from the Internet. For Compliance Framework audiences, this means clear network boundaries, enforceable access controls, and logging/evidence that show the segmentation is in place and effective.
\n\nStart with a VPC with a clear CIDR plan (example: VPC 10.0.0.0/16). Create at least two subnets per Availability Zone you use: public subnets for internet-facing load balancers or bastion hosts (10.0.1.0/24), and private subnets for application servers and databases (10.0.2.0/24). Attach an Internet Gateway (IGW) to the VPC and associate a route table for public subnets with 0.0.0.0/0 -> IGW. Private subnets should route outbound to a NAT Gateway placed in a public subnet (so hosts in private subnets can reach updates without receiving inbound connections from the Internet).
\n\nEnforce access with Security Groups (stateful) and NACLs (stateless) as layered controls. Example rules: ALB security group allows inbound TCP 80/443 from 0.0.0.0/0, EC2 web instance security group allows inbound only from the ALB security group, and DB security group allows traffic only from the application security group. Lock SSH/RDP ports to a management bastion IP or use AWS Systems Manager Session Manager (preferred) so you don't expose management ports at all. Enable VPC Flow Logs and CloudTrail for audit evidence; configure an S3 bucket or CloudWatch Log Group with lifecycle and encryption enabled for long-term retention.
\n\nIn Azure, create a VNet (example: 10.1.0.0/16) and define subnets: WebSubnet (10.1.1.0/24) for internet-facing components, AppSubnet (10.1.2.0/24) for app servers, and DataSubnet (10.1.3.0/24) for databases. Use an internet-facing Azure Load Balancer or Application Gateway (select WAF_v2 for additional protection) in the WebSubnet. For outbound access from private subnets, use an Azure NAT Gateway assigned to those subnets so the egress IP(s) are predictable and auditable.
\n\nApply Network Security Groups (NSGs) at subnet and NIC level with rules that allow inbound HTTP/HTTPS to the WebSubnet and deny other inbound flows. Use Azure Bastion for browser-based RDP/SSH to avoid public ports. For stricter east-west filtering and centralized logging, deploy Azure Firewall with an explicit route table (UDR) for private subnets to force traffic through the firewall (and enable diagnostic logs to Log Analytics). Use Azure Monitor/Activity Logs and NSG Flow Logs as evidence for auditors.
\n\nExample architecture for a small contractor hosting a public info site: put an internet-facing Application Load Balancer / Application Gateway in the public subnet (with TLS terminated at the ALB/Gateway using certificates from ACM or Key Vault). Behind it, place web servers in private subnets across AZs with security groups/NSGs allowing only the load balancer. Place the database in a separate private subnet with no public access and restrict DB access to the app security group and specific service accounts. Use a NAT Gateway for outbound updates, and put admin tools (bastion host or SSM/Azure Bastion) in a dedicated management subnet with very restricted access (single office IP or VPN only).
\n\nAutomate and document: codify networks using CloudFormation/Terraform (AWS) or ARM/Bicep (Azure) so deployments are repeatable and auditable. Tag resources consistently (Environment, SystemOwner, Compliance) and store a network diagram and subnet-to-role mapping in your compliance binder. For evidence, collect: route table associations, Security Group/NSG rulesets, VPC Flow Logs/NSG Flow Logs, CloudTrail/Activity Logs, WAF logs, and screenshots or exports of the public IP assignments and load balancer configuration. Use managed services (ALB/WAF/Application Gateway) where possible to reduce custom code and simplify evidence collection.
\n\nFailing to segment public-facing systems increases risk of lateral movement from a compromised web server to internal resources, data exfiltration of sensitive contractor information, and loss of availability. From a compliance standpoint, lack of clear segmentation and logging can lead to audit findings, contract jeopardy under FAR 52.204-21, and inability to demonstrate basic cyber hygiene under CMMC Level 1, potentially affecting contract awards or contract continuation.
\n\nIn summary, meeting SC.L1-B.1.XI for AWS and Azure is a practical mix of good network design (public vs private subnets, NAT for egress), layered controls (security groups/NSGs, NACLs, firewalls), managed front-door services (ALB/Application Gateway + WAF), centralized logging, and repeatable automation/documentation to produce audit evidence—steps that small businesses can implement confidently to reduce risk and stay compliant.
", "plain_text": "This post shows practical, audit-oriented steps to design and configure AWS and Azure subnets for public-facing systems so small businesses can meet the intent of FAR 52.204-21 and CMMC 2.0 Level 1 Control SC.L1-B.1.XI: separate and protect internet-exposed assets from internal systems while providing required services to the public.\n\nWhy subnet segmentation matters for the Compliance Framework\nThe key objective of this Control is to reduce attack surface and limit lateral movement: place internet-facing services in a tightly controlled logical perimeter (a \"DMZ\" or public subnet) and ensure internal systems (datastores, admin consoles) are unreachable directly from the Internet. For Compliance Framework audiences, this means clear network boundaries, enforceable access controls, and logging/evidence that show the segmentation is in place and effective.\n\nAWS: Practical configuration steps\nStart with a VPC with a clear CIDR plan (example: VPC 10.0.0.0/16). Create at least two subnets per Availability Zone you use: public subnets for internet-facing load balancers or bastion hosts (10.0.1.0/24), and private subnets for application servers and databases (10.0.2.0/24). Attach an Internet Gateway (IGW) to the VPC and associate a route table for public subnets with 0.0.0.0/0 -> IGW. Private subnets should route outbound to a NAT Gateway placed in a public subnet (so hosts in private subnets can reach updates without receiving inbound connections from the Internet).\n\nAWS security controls and hardening\nEnforce access with Security Groups (stateful) and NACLs (stateless) as layered controls. Example rules: ALB security group allows inbound TCP 80/443 from 0.0.0.0/0, EC2 web instance security group allows inbound only from the ALB security group, and DB security group allows traffic only from the application security group. Lock SSH/RDP ports to a management bastion IP or use AWS Systems Manager Session Manager (preferred) so you don't expose management ports at all. Enable VPC Flow Logs and CloudTrail for audit evidence; configure an S3 bucket or CloudWatch Log Group with lifecycle and encryption enabled for long-term retention.\n\nAzure: Practical configuration steps\nIn Azure, create a VNet (example: 10.1.0.0/16) and define subnets: WebSubnet (10.1.1.0/24) for internet-facing components, AppSubnet (10.1.2.0/24) for app servers, and DataSubnet (10.1.3.0/24) for databases. Use an internet-facing Azure Load Balancer or Application Gateway (select WAF_v2 for additional protection) in the WebSubnet. For outbound access from private subnets, use an Azure NAT Gateway assigned to those subnets so the egress IP(s) are predictable and auditable.\n\nAzure security controls and hardening\nApply Network Security Groups (NSGs) at subnet and NIC level with rules that allow inbound HTTP/HTTPS to the WebSubnet and deny other inbound flows. Use Azure Bastion for browser-based RDP/SSH to avoid public ports. For stricter east-west filtering and centralized logging, deploy Azure Firewall with an explicit route table (UDR) for private subnets to force traffic through the firewall (and enable diagnostic logs to Log Analytics). Use Azure Monitor/Activity Logs and NSG Flow Logs as evidence for auditors.\n\nSmall-business example: public website with private backend\nExample architecture for a small contractor hosting a public info site: put an internet-facing Application Load Balancer / Application Gateway in the public subnet (with TLS terminated at the ALB/Gateway using certificates from ACM or Key Vault). Behind it, place web servers in private subnets across AZs with security groups/NSGs allowing only the load balancer. Place the database in a separate private subnet with no public access and restrict DB access to the app security group and specific service accounts. Use a NAT Gateway for outbound updates, and put admin tools (bastion host or SSM/Azure Bastion) in a dedicated management subnet with very restricted access (single office IP or VPN only).\n\nCompliance tips, best practices, and audit evidence\nAutomate and document: codify networks using CloudFormation/Terraform (AWS) or ARM/Bicep (Azure) so deployments are repeatable and auditable. Tag resources consistently (Environment, SystemOwner, Compliance) and store a network diagram and subnet-to-role mapping in your compliance binder. For evidence, collect: route table associations, Security Group/NSG rulesets, VPC Flow Logs/NSG Flow Logs, CloudTrail/Activity Logs, WAF logs, and screenshots or exports of the public IP assignments and load balancer configuration. Use managed services (ALB/WAF/Application Gateway) where possible to reduce custom code and simplify evidence collection.\n\nRisk of not implementing subnet separation and controls\nFailing to segment public-facing systems increases risk of lateral movement from a compromised web server to internal resources, data exfiltration of sensitive contractor information, and loss of availability. From a compliance standpoint, lack of clear segmentation and logging can lead to audit findings, contract jeopardy under FAR 52.204-21, and inability to demonstrate basic cyber hygiene under CMMC Level 1, potentially affecting contract awards or contract continuation.\n\nIn summary, meeting SC.L1-B.1.XI for AWS and Azure is a practical mix of good network design (public vs private subnets, NAT for egress), layered controls (security groups/NSGs, NACLs, firewalls), managed front-door services (ALB/Application Gateway + WAF), centralized logging, and repeatable automation/documentation to produce audit evidence—steps that small businesses can implement confidently to reduce risk and stay compliant." }, "metadata": { "description": "Practical, audit-ready steps to design and configure AWS and Azure subnets for public-facing systems to meet FAR 52.204-21 and CMMC 2.0 Level 1 requirements.", "permalink": "/how-to-configure-aws-and-azure-subnets-for-public-facing-systems-practical-implementation-for-far-52204-21-cmmc-20-level-1-control-scl1-b1xi.json", "categories": [], "tags": [] } }