Sovereign cloud is one of the most overloaded terms in defense IT procurement. Vendors apply it to everything from a hyperscaler region whose buildings sit inside national borders to a fully air-gapped private cloud staffed exclusively by cleared nationals. The label hides architectural decisions that determine, in practice, whether a foreign government can compel disclosure of your data, whether an adversary intelligence service can co-opt the cloud operator's staff, and whether your continuity-of-operations plan survives a geopolitical fracture. For defense workloads, those questions are load-bearing.

This article walks the practical sovereign-cloud landscape as of 2026: the US hyperscaler government regions, the new generation of EU sovereign offerings (Bleu, Delos, T-Systems, OVH), NATO and national defense clouds, and the on-prem baseline that all of them ultimately compete with. It is written for architects making placement decisions, not for procurement teams writing RFPs.

1. What "Sovereign Cloud" Actually Means

Sovereignty in cloud is not one property — it is three orthogonal vectors, and any honest evaluation has to score each independently.

Data residency is the easiest and the most over-emphasized. It asks: where do the bytes physically live? A region in Frankfurt, Paris, or Warsaw satisfies residency for EU buyers. But residency alone is the weakest sovereignty guarantee on offer, because it says nothing about who can reach those bytes through the control plane.

Operator sovereignty asks: who can administer the infrastructure? US hyperscaler commercial regions are administered by globally distributed engineering teams — an L2 ticket touching your tenant could be handled from India, Ireland, or Seattle. Government-grade sovereign offerings restrict this to a defined set of cleared nationals, with audit trails sufficient to evidence compliance. SecNumCloud (France) and C5 (Germany) both require that operators be EU nationals working under EU jurisdiction.

Jurisdictional sovereignty is the vector that breaks the most procurement assumptions. The US CLOUD Act of 2018 lets US authorities compel any US-incorporated company to produce data under its control, regardless of where that data physically resides. So a US-headquartered hyperscaler running infrastructure in Frankfurt is still legally reachable from a US courtroom. The EU's response — GDPR, Schrems II, the Data Act — sharpened the question but did not resolve it. The only structural answer is to put both the data and the corporate entity controlling it under EU jurisdiction.

A useful diagnostic: ask whether a foreign court order, served on the cloud provider, could in principle compel disclosure of your workload's data without your government's involvement. If the honest answer is "yes," you do not have a sovereign cloud — you have a regional cloud.

2. US Hyperscaler Sovereign Offerings

The US hyperscalers have spent fifteen years building government-grade isolation. The result is the most mature sovereign cloud tier on the planet — for US-affiliated buyers.

AWS GovCloud (US-East and US-West) is physically isolated, US-persons-only-administered, and accredited at FedRAMP High and DoD IL4/IL5. AWS Secret Region and AWS Top Secret Region exist for the classified tiers but are reachable only by accredited US government and contractor buyers. AWS announced a European Sovereign Cloud (Brandenburg) for delivery in 2026, operated entirely by EU nationals — the first US hyperscaler to commit to that structure for EU buyers.

Azure Government mirrors the AWS model with Azure Government (FedRAMP High, IL5), Azure Government Secret (IL6), and Azure Government Top Secret. Microsoft has the most extensive accredited footprint at the classified tier, and Azure Government inherits most commercial Azure services with a six-to-twelve-month lag. Microsoft also operates Microsoft Cloud for Sovereignty as a configurable layer on top of commercial Azure for buyers who want sovereignty controls without the full Azure Government accreditation overhead — see our GovCloud architecture comparison for the Azure-vs-AWS placement detail.

Google Assured Workloads is the lightest of the three: a control-plane overlay on commercial Google Cloud that enforces residency, personnel, and key-management constraints. It targets FedRAMP High and IL5 for specific configurations but does not operate a separate region. For workloads where a configured commercial region is acceptable, this can shorten time to ATO; for IL6 and higher, it does not compete.

The hard constraint for non-US buyers: GovCloud, Azure Government, and the IL5/IL6 tiers are gated by US-persons-only access and US export control. A French air force unit cannot buy GovCloud capacity. This is the structural reason the EU sovereign cloud tier exists.

3. EU Sovereign Offerings

Bleu is the French sovereign cloud joint venture between Capgemini and Orange. It runs licensed Microsoft Azure technology inside French data centers, operated only by French nationals, with corporate control entirely under French law — explicitly out of CLOUD Act reach. SecNumCloud qualification is the headline accreditation. Bleu is the clearest example of the "licensed hyperscaler under sovereign operator" model and is the placement of choice for French defense, ministerial, and OIV (operator of vital importance) workloads.

Delos is the German sovereign cloud built by SAP and Arvato Systems, again on licensed Microsoft technology, targeting C5 accreditation and intended for Bund (federal) and Länder (state) workloads. Delos and Bleu are siblings: same technical pattern, different national jurisdictions.

T-Systems Sovereign Cloud is the older Deutsche Telekom offering — sovereign cloud built without a hyperscaler licensing layer, on top of OpenStack and proprietary Telekom orchestration. It targets the same buyer base as Delos but with a lower feature ceiling and a longer operational track record. For workloads that don't need the full hyperscaler API surface, T-Systems is often cheaper and faster to onboard.

OVHcloud occupies a distinct niche: a fully European-owned hyperscale alternative with bare-metal pods, dedicated cloud, and a public cloud tier, all under French jurisdiction. OVH does not pretend to match AWS feature parity, but for compute-heavy and storage-heavy workloads it is competitive on price and delivers genuine jurisdictional sovereignty without a US licensing dependency. For deeper EU-vs-US placement analysis see our EU vs US sovereign cloud comparison.

4. NATO and National Defense Clouds

Above the commercial sovereign tier sits a layer that does not appear in vendor brochures: NATO and national MoD clouds. These are the destinations for classified workloads where even SecNumCloud or FedRAMP High is insufficient.

The NCIA Software Factory and NATO's broader cloud programme provide the alliance-level platform for cross-nation classified workloads (NATO Secret and below). National MoDs operate parallel sovereign clouds — MODCloud in the UK, the BWI Bundeswehr cloud in Germany, the Dutch CC-NDC, the Polish MOD cloud — each accredited to the national classified tier and integrated with allied sharing protocols.

Below those sits the airgapped tier proper, for TS/SCI-equivalent workloads. We've covered the architectural pattern in air-gapped deployment for defense. The relevant point here is that workload placement decisions must include this tier explicitly — moving a workload from NATO Secret down to a commercial sovereign cloud is rare, but moving up is common, and the architecture must survive that transition without redesign.

5. Hybrid and On-Prem Baseline

Sovereign cloud is not always the right answer. The on-prem private-cloud baseline — VMware vSphere, OpenStack, or Kubernetes on bare metal in an accredited national data center — still wins in three scenarios.

First, for classified or air-gapped workloads that cannot tolerate any external network dependency. The sovereign hyperscalers offer disconnected modes (Azure Stack Hub, AWS Outposts, Google Distributed Cloud Air-Gapped) but pricing, support model, and operator-access constraints often push the calculus back to private cloud.

Second, for steady-state workloads where capex amortization beats hyperscaler markup. A workload that runs 24/7 at predictable load for five years is the worst possible economic match for any cloud — sovereign or not. The hyperscaler markup over depreciated bare metal is typically 3-5x annualized.

Third, for organizations that already operate certified data centers. The marginal cost of one more rack is low. The marginal cost of building hyperscaler-sovereign-cloud operations capability is high. For incumbent MoD IT organizations, on-prem extension is usually the cheaper transition path.

Key insight: The placement question is rarely "sovereign cloud or not." It is "which sovereignty tier per workload, and what cross-tier transfers are required?" A modern defense estate runs all four — commercial cloud for marketing, sovereign cloud for CUI, national MoD cloud for restricted-and-above, air-gapped private cloud for secret-and-above — and the architecture lives in the connectors between them. See the complete defense cybersecurity guide for the surrounding control framework.

6. Workload Placement Decisions

Workload placement reduces to a small set of classification tiers and a small set of cost-and-control tradeoffs. The practical matrix:

Unclassified, public-facing (websites, recruitment portals, public APIs) belongs in commercial hyperscaler regions in your jurisdiction. Sovereignty controls add cost and operational friction without proportional value.

Unclassified, internal CUI (HR, finance, internal collaboration) belongs in sovereign cloud — Bleu/Delos/Azure Gov class — for jurisdictional protection of personnel and operational data, even though no formal classified marking applies. The CLOUD Act exposure is the controlling factor.

Restricted and NATO Restricted belongs in national MoD cloud or the equivalent allied tier. Commercial sovereign cloud is usually insufficient here for accreditation reasons rather than technical ones.

Secret and above belongs in airgapped national or alliance infrastructure. No commercial cloud accreditation reaches this tier in 2026.

The cost that procurement teams under-budget is cross-domain transfer: every time data crosses tiers, a cross-domain solution (one-way diode, content inspection guard, or accredited cross-domain appliance) is required. These are slow, expensive, and constitute the operational bottleneck of multi-tier architectures. Designing to minimize required transfers is more valuable than optimizing within any single tier.

7. Architectural Patterns

Three patterns recur across well-architected defense estates.

Control-plane in sovereign cloud, data-plane in mission cloud. Identity, policy, monitoring, and CI/CD live in a sovereign-tier cloud where operator-access and audit are tight. Mission workloads — sensor processing, C2 services, geospatial analytics — run wherever the latency and classification require, often on edge or mission-cloud infrastructure. The control plane manages the mission plane through narrow, audited interfaces. This is the same separation that zero-trust military networking formalizes at the network layer.

Federated identity across tiers. Identity has to span the estate — an analyst should not need three separate credentials for sovereign cloud, MoD cloud, and air-gapped enclave. Federated identity with claims-based authorization, anchored in a sovereign-cloud identity provider and projected (via approved cross-domain mechanisms) into the higher-classification tiers, is the standard pattern. The hard problem is credential lifecycle across the air-gap.

Regional deployment topology. Sovereign cloud regions are sparser than commercial regions. A multi-region active-active deployment that is trivial in commercial AWS becomes a careful design exercise in GovCloud (two regions) or Bleu (initially one). The failure-domain math changes: regional resilience often means hybrid resilience, with a sovereign-cloud primary failing over to an on-prem secondary in the same jurisdiction. See multi-cloud defense strategy for the resilience pattern detail.

8. Vendor Lock-In and Exit Planning

Sovereign cloud lock-in is harder than commercial cloud lock-in because the substitute set is smaller. There are five viable EU sovereign options. There are two real GovCloud-tier US options. The leverage a single provider has on a captive defense customer is correspondingly larger.

The mitigation has three layers.

Infrastructure abstractions. Terraform with provider-agnostic modules, or Crossplane on top of Kubernetes, lets the deployment artifact survive a provider switch. The harder discipline is to avoid provider-proprietary services where a portable alternative exists — using managed Kubernetes (EKS, AKS, OVH Managed Kubernetes) instead of provider-specific PaaS, using S3-compatible object storage instead of native blob APIs, using PostgreSQL or open-source data engines instead of provider-proprietary databases. The cost of portability is real but bounded; the cost of late-stage migration is unbounded.

The exit drill. The "leaving GovCloud" exercise — actually doing a tabletop or pilot migration of a non-critical workload out of the chosen sovereign cloud, to a different sovereign provider or to on-prem — surfaces lock-in cost concretely. Defense organizations should run this drill at least every two years per major workload. The output is a documented migration runbook with timing and cost estimates, which feeds the procurement risk register and the BCP/DR plan.

Contract clauses. Procurement should mandate machine-readable data export within a defined window, IP rights to the deployment automation, no premium on egress for the purpose of provider exit, and transition assistance terms. This is where ITAR-free software supply and provider-exit language converge: the goal in both cases is to preserve sovereign optionality independent of any single foreign vendor's continued cooperation.

Sovereign cloud, done well, is not a single procurement decision but a portfolio posture: explicit per-workload placement, deliberate cross-tier transfer design, infrastructure abstractions that preserve exit, and a recurring drill to verify the exit actually works. The vendors will keep adding sovereign labels. The architecture is what determines whether those labels mean anything.