Choosing a cloud platform for defense workloads is not primarily a technology decision — it is a compliance and data sovereignty decision. The underlying compute infrastructure of Azure Government and AWS GovCloud is broadly similar to their commercial equivalents. What differs is the regulatory compliance posture, the physical and logical isolation from commercial tenants, the support model, and the maximum classification level supportable.

Getting this decision wrong has consequences that are difficult to reverse. Migrating a defense application from one cloud platform to another after it is deployed in production is a significant program-level undertaking. The platform selection decision, made early, constrains the architecture for the life of the program.

Compliance Frameworks: FedRAMP, IL Levels, and NATO Requirements

The primary US compliance framework for cloud workloads is FedRAMP (Federal Risk and Authorization Management Program), which defines three impact levels: Low, Moderate, and High. FedRAMP High is the baseline for sensitive but unclassified government data. Both Azure Government and AWS GovCloud carry FedRAMP High authorizations across most services.

Above FedRAMP, the DoD Cloud Computing Security Requirements Guide (CC SRG) defines Impact Levels 4 through 6. IL4 covers controlled unclassified information (CUI) with a national security designation. IL5 covers National Security Systems (NSS) and DoD classified information up to SECRET. IL6 covers SECRET data. Only specific, physically isolated cloud regions qualify for IL5 and IL6 workloads — not standard GovCloud regions.

For NATO-member nations outside the US, the relevant frameworks are NATO NCIA (Communications and Information Agency) cloud security requirements and national equivalents. NATO NCIA has approved specific cloud service offerings for NATO RESTRICTED and NATO CONFIDENTIAL data after their own audit processes. These approvals are not automatically conferred by FedRAMP — separate assessment is required.

Azure Government vs AWS GovCloud: Key Differentiators

Physical isolation. Both platforms operate physically separate infrastructure from their commercial clouds, staffed only by screened US citizens (for US programs) or equivalent national screening requirements. Both provide logical separation through dedicated infrastructure options (dedicated hosts, bare metal compute).

Service availability parity. Commercial cloud services often appear in GovCloud with a 12–24 month lag. AWS GovCloud historically has a broader service catalog parity with commercial AWS. Azure Government has strong parity in its core IaaS and PaaS services and has significantly improved coverage of AI/ML services, though some commercial Azure services remain unavailable in the Government cloud.

DoD-specific services. Microsoft holds the DoD JEDI/JWCC contract and has made significant investments in IL5-capable Azure Government regions. AWS operates the C2S (Commercial Cloud Services) environment for the IC community and has IL5-capable GovCloud East and West regions. For programs requiring IL5, both are viable — the specific service availability at IL5 varies by region and must be verified against current provider documentation.

Support model. Both providers offer dedicated government support tiers with cleared support personnel. For programs with strict operational security requirements, verifying that support access is restricted to appropriately cleared personnel — and auditable — is a contract requirement, not an assumption.

Hybrid Cloud for Classified Workloads

Most defense programs above SECRET classification cannot place workloads in a commercial cloud — not even an accredited GovCloud region. Classified workloads at SECRET and above must run in accredited government-operated or contractor-operated facilities with physical security controls and SCIF-level personnel access requirements. The cloud, for these workloads, is either a private cloud deployment (government-owned hardware running cloud-like IaaS) or a classified cloud environment such as C2S or Azure Government Top Secret.

The practical architecture for most programs is hybrid: unclassified and CUI components run in GovCloud, classified components run in a private or classified cloud environment, and cross-domain solutions (CDS) mediate data transfer between the two environments. Designing the CDS correctly — including the data validation, format conversion, and re-classification logic — is typically one of the most complex and schedule-critical elements of the architecture.

Data Residency Requirements

Many defense programs have contractual or legal requirements specifying where data may be stored and processed. EU member states' classified data may have restrictions preventing storage in US-operated infrastructure (even in US-owned European data centers). NATO-classified data has specific handling requirements that limit where it can be processed.

Both Azure and AWS have government cloud regions in Europe (Netherlands, Germany) with specific compliance postures for EU sovereign data requirements. Evaluating these options requires legal review of the specific program's classification instructions and national laws, not just the cloud provider's marketing materials.

Key insight: Zero-trust architecture is a requirement, not a choice, for defense cloud deployments. Perimeter-based security assumptions (internal traffic is trusted) are architecturally incompatible with multi-tenant cloud and hybrid environments. Plan for per-request authentication, micro-segmentation, and continuous authorization verification from day one.

Zero-Trust Baseline for Defense Cloud

DoD's Zero Trust Reference Architecture defines seven pillars: User, Device, Network, Application/Workload, Data, Automation/Orchestration, and Visibility/Analytics. For a GovCloud deployment, implementing a zero-trust baseline means: identity-based access (Microsoft Entra ID / AWS IAM with MFA and conditional access), device posture enforcement (no access from unmanaged or non-compliant devices), network micro-segmentation (application-layer firewalling, no implicit trust between services in the same VNet/VPC), and data classification-based access controls (encryption at rest with customer-managed keys, classification labels enforced at the application layer).

Multi-tenant isolation at the infrastructure level — ensuring that one tenant's workload cannot access another tenant's data or infrastructure — is guaranteed by the cloud provider. What is not guaranteed is application-level isolation. A multi-tenant defense application that stores all tenant data in a shared database with row-level security is not zero-trust compliant, regardless of the cloud platform it runs on. Tenant isolation must be implemented and verified at the application layer.