This tutorial shows step-by-step how a small organization can build physical and logical subnetworks on AWS to satisfy SC.L1-B.1.XI (the basic safeguarding requirement called out by FAR 52.204-21 and mapped to CMMC 2.0 Level 1), including concrete VPC/subnet designs, access controls, monitoring, and real-world examples you can implement today.
\n\nAt Level 1 the Compliance Framework requires basic safeguarding of controlled unclassified information (CUI) from unauthorized access and disclosure. Practically this means you must separate and protect systems that store or process CUI from general-purpose networks, limit network exposure, and have logging/monitoring to detect access. On AWS that translates into account-level isolation, dedicated VPCs and subnets, hardened routing and security group design, and comprehensive logging (CloudTrail, VPC Flow Logs, Config).
\n\nOn cloud providers \"physical\" isolation is proprietary to the provider (you cannot rewire racks) but you achieve equivalent assurance by separating workloads across AWS accounts and optionally using Dedicated Hosts/Instances where contractually needed. \"Logical\" isolation is implemented with VPCs, subnets, security groups, NACLs, route tables, and managed endpoints. For a small business, the recommended approach to meet SC.L1-B.1.XI is: (1) a separate AWS account for CUI, (2) a dedicated VPC in that account, (3) private subnets for CUI workloads with no direct inbound Internet access, and (4) controlled egress via NAT or proxies plus strict security groups and endpoint-only S3/SNS access.
\n\nBelow is a practical blueprint. Replace CIDRs and names to match your environment. For a simple small-business layout use one account for CUI and one for general IT:
\n\n1) Create an AWS Organization and a dedicated CUI AWS account. Put guardrails in place with Service Control Policies (SCPs) that restrict regions and disallow deletion of CloudTrail trails.
\n\n2) Create a VPC in the CUI account, for example 10.10.0.0/16, and carve subnets per AZ: public (10.10.1.0/24) for bastion/NAT, private-app (10.10.2.0/24) for application servers, private-db (10.10.3.0/24) for databases. Example Terraform snippet:
\n\n# Terraform (abbreviated)\nresource \"aws_vpc\" \"cui_vpc\" {\n cidr_block = \"10.10.0.0/16\"\n enable_dns_support = true\n enable_dns_hostnames = true\n}\n\nresource \"aws_subnet\" \"public_a\" {\n vpc_id = aws_vpc.cui_vpc.id\n cidr_block = \"10.10.1.0/24\"\n availability_zone = \"us-east-1a\"\n map_public_ip_on_launch = true\n}\n# create private_app and private_db subnets similarly\n3) Networking: attach an Internet Gateway (IGW) only to the public subnet route table, create a NAT Gateway in the public subnet to allow controlled outbound access from private subnets, and create route tables so private subnets route 0.0.0.0/0 to the NAT. Restrict inbound routes to only what is necessary.
\n\n4) Access controls: use Security Groups (stateful) for host-level access and NACLs (stateless) as an extra layer. Example SG setup: a \"bastion\" SG permits SSH from your corporate IP; application SG only allows inbound from bastion SG or an ALB SG on required ports; database SG allows inbound only from application SG on DB port (e.g., 5432). Avoid SSH-open-to-internet patterns — prefer Systems Manager (SSM) Session Manager for shell access without an open port.
\n\nEnable VPC Gateway Endpoints for S3 and DynamoDB so private subnets can access S3 without traversing the Internet. Restrict S3 bucket policies to the VPC endpoint and the CUI account. Use a KMS CMK in the CUI account for encryption of S3 and EBS volumes and set key policies to limit administration and usage to authorized roles only. Example S3 bucket policy snippet limiting access to a VPC endpoint:
\n\n{\n \"Version\":\"2012-10-17\",\n \"Statement\":[\n {\n \"Effect\":\"Deny\",\n \"Principal\":\"*\",\n \"Action\":\"s3:*\",\n \"Resource\":[\"arn:aws:s3:::cui-bucket\",\"arn:aws:s3:::cui-bucket/*\"],\n \"Condition\":{\n \"StringNotEquals\":{\n \"aws:sourceVpce\":\"vpce-0123456789abcdef0\"\n }\n }\n }\n ]\n}\nTurn on CloudTrail with multi-region logging and send logs to a dedicated, immutable S3 bucket with MFA Delete (where supported) and a retention/back-up policy. Enable VPC Flow Logs for the CUI VPC and ship to CloudWatch Logs or S3 for retention. Enable AWS Config with rules that monitor for public S3 buckets, public security groups, and whether encryption is enabled; use GuardDuty for threat detection. These controls provide the audit evidence required by FAR 52.204-21 and CMMC assessments.
\n\nExample: a 10-person subcontractor storing CUI for a prime. They create a single CUI account and the described VPC: no Internet-facing app servers, all management done through SSM and an approved bastion in a hardened management VPC. S3 contains CUI artifacts accessible only via VPC endpoint, and a KMS key rotates annually. Automated Terraform modules create the VPC, subnets, NAT, endpoints, and security groups, and a CI job validates AWS Config rules before changes are applied. This setup is low-cost (one NAT gateway, one small RDS instance) and meets the intent of SC.L1-B.1.XI for separation and evidenced control.
\n\nIf you don't implement physical or logical separation you increase the risk of accidental exposure and unauthorized access — e.g., a public security group or misconfigured S3 bucket could leak CUI. Non-isolated accounts make it harder to revoke access, produce audit logs, or demonstrate chain-of-custody during an assessment. Consequences include contract termination, inability to compete for government work, reputational damage, and potential regulatory penalties.
\n\nAutomate baseline provisioning with Terraform or CloudFormation and include AWS Config rules and GuardDuty. Use IaC for repeatable evidence in assessments. Prefer SSM Session Manager over SSH, restrict IAM with least privilege, enforce MFA for all human users, and rotate keys and access tokens. Maintain up-to-date network diagrams and a Controls Implementation Summary (mapping architecture elements to SC.L1-B.1.XI). Schedule quarterly reviews of security groups and a monthly review of VPC Flow Logs for anomalies.
\n\nIn summary, meeting SC.L1-B.1.XI on AWS is achievable for small businesses by combining account-level separation (physical-equivalent isolation), a dedicated VPC with well-designed private subnets (logical isolation), endpoint-only service access, strict SG/NACL rules, centralized logging, and automated guardrails. Implement the blueprint above, document decisions, and automate evidence collection to make assessments straightforward and reduce risk.
", "plain_text": "This tutorial shows step-by-step how a small organization can build physical and logical subnetworks on AWS to satisfy SC.L1-B.1.XI (the basic safeguarding requirement called out by FAR 52.204-21 and mapped to CMMC 2.0 Level 1), including concrete VPC/subnet designs, access controls, monitoring, and real-world examples you can implement today.\n\nWhat SC.L1-B.1.XI expects (high level)\nAt Level 1 the Compliance Framework requires basic safeguarding of controlled unclassified information (CUI) from unauthorized access and disclosure. Practically this means you must separate and protect systems that store or process CUI from general-purpose networks, limit network exposure, and have logging/monitoring to detect access. On AWS that translates into account-level isolation, dedicated VPCs and subnets, hardened routing and security group design, and comprehensive logging (CloudTrail, VPC Flow Logs, Config).\n\nDesign principles: physical vs logical isolation on AWS\nOn cloud providers \"physical\" isolation is proprietary to the provider (you cannot rewire racks) but you achieve equivalent assurance by separating workloads across AWS accounts and optionally using Dedicated Hosts/Instances where contractually needed. \"Logical\" isolation is implemented with VPCs, subnets, security groups, NACLs, route tables, and managed endpoints. For a small business, the recommended approach to meet SC.L1-B.1.XI is: (1) a separate AWS account for CUI, (2) a dedicated VPC in that account, (3) private subnets for CUI workloads with no direct inbound Internet access, and (4) controlled egress via NAT or proxies plus strict security groups and endpoint-only S3/SNS access.\n\nHands-on implementation (step-by-step)\nBelow is a practical blueprint. Replace CIDRs and names to match your environment. For a simple small-business layout use one account for CUI and one for general IT:\n\n1) Create an AWS Organization and a dedicated CUI AWS account. Put guardrails in place with Service Control Policies (SCPs) that restrict regions and disallow deletion of CloudTrail trails.\n\n2) Create a VPC in the CUI account, for example 10.10.0.0/16, and carve subnets per AZ: public (10.10.1.0/24) for bastion/NAT, private-app (10.10.2.0/24) for application servers, private-db (10.10.3.0/24) for databases. Example Terraform snippet:\n\n# Terraform (abbreviated)\nresource \"aws_vpc\" \"cui_vpc\" {\n cidr_block = \"10.10.0.0/16\"\n enable_dns_support = true\n enable_dns_hostnames = true\n}\n\nresource \"aws_subnet\" \"public_a\" {\n vpc_id = aws_vpc.cui_vpc.id\n cidr_block = \"10.10.1.0/24\"\n availability_zone = \"us-east-1a\"\n map_public_ip_on_launch = true\n}\n# create private_app and private_db subnets similarly\n\n\n3) Networking: attach an Internet Gateway (IGW) only to the public subnet route table, create a NAT Gateway in the public subnet to allow controlled outbound access from private subnets, and create route tables so private subnets route 0.0.0.0/0 to the NAT. Restrict inbound routes to only what is necessary.\n\n4) Access controls: use Security Groups (stateful) for host-level access and NACLs (stateless) as an extra layer. Example SG setup: a \"bastion\" SG permits SSH from your corporate IP; application SG only allows inbound from bastion SG or an ALB SG on required ports; database SG allows inbound only from application SG on DB port (e.g., 5432). Avoid SSH-open-to-internet patterns — prefer Systems Manager (SSM) Session Manager for shell access without an open port.\n\nMinimize data exposure with endpoints, KMS, and least privilege\nEnable VPC Gateway Endpoints for S3 and DynamoDB so private subnets can access S3 without traversing the Internet. Restrict S3 bucket policies to the VPC endpoint and the CUI account. Use a KMS CMK in the CUI account for encryption of S3 and EBS volumes and set key policies to limit administration and usage to authorized roles only. Example S3 bucket policy snippet limiting access to a VPC endpoint:\n\n{\n \"Version\":\"2012-10-17\",\n \"Statement\":[\n {\n \"Effect\":\"Deny\",\n \"Principal\":\"*\",\n \"Action\":\"s3:*\",\n \"Resource\":[\"arn:aws:s3:::cui-bucket\",\"arn:aws:s3:::cui-bucket/*\"],\n \"Condition\":{\n \"StringNotEquals\":{\n \"aws:sourceVpce\":\"vpce-0123456789abcdef0\"\n }\n }\n }\n ]\n}\n\n\nLogging, monitoring, and evidence-gathering\nTurn on CloudTrail with multi-region logging and send logs to a dedicated, immutable S3 bucket with MFA Delete (where supported) and a retention/back-up policy. Enable VPC Flow Logs for the CUI VPC and ship to CloudWatch Logs or S3 for retention. Enable AWS Config with rules that monitor for public S3 buckets, public security groups, and whether encryption is enabled; use GuardDuty for threat detection. These controls provide the audit evidence required by FAR 52.204-21 and CMMC assessments.\n\nReal-world small business scenario\nExample: a 10-person subcontractor storing CUI for a prime. They create a single CUI account and the described VPC: no Internet-facing app servers, all management done through SSM and an approved bastion in a hardened management VPC. S3 contains CUI artifacts accessible only via VPC endpoint, and a KMS key rotates annually. Automated Terraform modules create the VPC, subnets, NAT, endpoints, and security groups, and a CI job validates AWS Config rules before changes are applied. This setup is low-cost (one NAT gateway, one small RDS instance) and meets the intent of SC.L1-B.1.XI for separation and evidenced control.\n\nRisks of non-implementation and compliance pitfalls\nIf you don't implement physical or logical separation you increase the risk of accidental exposure and unauthorized access — e.g., a public security group or misconfigured S3 bucket could leak CUI. Non-isolated accounts make it harder to revoke access, produce audit logs, or demonstrate chain-of-custody during an assessment. Consequences include contract termination, inability to compete for government work, reputational damage, and potential regulatory penalties.\n\nCompliance tips and best practices\nAutomate baseline provisioning with Terraform or CloudFormation and include AWS Config rules and GuardDuty. Use IaC for repeatable evidence in assessments. Prefer SSM Session Manager over SSH, restrict IAM with least privilege, enforce MFA for all human users, and rotate keys and access tokens. Maintain up-to-date network diagrams and a Controls Implementation Summary (mapping architecture elements to SC.L1-B.1.XI). Schedule quarterly reviews of security groups and a monthly review of VPC Flow Logs for anomalies.\n\nIn summary, meeting SC.L1-B.1.XI on AWS is achievable for small businesses by combining account-level separation (physical-equivalent isolation), a dedicated VPC with well-designed private subnets (logical isolation), endpoint-only service access, strict SG/NACL rules, centralized logging, and automated guardrails. Implement the blueprint above, document decisions, and automate evidence collection to make assessments straightforward and reduce risk." }, "metadata": { "description": "A practical, hands-on guide showing how small businesses can design AWS account/VPC/subnet architectures, networking controls, and monitoring to meet SC.L1-B.1.XI (FAR 52.204-21 / CMMC 2.0 Level 1) basic safeguarding requirements.", "permalink": "/how-to-build-physical-and-logical-subnetworks-on-aws-to-meet-scl1-b1xi-far-52204-21-cmmc-20-level-1-control-scl1-b1xi-hands-on-tutorial.json", "categories": [], "tags": [] } }