Controlled Unclassified Information (CUI) represents the largest category of sensitive federal data — and the one most frequently handled by defense contractors, federal agencies, and their technology partners. Building a cloud environment that properly handles CUI means satisfying NIST SP 800-171, which is the baseline for CMMC Level 2, and doing it in a way that doesn't create audit debt that takes months to remediate before an assessment.
This article describes the architecture decisions that matter for CUI enclave design on AWS GovCloud.
What CUI Requires: The Regulatory Baseline
CUI handling requirements are defined in NIST SP 800-171 Rev 2 — 110 security requirements across 14 families (Access Control, Audit and Accountability, Configuration Management, etc.). CMMC Level 2 maps almost directly to these 110 requirements.
Key implications for cloud architecture:
- Access to CUI must be controlled to authorized users — role-based, least-privilege
- CUI must be encrypted at rest and in transit
- All access to CUI must be audited — who touched what, when, and from where
- The system must be able to detect and report incidents within 72 hours (DFARS 252.204-7012)
- Backups of CUI must be protected with equivalent controls
What this means in architectural terms: every design decision — IAM policy, encryption configuration, logging configuration, network boundary — must map to a control requirement. Design first, audit later is the wrong approach. Controls-as-code from day one is the right one.
The CUI Enclave: Design Principles
A CUI cloud enclave is a logically (and in some cases physically) isolated environment where CUI is stored, processed, and transmitted, with a well-defined boundary of controls.
Principle 1: Explicit boundary definition
The enclave boundary must be documented and enforced. In AWS, this means:
- A dedicated AWS account for CUI workloads — not mixed with lower-sensitivity systems in the same account
- VPC with no public subnets for CUI data stores
- Private endpoints for all AWS service access (S3, KMS, Secrets Manager, etc.) — no public API calls that cross the internet
Principle 2: No long-lived credentials inside the enclave
Service-to-service authentication should use IAM roles with instance profiles or EKS service accounts (IRSA), never static access keys. Humans authenticate through federation — IAM Identity Center or an approved IdP. Zero long-lived credentials means zero credential compromise risk.
Principle 3: Every access is audited
CloudTrail must be enabled in all regions — including GovCloud regions — with immutable log storage (S3 with Object Lock, MFA delete enabled). CloudWatch Logs for application-level access events. VPC Flow Logs for network-level audit trail. Disabling audit logging in a CUI enclave is a NIST 800-171 violation.
Terraform Architecture for a CUI Enclave
# CUI Account network foundation
module "cui_vpc" {
source = "terraform-aws-modules/vpc/aws"
name = "cui-enclave"
cidr = "10.0.0.0/16"
azs = ["us-gov-west-1a", "us-gov-west-1b"]
private_subnets = ["10.0.1.0/24", "10.0.2.0/24"]
# No public subnets — all CUI systems on private subnets only
enable_nat_gateway = false # No internet egress for CUI tier
enable_vpn_gateway = true # Site-to-site VPN for network connectivity
}
# S3 bucket for CUI with required controls
resource "aws_s3_bucket" "cui_data" {
bucket = "cui-enclave-${var.environment}"
}
resource "aws_s3_bucket_server_side_encryption_configuration" "cui_data" {
bucket = aws_s3_bucket.cui_data.id
rule {
apply_server_side_encryption_by_default {
sse_algorithm = "aws:kms"
kms_master_key_id = aws_kms_key.cui_key.arn
}
bucket_key_enabled = true
}
}
resource "aws_s3_bucket_public_access_block" "cui_data" {
bucket = aws_s3_bucket.cui_data.id
block_public_acls = true
block_public_policy = true
ignore_public_acls = true
restrict_public_buckets = true
}The KMS key used for CUI encryption should be a customer-managed key (CMK) — not the default AWS-managed key — so that key access is explicitly controlled and auditable.
Access Control for CUI: IAM Design
NIST 800-171 requires access control based on least privilege and need-to-know. IAM implementation:
Role taxonomy for CUI access:
cui-reader— read-only access to CUI data (analysts, auditors)cui-writer— read-write access (application service roles only — not humans directly)cui-admin— administrative access (break-glass role, requires MFA, every use generates an alert)
Policy structure:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["s3:GetObject", "s3:ListBucket"],
"Resource": [
"arn:aws-us-gov:s3:::cui-enclave-prod",
"arn:aws-us-gov:s3:::cui-enclave-prod/*"
],
"Condition": {
"StringEquals": {
"aws:RequestedRegion": "us-gov-west-1"
},
"Bool": {
"aws:SecureTransport": "true"
}
}
}
]
}The aws:SecureTransport condition enforces HTTPS on every S3 API call — a FIPS TLS requirement for CUI.
Incident Response Architecture
DFARS 252.204-7012 requires defense contractors to report cyber incidents affecting CUI within 72 hours of discovery. The architecture must support rapid detection and notification:
Detection stack:
- AWS GuardDuty — threat detection with GovCloud support
- AWS Security Hub — aggregated findings across services, mapped to NIST 800-53 controls
- Custom EventBridge rules for high-priority events (root login, IAM policy changes, S3 public access attempt)
Response automation:
- EventBridge → Lambda → automated containment (isolate affected instance, rotate compromised credentials)
- SNS → PagerDuty/Slack for human notification pipeline
- CloudTrail → SIEM export for forensic timeline reconstruction
The 72-hour reporting clock starts at discovery — automated alerting that fires within minutes of indicator of compromise is the architecture goal. See our guide on DFARS 252.204-7012 compliance architecture for the full incident reporting framework.
CUI Marking in Cloud Environments
NIST 800-171 requires CUI to be marked consistent with 32 CFR Part 2002. In cloud systems, marking manifests as:
- Object-level metadata tags — S3 object tags with CUI designation (
CUI: Basic/SP-6) - Database record attributes — schema-level classification fields on tables containing CUI
- API response headers — classification labels on API responses returning CUI data
- User interface indicators — classification banners on screens displaying CUI
Automated CUI marking at ingest is cleaner than relying on users to tag correctly. Data classification tooling (Amazon Macie for PII detection, custom Lambda functions for CUI pattern matching) can apply marks automatically and alert when unmarked data appears in CUI zones.
What This Looks Like in Production
Rutagon builds CUI enclave architectures using GovCloud-native Terraform modules — private-only VPC topology, CMK encryption with automated key rotation, CloudTrail with S3 Object Lock, and control mapping documentation that maps every design decision to the NIST 800-171 requirement it satisfies. The output isn't just a running system — it's an auditable architecture that supports the ATO process.
Discuss CUI enclave requirements with Rutagon → rutagon.com/government
Frequently Asked Questions
What is a CUI enclave?
A CUI enclave is a cloud environment specifically designed and authorized to store, process, and transmit Controlled Unclassified Information. It has a defined security boundary, enforced access controls, encryption requirements, and audit logging — all mapped to NIST SP 800-171 or CMMC Level 2 requirements.
Does AWS GovCloud satisfy CUI requirements automatically?
No. AWS GovCloud provides the physical isolation and service capabilities needed for CUI, but the customer is responsible for configuring the environment correctly — encryption, access controls, audit logging, and boundary protections. AWS's FedRAMP High authorization covers the infrastructure layer; the application and data layers are the customer's responsibility.
How many controls does NIST 800-171 have?
NIST SP 800-171 Rev 2 has 110 security requirements across 14 families. CMMC Level 2 maps almost directly to these 110 requirements. A system security plan (SSP) must document how each requirement is implemented or planned — see our article on SSP automation for how Rutagon automates this documentation.
What is the difference between CUI Basic and CUI Specified?
CUI Basic requires the baseline NIST 800-171 controls. CUI Specified is a subset of CUI categories where the originating agency requires additional handling controls beyond the baseline. Which category applies depends on the type of information — the CUI Registry at the National Archives defines all categories and their handling requirements.
Do I need a separate AWS account for CUI?
Using a dedicated AWS account for CUI workloads is the strongest isolation posture and simplifies compliance — resource-based policies, audit scope, and account-level controls apply cleanly to the CUI boundary. Multi-account architectures managed through AWS Organizations with Service Control Policies (SCPs) are the standard approach.
Discuss your project with Rutagon
Contact Us →