What Your Vendor Won't Tell You About 'EU Sovereign' Cloud

You’re evaluating cloud providers for a project that handles sensitive European data. Maybe it’s a financial compliance platform, maybe it’s an AI research pipeline, maybe it’s a health data warehouse. You send out RFPs, and three vendors come back with the same magic word: “sovereign.”

AWS has a European Sovereign Cloud. Azure has an EU Data Boundary. Google has Sovereign Controls. They all sound reassuring. But here’s the thing — when three competing hyperscalers all claim the same label, and none of them can actually sever the legal chain to their US parent company, the word “sovereign” starts to mean whatever the marketing team needs it to mean.

We tore down what each of these offerings actually promises — the corporate structures, the legal exposures, the fine print — so you don’t have to take anyone’s word for it. If you want the legal foundation for why this matters, start with The CLOUD Act and Your AI Research. If you want the conceptual framework for residency versus sovereignty, read Data Sovereignty Is Not Data Residency. This post is the vendor-by-vendor reality check.

AWS European Sovereign Cloud: a German subsidiary with an American parent

AWS launched its European Sovereign Cloud on January 14, 2026, starting with a Region in Brandenburg, Germany. The pitch is compelling: dedicated infrastructure physically and logically separated from standard AWS Regions, operated exclusively by EU-resident employees, with no data leaving the EU.

The operating entity is AWS European Sovereign Cloud GmbH — a German limited liability company. At first glance, it looks exactly like what European customers asked for. German company, German soil, German staff.

But look one level up the corporate chain. AWS European Sovereign Cloud GmbH is a 100% subsidiary of Amazon.com, Inc. — a Delaware-incorporated US company. That single fact determines everything about legal jurisdiction.

The CLOUD Act doesn’t care about where the servers sit or who operates them day-to-day. It follows the corporate chain. A US court order served to Amazon in Seattle can compel production of data from the German subsidiary’s servers. Amazon can file a motion to quash — the law allows that — but the conditions are narrow: the customer must not be a US person and must not reside in the US, disclosure must create a material risk of violating the law of a qualifying foreign government with a CLOUD Act executive agreement, and the court must agree that foreign interests outweigh US interests. As of 2026, only the UK and Australia have signed such agreements with the US. The EU hasn’t.

AWS’s own documentation emphasizes “operational” sovereignty — EU staff, EU data centers, restricted access controls. These are real engineering measures, and they matter for protecting against casual breaches or unauthorized internal access. But operational separation isn’t legal separation. As Techzine’s analysis put it: “AWS and the AWS European Sovereign Cloud are part of the American company Amazon. That company therefore ultimately has to listen to what the US government expects, desires, and demands.”

The bottom line: AWS European Sovereign Cloud offers strong data residency and operational controls. It doesn’t offer legal sovereignty. The CLOUD Act path to your data runs straight through Seattle.

Operational separation is not legal separation. A German subsidiary with an American parent is still an American company under the CLOUD Act.

Azure EU Data Boundary: a residency promise, not a sovereignty one

Microsoft’s approach is different in structure but identical in outcome. Instead of creating a standalone sovereign cloud, Microsoft built the EU Data Boundary — a commitment that EU customer data stays within the EU for core services including Azure, Microsoft 365, and Dynamics 365.

The EU Data Boundary controls where data is stored and processed. It’s a data residency commitment, and a substantial one. Microsoft has invested heavily in EU infrastructure, added data residency controls across its services, and publishes detailed documentation about which data flows stay within the boundary.

But residency isn’t sovereignty. Microsoft Corporation is a Washington State company. Every EU subsidiary — Microsoft Ireland Operations Limited, Microsoft France SARL, Microsoft Deutschland GmbH — sits below a US parent. And that parent is subject to the CLOUD Act.

Microsoft’s own people have said as much publicly. At a French Senate inquiry into digital sovereignty on June 18, 2025, Microsoft France’s Anton Carniaux — director of public and legal affairs — was asked if he could guarantee, under oath, that French citizens’ data couldn’t be transmitted to the American government. His answer: “No, I cannot guarantee that, but, again, it has never happened before.” That’s not a hostile critic’s interpretation. That’s Microsoft’s own representative, under oath, to a European legislature.

Microsoft also offers Azure Local (formerly Azure Stack HCI) — on-premises hardware that runs Azure services in your own data center. This reduces the residency exposure, since the data physically lives on your infrastructure. But it doesn’t eliminate the legal exposure. The software is still licensed and operated under agreements with a US-incorporated company. If US authorities want data that Azure Local processes, the CLOUD Act provides a pathway through Microsoft.

The pattern holds: strong residency controls, genuine engineering investment, but no legal severance from US jurisdiction.

Google Sovereign Controls: partnerships, not independence

Google took yet another approach — and in some ways, it’s the most revealing.

Google Cloud doesn’t offer a standalone European sovereign cloud at all. Instead, it built Sovereign Controls — a set of technical controls (encryption key management, access restrictions, data residency) that layer on top of standard Google Cloud regions.

For customers who want more separation, Google partnered with European operators. T-Systems (a Deutsche Telekom subsidiary) operates the Germany data boundary. S3NS — the Thales–Google joint venture — operates the France data boundary, with Thales managing the encryption keys. These partnerships put European companies in the operational loop — they hold encryption keys, manage access policies, and can theoretically block Google from accessing data.

Theoretically. In practice, the underlying cloud platform is still Google Cloud Platform, operated by Google LLC, a subsidiary of Alphabet Inc. — a Delaware-incorporated company. The compute, the storage, the networking fabric, the hypervisor — it’s all Google’s stack. T-Systems and S3NS operate a control layer on top of Google’s infrastructure, not an independent platform.

This creates an interesting tension. If T-Systems holds the encryption keys, can Google actually comply with a CLOUD Act order? Maybe not for encrypted-at-rest data. But the CLOUD Act doesn’t just cover stored data — it covers data “in the possession, custody, or control” of the provider. If Google’s platform processes your data in memory during inference or computation, the encryption at rest doesn’t help. The data is decrypted while it’s being used.

And there’s a deeper structural issue. Google could, in theory, update its platform in ways that change how the sovereign controls operate. T-Systems and Thales have contractual protections, but contracts between a €30 billion European telco and a €1.8 trillion American tech company don’t always play out evenly when a US court order is on the table.

Google’s approach is arguably more honest about the limitations — it doesn’t call the result “sovereign” in the way AWS does. But the end state is similar: European operators provide a layer of control on top of a US-jurisdiction platform.

When asked under oath whether French citizens’ data could be kept from the American government, Microsoft’s own representative answered: no.

The pattern: operational separation ≠ legal separation

Step back and look at all three vendors together. The specifics differ — a German subsidiary, a data boundary commitment, a partnership model — but the structure is identical:

• Operational controls: EU-resident staff, EU data centers, restricted access policies, encryption key management. These are real and meaningful.
• Corporate structure: A US-incorporated parent company at the top of the chain. This is also real, and it’s what the CLOUD Act cares about.

Every hyperscaler has invested genuinely in making their EU offerings more secure, more private, and more operationally separated. None of that investment changes the legal reality. A US court order served to the parent company can reach through any number of EU subsidiaries, data boundaries, and operational controls.

This isn’t a conspiracy or a design flaw. It’s structural. US law says: if we have jurisdiction over the parent, we have jurisdiction over the data. EU law says: our residents’ data should be governed by our rules. These two positions are fundamentally in conflict, and no amount of subsidiary engineering resolves the contradiction.

The EU knows this. The CJEU struck down two successive EU-US data transfer frameworks in Schrems I and Schrems II for exactly this reason. The current Data Privacy Framework survived its first court challenge in September 2025 — judged on the facts as they stood at its adoption in 2023 — and further challenges are expected. The European Data Protection Supervisor found that even the European Commission’s own use of Microsoft 365 infringed data protection law.

The regulators aren’t confused. They’ve been saying this for years.

US law says: jurisdiction over the parent means jurisdiction over the data. EU law says: our residents’ data follows our rules. No subsidiary engineering resolves that contradiction.

What real sovereignty looks like

Genuine data sovereignty requires severing the legal chain entirely. That means three things:

1. EU-incorporated provider with no US parent — and no US operations. The company operating your infrastructure must be incorporated in an EU/EEA member state, with no controlling interest from a US-jurisdiction entity. But incorporation isn’t the whole picture: the CLOUD Act also reaches providers that conduct business in the US. OVHcloud, for example, is French-headquartered but operates US data centers — and their own legal FAQ acknowledges they’ll comply with lawful CLOUD Act requests, which could include data stored outside the United States. Providers like Scaleway and Hetzner, which don’t have US operations, offer a cleaner jurisdictional position.

2. Full-stack independence. It’s not enough to have an EU company at the top if critical components depend on US-jurisdiction vendors underneath. The hypervisor, the orchestration layer, the management plane — if any of these route through a US company, there’s a potential access path.

3. Open-source models for AI workloads. For AI specifically, open-source models running on EU-sovereign infrastructure offer the strongest position. The model weights are public (no vendor lock-in), inference runs on EU hardware, and no US company is in the data path. Your queries never leave European jurisdiction.

LumaVista takes this approach — running multiple open-source models on dedicated EU GPU servers with no US company anywhere in the corporate chain or infrastructure stack. It’s the difference between a vendor telling you your data is “operationally” sovereign and your data actually being legally unreachable by foreign courts.

This isn’t the only path. Any combination of EU-incorporated provider, EU infrastructure, and open-source or EU-developed software can achieve genuine sovereignty. The test is always the same: follow the corporate chain upward and check whether any entity in it is subject to US jurisdiction.

A decision framework: questions to ask any vendor

Before you sign with any provider that uses the word “sovereign,” ask these questions. The answers will tell you more than any whitepaper.

1. “Where is your ultimate parent company incorporated?” If it’s the US, the CLOUD Act applies. Full stop. No subsidiary structure changes this.

2. “If a US court issues a CLOUD Act warrant for our data, can you legally refuse to comply?” If they can’t say yes — and no company with a US parent can — you have your answer.

3. “Which entities in your corporate chain are subject to US jurisdiction?” Not just the operating entity. The parent, the holding company, the licensing entity. Any one of them is enough. And don’t forget operational presence — the CLOUD Act also reaches providers that conduct business in the US, even if they’re EU-incorporated.

4. “Do any US-jurisdiction companies provide critical infrastructure components?” Hypervisors, management planes, update mechanisms, support access. If a US company can reach the running system, the legal exposure may extend through them.

5. “What happens if the EU-US Data Privacy Framework is invalidated?” Every previous framework was struck down. What’s your vendor’s contingency plan? If they don’t have one, they’re betting your compliance on a framework with a track record of failure.

6. “Can you show us the corporate ownership chain as a diagram?” If a vendor hesitates to produce this, that tells you something. If they produce it willingly and there’s no US entity in the chain, you’re in a stronger position.

These aren’t gotcha questions. They’re the questions your DPA will ask if they audit your data processing arrangements. Better to ask them now, during procurement, than to discover the answers during an enforcement action.

What to do now

1. Run the parent company test on your current providers. Trace the corporate chain to the top for every service that handles sensitive data. Mark each as “EU-sovereign” or “US-reachable.”

2. Don’t confuse operational controls with legal protection. EU staff, EU data centers, and encryption at rest are all valuable security measures. None of them stop a CLOUD Act warrant.

3. Classify your workloads by sovereignty requirement. A public marketing site on AWS is low-risk. Client financial records processed through a US-jurisdiction AI tool? That needs sovereign infrastructure.

4. Start evaluating EU-native providers for high-sensitivity workloads. You don’t need to migrate everything overnight. Start with the data that would hurt most if a foreign government accessed it.

5. Add the six vendor questions to your procurement process. Five minutes during vendor evaluation saves months of emergency migration later.

6. Watch the regulatory timeline. Most remaining EU AI Act obligations apply from August 2, 2026, with high-risk system requirements following from December 2027. Organizations using AI for high-risk applications will need to demonstrate they understand where their data goes and who has legal access. “We use the EU region” isn’t going to cut it.

7. Brief your team across disciplines. Legal needs to understand cloud infrastructure. IT needs to understand the CLOUD Act. Procurement needs to understand both. The gap between these teams is where sovereignty failures hide.

The word “sovereign” on a vendor’s marketing page doesn’t make your data sovereign. Corporate structures do. Legal jurisdictions do. Follow the chain, ask the hard questions, and make decisions based on what you find — not on what someone’s brochure promises.