IL5 is not a checkbox on GovCloud
Every quarter a DoD mission team tells a vendor they need an IL5 system, and the vendor replies "we use GovCloud, so we're good." They are not good. Impact Level 5 under the DoD Cloud Computing Security Requirements Guide (SRG) is a specific sensitivity tier with specific infrastructure, personnel, connectivity, and accreditation requirements that go well beyond what FedRAMP High covers. An IL5 system runs on DoD-only dedicated infrastructure, is operated by cleared US persons, connects to the DoDIN through a Boundary Cloud Access Point, and has been individually accredited by DISA for each service in the stack. Building IL5 correctly requires reading the SRG line by line and designing to it — not trusting that "GovCloud" gets you there by default.
Precision Federal engineers IL5 mission systems the way DISA expects: a clearly drawn authorization boundary, service-by-service accreditation confirmed against the DoD Cloud Service Catalog, STIG-compliant operating system images, CAP-routed connectivity, and a documentation package that maps every control to an implementation. For workloads that cross into IL6 or Secret enclaves, we layer in air-gapped patterns and cross-domain solutions that have cleared DISA's CDS evaluation process.
Why this matters federally: DoD program offices are under pressure to move mission systems to cloud for JWCC, for Software Modernization, and for the shift away from on-prem data centers. They need builders who treat IL5 as an engineering problem, not a marketing label.
IL5 CLOUD — FEDERAL APPLICATION FIT
The IL5 stack we use
- Azure Government IL5: US Gov Virginia, Arizona, and Texas regions. IL5-accredited services include Virtual Machines (DoD-dedicated), AKS, Azure SQL MI, Storage, Key Vault Managed HSM, Sentinel, Defender for Cloud. Azure Government Secret for IL6 workloads.
- AWS GovCloud IL5: US-East and US-West. IL5-accredited services include EC2 dedicated tenancy, EKS, RDS, S3, KMS with CloudHSM, GuardDuty, Security Hub, Lambda. AWS Secret Region and Top Secret Region for IL6 and above.
- STIG-compliant images: Iron Bank (DoD Platform One) hardened container images, STIG-compliant AMIs from AWS Marketplace, Azure's CIS and STIG images for Windows and RHEL. Automated scanning with OpenSCAP and Nessus.
- Connectivity: CAP routing through DISA BCAP for IL4/IL5 inbound traffic. ExpressRoute and Direct Connect into DoD Gateway. Transit architectures that keep east-west traffic inside the IL5 boundary.
- Identity: Azure AD Government with CAC/PIV authentication, AWS IAM Identity Center with federation to DoD EAMS-A or agency SSO. Privileged access through PIM/PAM with just-in-time elevation.
- Platforms: Platform One, Big Bang, Kubernetes on Iron Bank base images, OpenShift on GovCloud. See our Kubernetes page and platform engineering page.
- Observability and logging: Splunk Enterprise on IL5, Azure Sentinel, AWS Security Lake. Forwarding to the DoD Cyber Exchange and mission owner SOC.
- Cross-domain: Forcepoint, Owl, Arbit, and Garrison cross-domain solutions for flows between IL5 and IL6/Secret enclaves. See classified AI.
Boundary documentation done right
The most common reason an IL5 package stalls is sloppy boundary documentation. We draw the authorization boundary in a single authoritative diagram, enumerate every component inside it with its accreditation status, map data flows in and out through the CAP, identify inherited controls from the cloud provider (Azure Gov, AWS GovCloud, Oracle Gov) via their P-ATO letters, and produce SSP artifacts that match the agency's ATO template (eMASS, Xacta, or RSA Archer). Our boundary packages survive DISA validation and AO review because they tell one story, end to end.
Federal deployment considerations
- SRG alignment: DoD Cloud Computing SRG v1r4+ is the controlling document. Every architectural decision maps to a specific SRG section.
- US persons rule: only cleared US citizens touch IL5 infrastructure. This affects support contracts, escalation paths, and on-call rotations.
- Dedicated tenancy: IL5 compute and storage are physically separated from non-DoD tenants. Budget accordingly — dedicated instances cost more than shared.
- Service catalog discipline: use only services individually listed as IL5-accredited in the Azure Gov or AWS GovCloud DoD service catalog. New services added to the region are not automatically IL5.
- DoDIN connectivity: inbound internet traffic must traverse a BCAP. Outbound traffic follows the agency's exit architecture. No split-tunnel shortcuts.
- Continuous monitoring: cATO enablement for IL5 systems — see ATO engineering — so mission updates don't trigger full re-authorization.
Where this fits in Precision Federal engagements
IL5 cloud engineering is the substrate for most of our DoD work. It pairs with AWS GovCloud, Azure Government, Kubernetes, and zero trust to deliver mission systems that pass DISA review. Typical engagements: stand up an IL5 landing zone in Azure Government, migrate a mission system from on-prem to GovCloud IL5, produce a boundary package for IL5 ATO, or design a cross-domain path from IL5 to a Secret enclave.