The DoD's cloud spending is projected to reach $9.1 billion by 2028 (Deltek GovWin). DISA's updated Cloud Computing SRG and the Pentagon's JADC2 strategy are accelerating classified workload migration. For defense contractors, cloud adoption is no longer optional—it's a competitive requirement. But getting it wrong means losing your Authority to Operate, your CMMC certification, or worse—exposing CUI to adversaries.
Why Defense Contractors Are Moving to the Cloud
For decades, defense software lived on-premises—behind air gaps, in hardened server rooms, updated via physical media. That model still has its place (and we've written extensively about it), but the reality is shifting:
- Speed of deployment: Cloud-native CI/CD pipelines can deliver updates in hours, not months. For programs on continuous ATO (cATO) tracks, this velocity is essential.
- Scalability: Burst compute for ML training, large-scale simulation, and data analytics that would be cost-prohibitive to maintain on-premises.
- Collaboration: Multi-contractor programs (like JADC2) require shared environments that on-prem infrastructure can't easily provide.
- Talent: Modern engineers expect cloud-native tooling. Organizations stuck on legacy infrastructure struggle to recruit and retain top talent.
- Compliance alignment: FedRAMP-authorized environments inherit hundreds of controls, reducing the burden of achieving CMMC and NIST 800-171 compliance.
Understanding Impact Levels: Where Can Your Data Live?
The DoD Cloud Computing Security Requirements Guide (CC SRG) defines six Impact Levels that determine what data can be hosted in which cloud environments. Getting this wrong is the #1 mistake defense contractors make during cloud migration:
Impact Level 2 — Public, Non-Sensitive
Publicly releasable DoD information. Can be hosted on any FedRAMP Moderate-authorized commercial cloud. Examples: Public-facing websites, unclassified training materials, open-source project repositories.
Impact Level 4 — CUI & Non-Critical Mission Data
Controlled Unclassified Information (CUI) and non-public DoD data. Requires FedRAMP Moderate+ on a DoD-authorized platform. This is where most defense contractor workloads land. Platforms: AWS GovCloud, Azure Government, Google Cloud for Government, Oracle Cloud for Government.
Impact Level 5 — Higher Sensitivity CUI & Mission Data
Higher-sensitivity CUI and unclassified National Security Information (NSI). Requires dedicated infrastructure, US-person-only operations staff, and enhanced physical security. Key constraint: data cannot leave the geographic boundaries of the United States. Fewer CSPs are authorized at this level.
Impact Level 6 — Classified (Secret)
Classified data up to Secret. Requires air-gapped cloud infrastructure that is completely physically and logically isolated from commercial and lower-IL environments. Only a handful of CSPs offer IL6: AWS Secret Region, Azure Government Secret, Google Distributed Cloud (air-gapped). These environments look and feel very different from commercial cloud—expect significant constraints on services, regions, and automation capabilities.
The 5-Pillar Migration Framework
Based on our experience helping defense organizations migrate to the cloud, we've developed a five-pillar framework that addresses the unique challenges of defense cloud adoption:
Data Classification & Boundary Definition
Before you touch a single VM, you need a complete data inventory. Every data element must be classified by sensitivity level and mapped to the appropriate Impact Level. This isn't a checkbox exercise—it's the foundation that determines your entire architecture.
- Conduct a full CUI/CDI inventory using NIST SP 800-171A assessment procedures
- Map data flows between systems to identify cross-boundary interactions
- Define authorization boundaries that align with your System Security Plan (SSP)
- Identify data that cannot migrate—some classified workloads must remain on-premises behind air gaps
Zero Trust Architecture Design
The DoD's Zero Trust Reference Architecture is now mandatory for all new cloud deployments. Your cloud architecture must implement:
- Identity-centric access: CAC/PIV authentication, conditional access policies, just-in-time privileged access
- Microsegmentation: Network policies that enforce least-privilege communication between every service, pod, and function
- Continuous verification: Runtime attestation of workload identity, device posture checks, and behavioral analysis via UEBA
- Encryption everywhere: TLS 1.3 in transit, AES-256 at rest, CNSA 2.0-compliant algorithms for systems with longevity requirements
Secure DevSecOps Pipeline
A cloud migration without a secure CI/CD pipeline is just moving your vulnerabilities to someone else's data center. Your pipeline must include:
- SBOM generation: Automatic Software Bill of Materials for every build artifact
- SAST/DAST/SCA scanning: Integrated supply chain security checks at every stage
- Container hardening: Kubernetes security with Pod Security Standards, OPA/Gatekeeper policies, and DISA STIG-hardened base images
- Infrastructure as Code (IaC): All infrastructure defined in
version-controlled Terraform/Pulumi with
tfsecandcheckovpolicy enforcement
Compliance as Code
Manual compliance documentation is the death of agility. Modern defense cloud programs implement compliance as automated, continuously validated code:
- OSCAL-based SSP: System Security Plans in NIST's Open Security Controls Assessment Language for machine-readable compliance
- Automated control validation: Tools like OpenSCAP and Chef InSpec continuously verify that deployed infrastructure meets NIST 800-53 controls
- Continuous monitoring (ConMon): Real-time dashboards showing control status, POA&M items, and drift detection—feeding directly into your cATO narrative
- Evidence automation: Automatically collect and package assessment evidence for 3PAO reviews, reducing assessment preparation from months to days
Hybrid Architecture & Graceful Degradation
Most defense cloud migrations aren't all-or-nothing. The reality is a hybrid architecture where some workloads run in the cloud, others remain on-premises, and some operate in disconnected or denied environments:
- Cloud-to-edge sync: Design for intermittent connectivity. Tactical edge nodes must operate independently and synchronize when connectivity is restored
- Data sovereignty controls: Implement cryptographic enforcement of data residency—not just policy, but technical controls that prevent data from leaving approved regions
- Graceful degradation: If the cloud connection drops, your mission systems must continue operating. This means local caching, offline-capable clients, and air-gapped fallback modes
- Egress control: Implement defense-in-depth egress filtering to prevent data exfiltration, including DNS-layer controls and eBPF-based network monitoring
The FedRAMP Shared Responsibility Trap
The most dangerous misconception in defense cloud migration: "We're using a FedRAMP-authorized cloud, so we're compliant."
FedRAMP authorizes the infrastructure. It does NOT authorize your application, your data handling, or your access controls. The shared responsibility model means:
┌─────────────────────────────────────────────────────────────┐
│ YOUR RESPONSIBILITY │
│ │
│ • Application security (code, APIs, business logic) │
│ • Data classification and encryption key management │
│ • Identity and access management (IAM policies) │
│ • OS patching and hardening (for IaaS) │
│ • Network security groups and firewall rules │
│ • Logging, monitoring, and incident response │
│ • CMMC/NIST 800-171 control implementation │
│ • Security awareness training for your staff │
├─────────────────────────────────────────────────────────────┤
│ CSP RESPONSIBILITY │
│ │
│ • Physical security of data centers │
│ • Hypervisor and host OS security │
│ • Network infrastructure │
│ • Hardware lifecycle management │
│ • FedRAMP control inheritance (infrastructure layer) │
└─────────────────────────────────────────────────────────────┘Your cloud assessment must document exactly which controls you inherit from the CSP and which you implement yourself. The Customer Responsibility Matrix (CRM) from your CSP is the starting point—but you must validate every inherited control against your specific deployment configuration.
Common Migration Anti-Patterns
After reviewing dozens of defense cloud migrations, these are the patterns that consistently lead to failed assessments, security incidents, or both:
1. Lift-and-Shift Without Re-Architecture
Taking a monolithic on-prem application and running it on EC2 instances doesn't give you any cloud benefits—you get all the cloud risks with none of the cloud advantages. Defense workloads need to be re-architected for cloud-native patterns: containerized microservices, managed databases, and event-driven architectures that leverage the CSP's FedRAMP-authorized managed services.
2. Ignoring the Blast Radius
Cloud makes it trivially easy to over-provision access. A single misconfigured IAM role can expose your entire environment. Design for minimum blast radius: separate AWS accounts per workload, Kubernetes namespaces per team, and service mesh policies that default-deny all inter-service communication.
3. Treating Cloud as Someone Else's Data Center
Cloud environments generate 100-1000x more telemetry than on-prem. Your existing SIEM won't scale. Invest in cloud-native detection using services like AWS GuardDuty, Azure Sentinel, or GCP Security Command Center—and feed everything into your XDR platform for correlated, cross-domain detection.
4. Manual Compliance Documentation
If your SSP is a Word document that gets updated quarterly, you will fail your assessment. Modern assessors expect evidence of continuous compliance—automated scans, real-time dashboards, and machine-readable security artifacts.
Migration Roadmap: A Phased Approach
Attempting a big-bang migration is a recipe for disaster. Defense cloud migrations should follow a phased approach:
- Phase 0 — Assessment (2-4 weeks): Data classification, application inventory, gap analysis against target IL, CSP selection.
- Phase 1 — Foundation (4-8 weeks): Landing zone deployment, network architecture, identity federation (CAC/PIV integration), logging infrastructure, IaC pipelines.
- Phase 2 — Pilot Migration (4-6 weeks): Migrate a low-risk, non-mission-critical workload. Validate the entire DevSecOps pipeline, compliance automation, and operational procedures.
- Phase 3 — Assessment & ATO (8-12 weeks): 3PAO assessment, POA&M remediation, ATO package submission to the Authorizing Official.
- Phase 4 — Production Migration (6-12 weeks): Migrate remaining workloads in priority order. Implement ConMon, establish operational runbooks, and transition to cATO model.
- Phase 5 — Optimization (Ongoing): Cost optimization, performance tuning, advanced threat detection deployment, and continuous compliance improvement.
Total realistic timeline: 6-12 months from assessment to production for IL4/IL5 workloads. IL6 (classified) migrations take significantly longer due to the limited CSP ecosystem and enhanced security requirements.
Frequently Asked Questions
Can defense contractors use public cloud?
Yes, but only FedRAMP-authorized cloud environments. For CUI, you need at least FedRAMP Moderate on an IL4-authorized platform like AWS GovCloud, Azure Government, or Google Cloud for Government. For classified data (Secret and above), you need IL5/IL6 environments that are physically separated from commercial infrastructure.
What is the difference between IL4 and IL5?
IL4 is authorized for CUI and National Security Systems data. IL5 is authorized for higher-sensitivity CUI and unclassified National Security Information. IL5 environments require dedicated infrastructure, US-person-only support staff, and enhanced physical security controls.
How long does FedRAMP authorization take?
Traditional FedRAMP authorization (JAB P-ATO) takes 12-18 months. Agency ATO can take 6-12 months. Realistic timelines for defense contractors should plan for 9-15 months including documentation, assessment, and remediation.
Can I maintain my CMMC certification in the cloud?
Yes. CMMC 2.0 Level 2 maps to NIST 800-171, which is achievable in FedRAMP Moderate environments. However, the shared responsibility model means you are responsible for controls above the infrastructure layer.
Alterra Solutions' Perspective
At Alterra, we've built defense-grade software for both extremes: fully air-gapped tactical systems and cloud-native platforms running on IL4/IL5 infrastructure. Our approach is pragmatic—we design for the hybrid reality where some data lives in GovCloud, some stays on-premises, and some runs on tactical edge devices disconnected from everything.
Whether you're planning your first cloud migration or need to re-architect a failed one, we can help you get to ATO without compromising mission security.
Cloud migration blocked by compliance or architecture risk?
Use our secure cloud migration service to scope GovCloud and hybrid realities properly, then pair with NIST assessment or air-gapped review where the environment demands it.