Gartner is forecasting that European sovereign cloud spend will triple between 2025 and 2027. Sixty-one percent of CIOs now prefer a local cloud provider over a US hyperscaler. This isn’t a minor shift in sentiment — it’s hundreds of billions of euros in infrastructure decisions being made right now.
AWS has responded with the European Sovereign Cloud (ESC): a €7.8B investment, general availability from January 2026, with its first region at eusc-de-east-1 in Brandenburg, Germany.
This article answers one specific question: does the AWS European Sovereign Cloud actually deliver sovereignty, or is it “sovereignty washing”? Sovereignty washing is marketing US-owned cloud infrastructure as sovereign by locating datacentres in Europe — without insulating customers from CLOUD Act exposure via the US parent company. We trace the legal chain clearly and deliver a ten-question checklist you can take into your next vendor meeting.
The tone here is analysis, not advocacy. AWS deserves credit where it has earned it. The legal limitation is real.
For broader context on what’s driving this procurement shift, see our overview of the European cloud sovereignty decision.
What Has AWS Actually Built, and What Is It Claiming?
The AWS European Sovereign Cloud is not a marketing rebrand of an existing AWS region. It is a structurally distinct cloud partition — designated aws-eusc — with its own IAM plane, billing plane, and control plane, isolated from AWS’s standard commercial regions. Data does not flow between the ESC and standard AWS regions. Local Zones in Belgium, the Netherlands, and Portugal are planned.
AWS created a dedicated German holding company — AWS European Sovereign Cloud GmbH (ESC GmbH) — with subsidiaries covering infrastructure, certificate management, and employment. Operational leadership is EU-resident. AWS is also transitioning towards an EU-citizen workforce, which sounds significant but comes with an important caveat: EU residents can be subject to the laws of their country of citizenship, which may not be an EU member state.
At the hardware level, the AWS Nitro System provides genuine technical isolation — AWS employees cannot access customer data even with physical server access. The ESC holds BSI C5 attestation, which is Germany’s cloud security standard.
So AWS’s claims about data residency, EU-based operations, and operational independence are substantially accurate. What the marketing doesn’t address is CLOUD Act exposure. That’s what we’re here to dig into.
What Does the Corporate Structure of ESC GmbH Actually Mean, Legally?
ESC GmbH is 100% owned by Amazon.com Inc., a US corporation headquartered in Seattle. That single fact determines CLOUD Act jurisdiction. Not where the datacentres sit. Not which legal system the GmbH is incorporated under. Not whether the managing directors hold EU passports.
The CLOUD Act (18 U.S.C. § 2703) compels any US-headquartered company to produce stored data in response to a Department of Justice order, regardless of where the data physically resides. Jurisdiction follows the provider, not the server.
The warrant chain for the AWS ESC is straightforward. DOJ issues an order to Amazon.com Inc. in Seattle. Amazon.com Inc. directs ESC GmbH to comply. ESC GmbH cannot refuse its own parent. The GmbH incorporation under German law does not sever this chain — ESC GmbH is a wholly-owned subsidiary, not a legally independent entity.
A high-ranking AWS representative confirmed this to the French Senate, acknowledging that data from a German SME could not be guaranteed protection from US authorities if required by court order. Representatives from AWS, Microsoft, Google, and Salesforce all confirmed the same in a separate German industry report.
For background on the CLOUD Act’s warrant and gag order mechanics, see our earlier analysis.
The CLOUD Act also permits gag orders preventing the company from notifying affected customers. A disclosure could occur without customers ever knowing.
Legal analysts call this an impossible dilemma. Complying with a CLOUD Act order may violate GDPR Article 48, which governs cross-border data transfers. Refusing risks US contempt charges. And there is no EU–US executive agreement that resolves this conflict — unlike the UK and Australia, which have bilateral agreements with the US. That absence is a structural legal gap, not a gap anyone is about to fill quickly.
One partial mitigation exists: customer-held encryption keys (BYOK/HYOK). If customers control their own keys, AWS employees cannot access plaintext data. But whether a CLOUD Act order could compel AWS to assist in decryption even when keys are customer-held remains legally unresolved. Don’t treat BYOK as a definitive CLOUD Act barrier until that’s settled in case law.
The EU Parliament put it plainly: “No amount of local staffing or isolated infrastructure changes” the fact that US-headquartered corporations must comply with US legal mandates regardless of where their data or operations are located.
Why Can’t the AWS European Sovereign Cloud Currently Achieve GAIA-X Level 3?
GAIA-X runs from Level 1 (basic compliance) through Level 3 (full digital sovereignty). Level 3 is the definitive external benchmark — roughly 10% of cloud customers require it, concentrated in military, defence, and highly regulated industries.
Level 3 requires the provider’s ultimate parent company to be headquartered in the European Union. Not merely operating in Europe. Not incorporated as a European subsidiary. The controlling entity’s headquarters must be in the EU.
AWS ESC cannot qualify because its ultimate parent, Amazon.com Inc., is a US corporation. This is structural — you can’t bridge it with operational changes, additional certifications, or EU-resident management. CLOUD Act exposure flows from the US parent to all subsidiaries. That is precisely what Level 3 is designed to screen out.
Catherine Jestin, Airbus EVP and GAIA-X chairwoman, stated as recently as December 2025 that “lawyers are still working on” whether ESC GmbH’s structure could ever qualify for Level 3. The January 2026 GA launch did not resolve this.
BSI C5 — which AWS does hold — covers 121 mandatory controls across 17 security domains and is required for German federal agencies and KRITIS operators. It’s a meaningful certification for operational security. But what it doesn’t do is address extraterritorial law. A provider can hold BSI C5 and remain fully subject to CLOUD Act compulsion. BSI C5 attests operational security; GAIA-X Level 3 attests legal sovereignty. These are different things.
SecNumCloud — France’s sovereignty certification administered by ANSSI — requires the provider to be majority EU-owned and immune to foreign law. No US hyperscaler can obtain it. AWS ESC does not hold SecNumCloud.
For how certification frameworks map to sovereignty claims, see what GAIA-X Level 3 actually requires for genuine sovereignty.
What Did Microsoft France Admit in Court, and What Does That Mean?
Microsoft’s EU Data Boundary is structurally analogous to AWS ESC: Microsoft Corporation (US) remains the ultimate parent, and the CLOUD Act applies at the parent level. In May 2025, Microsoft described encryption features that would make external access — including by US government — “technically impossible.” A month later, that position changed.
In June 2025, Anton Carniaux, General Manager of Microsoft France, testified under oath before the French Senate that Microsoft “cannot guarantee that data belonging to French citizens… would not be handed over to foreign authorities without the French government’s consent.” This is sworn testimony from Microsoft’s own senior officer in France — not an analyst’s critique. And the structural logic that produces this admission applies to any US-headquartered cloud provider operating European sovereign products.
The ICC example makes it concrete. Karim Khan, Chief Prosecutor of the International Criminal Court in The Hague, had Microsoft services access cut during a live legal proceeding. The ICC subsequently adopted OpenDesk from ZenDiS — the German Centre for Digital Sovereignty. A documented case of an international institution concluding that US-headquartered cloud providers simply couldn’t meet its sovereignty requirements.
How Do Google and Oracle Approach Sovereignty, and Does It Change the Picture?
Google took a different structural approach. Rather than creating a US-owned European subsidiary, Google partnered with EU-native companies: S3NS with Thales in France, T-Systems in Germany. In the S3NS model, Thales is the legal operator. S3NS received SecNumCloud certification in late 2025. This is structurally distinct from ESC GmbH — but the underlying technology still involves US-controlled infrastructure, so the open question is whether the partnership genuinely interposes a legal barrier between US authorities and customer data.
NATO’s air-gapped sovereign cloud uses Google infrastructure. But that’s a different category — a government-specific, physically isolated deployment not available to commercial customers.
Oracle has built sovereign cloud products in Europe with EU-law contractual commitments. Like AWS and Microsoft, Oracle’s ultimate parent is a US corporation, and the same CLOUD Act exposure applies.
The pattern across all four hyperscalers is consistent. Every US-headquartered hyperscaler carries CLOUD Act exposure at the ultimate parent level. No subsidiary structure, partnership model, or contractual commitment changes this.
Cristina Caffarra, founder of the Eurostack Foundation, puts it plainly: “A company subject to the extraterritorial laws of the United States cannot be considered sovereign for Europe.” CISPE, the EU cloud provider trade association, launched a Sovereign Cloud Manifesto in July 2025 making the same argument to the European Commission.
So how do you cut through this in a vendor meeting? Here is the checklist.
Ten Questions to Ask Any Cloud Vendor Claiming Sovereignty
Sovereignty washing is detectable. No vendor will surface their CLOUD Act exposure in a sales meeting. These ten questions force the answer into the open. No US-headquartered hyperscaler can answer questions 2 and 7 without qualification. EU-native providers can answer both definitively.
-
Who is the ultimate parent company, and where is it headquartered? If the parent is outside the EU, the CLOUD Act applies — regardless of datacentre location or certifications. This is the threshold question. Everything else flows from it.
-
Is your company or any parent entity subject to the US CLOUD Act, FISA Section 702, or equivalent extraterritorial law? Ask for this on the record in writing. A direct “yes” is honest. A non-answer — pivoting to contractual commitments or technical controls — tells you the vendor cannot answer the question.
-
Who manages the encryption keys for my data — your company, your parent company, or me? Provider-managed keys are fully exposed. Customer-held keys (BYOK/HYOK) reduce exposure. Ask whether a CLOUD Act order could compel decryption assistance even with customer-held keys — this is legally unresolved.
-
What GAIA-X certification level do you hold, and have you applied for Level 3? Level 3 requires EU-headquartered ultimate parent. If the vendor cannot hold Level 3, the answer tells you exactly what the structural legal exposure is.
-
Are you SecNumCloud-certified or BSI C5-attested, and what is the difference for my workload? SecNumCloud requires EU-based ultimate parent control — sovereignty certification. BSI C5 attests operational security without addressing extraterritorial law. Both matter; they address different risks.
-
Has any court, regulatory body, or government ever requested data relating to European customers, and if so, what did you do? Vendors rarely confirm specific instances. The question establishes whether their response process is defined. Contractual disclosure obligations are more useful than transparency reports.
-
Can you guarantee in writing that no foreign government can compel you to disclose my data without notifying me? No US-headquartered provider can make this guarantee — CLOUD Act orders may include gag provisions. The response (or refusal) is itself diagnostic. Document it.
-
Are your operations, management, and technical staff EU citizens or EU residents, and who has access to customer data? EU residents can be subject to the laws of their citizenship country. “EU-based staff” can include non-EU citizens. Ask who specifically has access to customer data.
-
What contractual commitments do you offer under the ESCA addendum or equivalent EU-law governed data processing agreement? ESCA addenda and GDPR DPAs establish liability and expectations. They cannot override a valid US court order. Ask vendors to be explicit about that limitation in writing.
-
What data portability mechanisms exist, and can I migrate off your platform without your cooperation? Lock-in is a secondary sovereignty risk. The EU Data Act establishes portability rights, but technical portability varies. Ask for documented migration tooling, export formats, and exit timelines.
What EU-Native Providers Offer That Hyperscaler Sovereign Variants Cannot
The structural limitation on AWS ESC, Microsoft EU Data Boundary, and Google’s sovereign variants is a consequence of US law — not a criticism of engineering competence. The €7.8B AWS investment, EU-resident leadership, Nitro isolation, and BSI C5 attestation are real and matter for a large proportion of workloads.
EU-native providers — those genuinely headquartered and legally domiciled in the EU — do not carry CLOUD Act exposure. They can qualify for GAIA-X Level 3 and obtain SecNumCloud certification. Examples include OVHcloud and Outscale (Dassault, France — SecNumCloud-certified). For the full landscape, see EU-native providers that do not carry this CLOUD Act exposure.
The right cloud procurement choice depends on workload classification. Most commercial workloads — approximately 90% — do not inherently require Level 3. Many can legitimately run on AWS ESC with appropriate controls. The ten questions above help you work out which workloads need which level of protection.
Sovereign cloud spend is tripling over the next 18 months, EU policy is hardening, and DORA and NIS2 are creating explicit audit rights and exit strategy requirements. Building jurisdictional risk assessment into procurement decisions now is considerably cheaper than retrofitting it later.
For the sovereign cloud procurement framework that ties workload classification to provider selection, see the sovereign cloud procurement framework.
FAQ
What is “sovereignty washing” and how do I recognise it?
Sovereignty washing is marketing US-owned cloud infrastructure as sovereign by locating datacentres in Europe or forming European subsidiaries, without actually insulating customers from CLOUD Act exposure via the US parent. The key tell: if the ultimate parent is US-headquartered, the CLOUD Act applies regardless of subsidiary structure. In a vendor conversation, the signal is simple — the vendor cannot answer “are you subject to the US CLOUD Act?” without qualification.
Is the AWS European Sovereign Cloud the same as the standard AWS region in Frankfurt?
No. The ESC is a separate partition (aws-eusc) with its own IAM, billing, and control plane, architecturally isolated from standard AWS commercial regions. Customers need a separate AWS account. The Frankfurt region (eu-central-1) carries no additional sovereignty controls. The ESC offers a meaningfully different operational architecture — the question this article addresses is about legal jurisdiction, not technical isolation.
Can the US government actually access my data in the AWS European Sovereign Cloud?
Structurally: Amazon.com Inc. is subject to the CLOUD Act. A DOJ order under 18 U.S.C. § 2703 could compel it to produce ESC customer data regardless of physical location. A high-ranking AWS representative confirmed to the French Senate he could not guarantee data would not be disclosed to US authorities if required by court order. The structural exposure exists whether or not any specific government ever acts on it.
What workloads actually require GAIA-X Level 3 certification?
Level 3 is required for approximately 10% of workloads — military, defence, intelligence, and highly regulated industries (financial services under DORA, health data under national frameworks). Most commercial SaaS workloads do not inherently require it. Classify workloads by data sensitivity and regulatory exposure first, then use the ten-question checklist to evaluate vendor claims at each tier.
Does holding my own encryption keys (BYOK) protect my data from CLOUD Act access?
BYOK prevents AWS employees from accessing plaintext data — a genuine technical control. The unresolved question is whether a CLOUD Act order could compel decryption assistance even when keys are customer-held. No public source has definitively answered this. BYOK reduces insider access risk; it cannot be relied upon as a definitive CLOUD Act barrier until case law resolves the decryption compulsion question.
What did the Microsoft France court admission actually say?
Anton Carniaux, General Manager of Microsoft France, testified under oath before the French Senate in June 2025 that Microsoft “cannot guarantee that data belonging to French citizens… would not be handed over to foreign authorities without the French government’s consent.” Sworn legal testimony from Microsoft’s own senior officer in France. The structural logic applies to all US-headquartered cloud providers operating European sovereign products — not only Microsoft.
Which European cloud providers can actually achieve GAIA-X Level 3?
Level 3 is achievable by providers whose ultimate parent is headquartered in the EU: STACKIT (Schwarz Gruppe), Scaleway, Hetzner, OVHcloud, Outscale (Dassault Systèmes — SecNumCloud-certified). No US-headquartered hyperscaler qualifies at the parent level. Google’s S3NS partnership with Thales approaches Level 3 through the partnership entity rather than through Google itself. For the full landscape, see EU-native providers that do not carry this CLOUD Act exposure.
Can a cloud provider’s contractual commitments under EU law override a valid CLOUD Act order?
No. A valid US court order takes precedence over contractual commitments — no contract can nullify a compulsion order served on the provider’s US parent. ESCA addenda and GDPR DPAs establish liability and define remedies; they are not shields against compulsion. The GDPR Article 48 conflict means the provider would be in breach of GDPR if it complied — but that doesn’t prevent compliance, it just creates parallel legal exposure on both sides.
