The hyperscaler sovereign cloud marketing machine has been running hot. AWS launched the European Sovereign Cloud in January 2026 — €7.8 billion, a German legal entity, the lot. Microsoft is pushing Azure EU Data Boundary and Azure Local. Google is quietly partnering with T-Systems and Thales to run sovereign infrastructure in Germany and France. All three claim sovereignty credentials. The term means something different in each case.
If you’re dealing with GDPR, DORA, or NIS2, you need to know what each product actually delivers — not what the press releases say.
In our sovereign cloud guide, we introduced the three-layer sovereignty framework: data residency (where data physically sits), operational separation (who operates the infrastructure and holds the keys), and legal jurisdiction (which country’s laws can compel access). This article applies that framework to all three hyperscalers. It gives you a clear picture of what the guardrail sovereign model actually delivers, where it falls short, and when you need EU-native alternatives instead.
What Does the Three-Layer Framework Reveal When Applied to Hyperscaler Sovereign Offerings?
The three-layer framework cuts through the marketing by asking three questions: Where does data reside? Who operates the infrastructure and holds the keys? Which country’s laws govern who can compel access?
Layer 1 — data residency — is the easiest to achieve and the most heavily marketed. Every sovereign cloud offering from every major provider clears this bar. If your regulatory requirement stops at data residing within EU borders, most standard EU regions will get you there.
Layer 2 — operational separation — is where things start to diverge. AWS ESC uses a separate partition architecture with EU-resident staff and EU key management. Azure Local lets customers run disconnected deployments in their own data centres. Google’s partner model hands operational control to EU legal entities entirely. These are meaningfully different approaches, and Layer 2 is where the genuine differentiation lives.
Layer 3 — legal jurisdiction — is the question none of the directly operated hyperscaler offerings fully answer. The CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018) shifts jurisdiction from where data sits to who controls it. As long as a provider is controlled by a US parent, it remains subject to the CLOUD Act. Storing data in an EU data centre operated by a US parent does not eliminate US legal reach.
That is what the guardrail sovereign model label captures honestly. Hyperscaler offerings erect operational guardrails around EU data — real infrastructure, real EU legal entities, real separation commitments. But the US parent company ownership structure remains unresolved. Sovereignty washing is when marketing presents Layer 1 data residency as equivalent to full sovereignty. The guardrail model is not sovereignty washing — but it is not full sovereignty either.
What Does AWS European Sovereign Cloud Actually Change?
AWS ESC operates as a separate partition (aws-eusc, region eusc-de-east-1) in Brandenburg, Germany. This is not a standard EU region with extra policies bolted on — partitions are entirely independent versions of AWS, with separate APIs, IAM, service endpoints, and data planes.
AWS European Sovereign Cloud GmbH is incorporated under German law. All operational staff must be EU residents, with a stated goal of transitioning to exclusively EU-citizen staffing. Technical controls prevent access from outside the EU. Encryption keys are generated, stored, and managed within the EU. Customer data in EC2 is protected by the Nitro System, which blocks unauthorised access — including by AWS personnel.
On certification: BSI C5 is the German government’s minimum standard for federal agencies using external cloud services. It confirms operational security controls, access management, and data handling. What it does not confirm: legal immunity from foreign government access demands, CLOUD Act applicability, or corporate ownership jurisdiction. C5 evaluates how the cloud is operated, not who can legally compel access. Compare that to France’s SecNumCloud, which requires the provider to be immune to requests from public authorities of third countries. That is a genuine Layer 3 framework. C5 is not.
On service availability: AWS ESC launched with more than 90 services — more than a standard new region launch. Not all standard AWS services are available, there is a sovereignty premium of approximately 10-15% over Frankfurt, and enterprise discounts may not transfer. Verify the service list before committing workloads.
AWS ESC is an architectural commitment that deserves to be taken seriously. Layers 1 and 2 are genuinely addressed.
What Does AWS ESC Not Resolve — and Why Does the CLOUD Act Still Apply?
AWS ESC does not resolve Layer 3 legal jurisdiction. Amazon.com Inc. remains the US parent company of AWS European Sovereign Cloud GmbH. The CLOUD Act applies to the parent entity. Data entrusted to foreign subsidiaries of US-registered companies is considered under the parent’s “possession, custody, or control” — a phrase US authorities interpret broadly enough to encompass overseas affiliates.
Sam Newman put it plainly: “The new EU AWS Sovereign cloud offering does nothing to protect customer data from being accessed by the US government.” That is the direct answer.
GDPR Article 48 prohibits data transfers to foreign authorities without an EU-approved legal basis. The CLOUD Act explicitly allows US authorities to demand US providers hand over data regardless of where it is stored. As cybersecurity analyst Andrea Fortuna observed: “When American and European law conflict, the company will follow the jurisdiction that controls its existence. Technical measures cannot fix a legal reality.” The provider is caught between two legal systems — not protected by one.
What about BYOK? Encrypting data with EU-controlled hardware security modules makes it unreadable to the provider even under compulsion. But it does not eliminate legal compellability — the provider can still be compelled to produce metadata or provide infrastructure-level cooperation. BYOK reduces risk. It does not resolve Layer 3.
Read more on the CLOUD Act exposure that no EU subsidiary structure resolves.
How Do Microsoft Azure Sovereign Options Compare — EU Data Boundary and Azure Local?
Microsoft offers two distinct sovereign-oriented products. Keep them clearly separate — they address different layers and serve different needs.
Azure EU Data Boundary stores and processes customer data within the EU, including AI data processing for EU customers. This is a Layer 1 commitment. Microsoft’s own chief legal officer in France, under oath before the French Senate, acknowledged the company cannot guarantee EU data is safe from US access requests. Microsoft has said directly that EU Data Boundary alone is insufficient for full sovereignty.
Azure Local (formerly Azure Stack HCI) is structurally different. It delivers Azure infrastructure in customers’ own data centres in disconnected mode — and when customer-operated in disconnected mode, this achieves Layer 2 with real depth. The unresolved issue is Layer 3: even fully disconnected, the software licensing and update relationship with Microsoft Corporation maintains a legal connection to the US entity.
AWS ESC is a provider-operated sovereign partition; Azure Local is a customer-operated disconnected deployment. Different models for different sovereignty needs.
What Does Google Cloud’s Partner-Led Sovereign Model Offer Through Delos and S3NS?
Rather than operating sovereign infrastructure directly, Google partners with EU legal entities. T-Systems (a Deutsche Telekom subsidiary) operates Delos Cloud in Germany on Google Cloud Platform technology, with operational control under German law. In France, S3NS is a Thales-majority joint venture with Google, with Thales maintaining operational control under French law.
The key distinction: the operating entity that handles customer data is an EU legal entity, not a subsidiary of a US parent. That creates a structurally stronger Layer 3 argument than AWS ESC’s directly operated model.
The persistent nuance is Google’s control plane involvement. While the partner operates the infrastructure, Google Cloud technology underpins the service and software supply chain dependencies on Alphabet persist: “The offering’s control plane will still be under Google which will come into consideration for highly sensitive workloads.”
A practical caveat: independent assessment data on Delos and S3NS is limited. Fewer independent technical reviews exist, and it is harder to verify what Google’s control plane involvement means in practice. That limited visibility is itself a risk factor — you are relying on partner-operated trust rather than independently verified architecture.
When Is the Guardrail Sovereign Model Not Enough — and What Are the Alternatives?
The guardrail model is right for a lot of workloads. It is not right for all of them.
For standard SaaS workloads and non-regulated data, AWS ESC or Azure EU Data Boundary will satisfy the requirement. Data stays in the EU, operational controls are real, and the sovereignty gap at Layer 3 does not create unacceptable regulatory risk.
For regulated workloads — HealthTech with GDPR-sensitive patient data, FinTech under DORA — the guardrail model is not sufficient. Airbus put out a €50 million, decade-long tender to migrate mission-critical applications to a sovereign European cloud, explicitly because data residency on paper from US hyperscalers was not enough. That is the calculation you need to make for your own workloads.
For genuine Layer 3 independence, the EU-native providers are the benchmark: OVHcloud (France), Scaleway (France), and Hetzner (Germany). All fully EU-owned, no US parent, no CLOUD Act exposure. Hetzner’s flat-rate pricing means sovereign-first architectures can reduce egress spend by 30-50% compared to hyperscaler pricing. The trade-offs are real — smaller service catalogues, less mature tooling, migration costs — but for workloads where Layer 3 independence is genuinely required, that is the right conversation to have.
Here is the decision framework:
- Layer 1 only required: Any standard EU region from any major provider will do.
- Layer 1 + 2 required: AWS ESC or Azure Local are genuine options — provider-operated partition vs. customer-operated disconnected deployment.
- Layer 1 + 2 + 3 required: EU-native providers (OVHcloud, Scaleway, Hetzner) or partner-operated models (Delos, S3NS). Partner models have less publicly verifiable architecture.
For EU-native providers that offer full jurisdictional isolation, and how to apply this framework to your own vendor assessment, the follow-on articles in this series cover both in depth.
FAQ
Does the AWS European Sovereign Cloud protect my data from the US CLOUD Act?
AWS ESC provides genuine operational separation — a separate partition, EU-resident staff, EU key management — but Amazon.com Inc. remains the US parent company. The CLOUD Act applies at the corporate ownership level, meaning a US court order can still compel Amazon to produce data held in AWS ESC. Operational separation is not legal independence.
What is the guardrail sovereign model?
The guardrail sovereign model describes hyperscaler offerings that place operational controls — data residency, EU staffing, separate infrastructure — around EU data while remaining owned by a US parent company subject to the CLOUD Act. It represents progress on Layers 1 and 2 of sovereignty but does not resolve Layer 3 legal jurisdiction.
Is AWS ESC sovereignty washing?
No. AWS ESC represents a substantial investment in separate infrastructure, EU legal entity creation, and operational separation. Sovereignty washing is marketing basic data residency as full sovereignty. AWS ESC goes well beyond data residency — but it does not achieve full legal jurisdiction independence from US law.
What does BSI C5 certification actually prove about sovereignty?
BSI C5 certifies operational security controls — access management, incident response, encryption implementation, physical security. It does not evaluate legal jurisdiction, CLOUD Act applicability, or corporate ownership structure. C5 confirms how the cloud is operated, not who can legally compel access to data.
How does Azure EU Data Boundary differ from Azure Local for sovereignty?
Azure EU Data Boundary is a data residency commitment (Layer 1) — data stays in the EU. Azure Local is an on-premises, potentially disconnected deployment model that achieves operational separation (Layer 2) and can partially address legal jurisdiction (Layer 3) when customer-operated. They serve different sovereignty requirements.
Can customer-managed encryption keys (BYOK) solve the CLOUD Act problem?
BYOK prevents the cloud provider from reading encrypted data at rest, which is a useful security measure. However, it does not eliminate legal compellability — the provider can still be compelled to produce metadata, facilitate access, or provide infrastructure-level cooperation under a CLOUD Act order.
What makes Google Cloud’s Delos and S3NS different from AWS ESC?
Delos (T-Systems) and S3NS (Thales) are EU legal entities that operate sovereign cloud infrastructure built on Google Cloud technology. Because the operating entity is EU-owned — not a US subsidiary — the partner model potentially achieves stronger Layer 3 legal jurisdiction independence than AWS ESC’s directly operated model.
What is the difference between EU-resident and EU-citizen staffing at AWS ESC?
AWS ESC currently operates with EU-resident staff, with a stated goal of transitioning to exclusively EU-citizen staff. EU residents may hold citizenship in non-EU countries and could be subject to legal obligations in those jurisdictions. The distinction matters because an EU resident with US citizenship could theoretically face conflicting legal compellability demands.
Which sovereign cloud option is right for an SMB running regulated workloads?
It depends on the workload’s regulatory exposure. Standard SaaS data may be adequately served by AWS ESC or Azure EU Data Boundary (Layers 1-2). Regulated HealthTech or FinTech data under strict supervisory requirements may need EU-native providers (OVHcloud, Scaleway, Hetzner) that achieve all three layers including full legal jurisdiction independence.
Does GDPR Article 48 actually prevent CLOUD Act data requests?
GDPR Article 48 prohibits data transfers to foreign authorities without an EU-approved legal basis. However, the CLOUD Act compels US-owned providers to comply with US government data requests regardless of foreign data protection laws. The provider is caught between two conflicting legal regimes — Article 48 does not provide immunity; it creates a legal conflict that remains unresolved.
What services are available in AWS ESC compared to standard AWS regions?
AWS ESC launched in January 2026 with more than 90 services — more than a typical new region launch. However, not all standard AWS services are available in eusc-de-east-1, and the catalogue will expand over time. Verify the current AWS ESC service list before committing workloads.
How do I evaluate any cloud provider’s sovereignty claims?
Apply the three-layer framework: Layer 1 — does data reside within the EU? Layer 2 — who operates the infrastructure and holds encryption keys? Layer 3 — which legal jurisdiction governs access compellability, and is the provider’s parent company subject to US law? If the provider only addresses Layers 1 and 2, you are looking at a guardrail model, not full sovereignty.
This article is part of sovereign cloud explained — a complete resource covering the three-layer framework, legal exposure, provider comparisons, regulatory drivers, and a practical due diligence playbook for SMB technical leaders.
