The Department of Defense uses impact levels (ILs) to categorize the sensitivity of data and set the minimum security controls required for the cloud systems that process it. For contractors and government teams building cloud environments, IL4 and IL5 represent a meaningful architecture boundary — they're the first levels that deal with Controlled Unclassified Information (CUI) and National Security Systems (NSS) data respectively.
Getting the architecture right before an Assessment and Authorization (A&A) review is significantly cheaper than remediating it after. This article describes the structural requirements for IL4 and IL5 cloud environments and the design decisions that matter most.
What IL4 and IL5 Mean
The DoD Cloud Computing Security Requirements Guide (SRG) defines impact levels by the type of information a system processes:
- IL2: Public data and low-sensitivity information — most commercial cloud providers can satisfy this
- IL4: Controlled Unclassified Information (CUI) — requires GovCloud or equivalent isolation; commercial cloud with enhanced controls
- IL5: CUI requiring higher protection, National Security Systems, and some mission-critical unclassified data — requires physical isolation from non-DoD tenants
The gap between IL4 and IL5 is material: IL5 adds US-person access controls, physical isolation from non-DoD workloads, and in practice means AWS GovCloud (US) or another FedRAMP High-authorized environment is required.
Foundational Architecture Differences: IL4 vs. IL5
Network Isolation
At IL4, network isolation can be achieved through logical controls: dedicated VPCs, security group policies that enforce least-privilege traffic, and private endpoints for AWS service access. Commercial AWS East/West regions can satisfy IL4 when properly configured.
At IL5, physical isolation from non-DoD tenants is required. AWS GovCloud (US-East and US-West) meets this requirement — the infrastructure is physically separate from AWS commercial regions and accessible only to US citizens. Architecture in GovCloud requires rebuilding any dependencies that rely on cross-region resources or commercial-region AWS services not mirrored in GovCloud.
US-Person Access Controls
IL5 adds an explicit requirement: access to IL5 systems must be limited to US persons. This affects:
- IAM identity management — federated identity providers must be configured to enforce citizenship-based access. DoD PKI or ICAM-compliant identity providers are the standard path.
- CI/CD pipelines — automation accounts and pipeline runners must be operated by US persons only. OIDC-federated pipelines with scoped role assumptions support this when the underlying identity provider enforces citizenship attributes.
- Support and operations — vendor support tickets, AWS Support access, and any console access must flow through US-person controlled accounts.
FIPS 140-2 Cryptography
Both IL4 and IL5 require FIPS 140-2 validated cryptographic modules, but at IL5 this is more strictly enforced across all data paths. In AWS GovCloud, this requires:
- Enabling FIPS endpoints for all API calls (available at
{service}-fips.{region}.amazonaws.com) - Using FIPS-compliant TLS cipher suites — TLS 1.2 minimum with approved cipher suites
- Ensuring encryption keys are managed through AWS KMS with FIPS-validated hardware security modules
A common gap: teams configure FIPS endpoints for the primary application but miss secondary integrations — S3 event notifications, CloudWatch API calls from Lambda functions, SQS polling. Every API call must traverse a FIPS endpoint.
Reference Architecture: Multi-IL Environment
Many government systems need to support both IL4 and IL5 workloads — processing some data under one classification and other data under another. The cleanest architecture uses separate AWS accounts at each impact level:
┌─────────────────────────────────────────────┐
│ GovCloud (US) Organization │
│ │
│ ┌──────────────┐ ┌───────────────────┐ │
│ │ IL5 Account │ │ IL4 Account │ │
│ │ (NSS/CUI) │ │ (CUI) │ │
│ │ │ │ │ │
│ │ Isolated │ │ Logically │ │
│ │ VPC │ │ Isolated VPC │ │
│ │ │ │ │ │
│ └──────┬──────┘ └────────┬──────────┘ │
│ │ │ │
│ ┌──────▼───────────────────▼──────────┐ │
│ │ Shared Services Account │ │
│ │ (Logging, Security Hub, GuardDuty) │ │
│ └─────────────────────────────────────┘ │
└─────────────────────────────────────────────┘Critical design principle: Data must never flow down-classification (IL5 → IL4) without an explicit data marking review. Architecture controls enforcing this include:
- Separate KMS key hierarchies per account
- No cross-account IAM roles that allow IL5 → IL4 data access
- S3 bucket policies with explicit deny for cross-account read from lower-IL accounts
The Terraform module structure mirrors this hierarchy — separate workspaces per account, with a shared services workspace that outputs cross-account logging configurations.
DISA STIG Hardening at IL5
The Defense Information Systems Agency (DISA) publishes Security Technical Implementation Guides (STIGs) for cloud services used at IL5. AWS GovCloud has an associated DISA SRG authorization that establishes the baseline, but individual system owners must still implement STIGs for:
- EC2 instances and AMIs (OS-level STIGs)
- Container base images (DISA-approved base images through Platform One Iron Bank)
- Database configurations (PostgreSQL, RDS STIGs)
- Web application configurations (NGINX, Apache STIGs)
Automating STIG compliance through CI/CD pipeline gates means every deployment includes a compliance check rather than a periodic audit. Tools like Inspec profiles, OpenSCAP, and AWS Config rules can validate STIG controls as part of the pipeline.
Authorization Process: ATO vs. cATO
Traditional ATO (Authority to Operate) for an IL5 system involves a full security package review by an Authorizing Official (AO) — typically taking months. The DoD's push toward continuous ATO (cATO) enables systems to maintain authorization dynamically by demonstrating that controls are monitored and enforced continuously.
Building toward cATO from the start means:
- Controls are implemented as code (Infrastructure as Code, policy-as-code)
- Compliance evidence is collected automatically (AWS Config, CloudWatch, Security Hub)
- Control status is visible in real-time to the AO
- Changes go through the pipeline rather than manual review
For more on building cATO-ready pipelines, see our guide on continuous ATO automation.
What Rutagon Builds for IL4/IL5 Systems
Rutagon builds multi-impact-level cloud environments using Terraform-managed AWS GovCloud infrastructure — account isolation, FIPS-enforced API paths, OIDC-federated CI/CD with US-person access controls, and STIG-compliant base configurations. The delivery philosophy is infrastructure that passes A&A on first submission, not after three rounds of remediation.
Discuss your IL4/IL5 requirements → rutagon.com/contact
Frequently Asked Questions
What's the difference between IL4 and IL5 for AWS?
IL4 can be satisfied on AWS commercial regions with appropriate controls (VPC isolation, FIPS endpoints, encryption). IL5 requires AWS GovCloud (US) due to the physical tenant isolation and US-person access requirements. The architecture patterns are similar, but IL5 requires rebuilding any commercial-region dependencies that aren't available in GovCloud.
Can I use Terraform to manage AWS GovCloud?
Yes. The AWS Terraform provider supports GovCloud regions (us-gov-east-1 and us-gov-west-1). GovCloud requires a separate AWS account with a linked commercial account for initial setup — the Terraform configuration manages the GovCloud account directly. Provider authentication uses GovCloud-specific credentials.
What is the DISA Cloud Computing SRG?
The DISA Cloud Computing Security Requirements Guide defines the impact levels (IL2 through IL6), the controls required at each level, and the process for authorizing cloud service providers. It's the primary reference document for DoD cloud architecture decisions. Available on the DISA website.
How long does an IL5 ATO take?
Traditional IL5 ATO processes typically take 6–18 months depending on the complexity of the system, the readiness of the security package, and the pace of the authorizing official's review cycle. Systems built with cATO-oriented architectures — automated evidence collection, continuous monitoring dashboards — can accelerate this significantly.
What is FIPS 140-2 and why does it matter for IL5?
FIPS 140-2 is a federal standard for cryptographic modules. IL5 requires all encryption to use FIPS 140-2 validated modules — meaning both the algorithm and the implementation must be validated. In practice, this means using AWS FIPS endpoints for all API calls and configuring TLS to use only FIPS-approved cipher suites.
Discuss your project with Rutagon
Contact Us →