EU Sovereign Cloud Options Compared Guide: Control, Assurance and Trade-offs by Provider

"Sovereign cloud" now describes at least five different things, from a policy setting in a global hyperscaler region to a French-law company running Google technology behind a disconnectable boundary, and buyers who compare them on marketing labels end up with the wrong one. European regulators, public bodies and regulated firms want control over who can access their data, which law applies to the operator, who holds the keys and whether services keep running if a non-EU parent is cut off. This guide compares the main EU sovereign cloud options available in October 2026 (AWS European Sovereign Cloud, Microsoft's sovereign offerings and national partner clouds, Google's sovereign portfolio including S3NS, and European providers such as OVHcloud and STACKIT) on control and assurance rather than branding. It is for cloud architects, CISOs, procurement and compliance teams. Statuses change quickly: every fact here was checked on 27 October 2026, and you should re-check before a decision. For the underlying residency and transfer concepts, see the Data Sovereignty and Residency Guide.

Key takeaways

• Define which sovereignty you need. Data residency, operational control, legal jurisdiction, key control and disconnection resilience are separate requirements; most offerings excel at some and not others.
• Assurance beats claims. A national qualification such as SecNumCloud, an attestation such as BSI C5, or a European Commission SEAL rating is evidence; "sovereign by design" is not.
• Feature parity costs sovereignty, and vice versa. Offerings closest to the global hyperscaler have the richest services; the most independent ones have fewer services and smaller ecosystems.
• Identity is part of sovereignty. Separate IAM, where your identities live, who can operate the control plane and who holds keys matter as much as where the disks sit.
• Plan for refresh. Qualifications, service lists and partner clouds are moving; build re-validation into contracts and reviews.

The dimensions of sovereignty

The usual driver for the legal dimension is extraterritorial law, most often discussed in relation to the US CLOUD Act, together with GDPR rules on transfers to third countries (Chapter V). Contractual and technical measures reduce, but do not remove, this exposure when the operator is controlled by a non-EU parent.

The options compared

Hyperscaler offerings in detail

AWS European Sovereign Cloud

• Status: generally available since 14 January 2026, first Region eusc-de-east-1 in Brandenburg, Germany, in a separate partition aws-eusc. AWS has announced Sovereign Local Zones in Belgium, the Netherlands and Portugal.
• Operations and governance: run by EU residents located in the EU, with AWS stating it is moving to EU citizens; managed through German-law legal entities with an advisory board of EU citizens.
• Identity and metadata: a dedicated IAM system and billing; customer content and metadata such as roles, permissions and configuration stay in the EU; AWS states technical controls prevent access from outside the EU, and a European trust service provider runs certificate authority operations.
• Assurance: BSI C5, ISO/IEC 27001 and SOC reports, plus a Sovereign Reference Framework published in AWS Artifact. See the AWS European Sovereign Cloud Guide.
• In the global regions: AWS also offers over 245 digital sovereignty controls in AWS Control Tower and customer managed keys.

Microsoft Sovereign Cloud

• Sovereign Public Cloud: Microsoft-operated datacentres inside defined boundaries such as the EU Data Boundary, with customer-managed keys, External Key Management, Data Guardian, tamper-evident access logs and confidential computing, deployed through a Sovereign Landing Zone of policy-as-code templates.
• EU Data Boundary: covers the EU27 and EFTA countries; Customer Data and pseudonymised personal data in system logs are stored and processed inside it, and Professional Services Data is stored at rest inside it. Microsoft documents that limited transfers continue, that configuration information is excluded, and that Azure non-regional services need separate configuration. Microsoft 365 tenants with Multi-Geo are out of scope.
• Sovereign Private Cloud: Azure Local, Microsoft 365 Local, GitHub Enterprise Local and Foundry Local for hybrid or disconnected operation.
• National Partner Clouds: Bleu, a joint venture of Orange and Capgemini designed to meet SecNumCloud, and Delos Cloud, operated by an SAP subsidiary and aligned with German cloud platform requirements. Microsoft notes service scope and rollout can differ from global Azure. A legal news report dated 13 October 2026 stated that the ANSSI list showed Bleu as still in qualification, targeting the end of 2026. See the Azure Government and Sovereign Cloud Guide.

Google sovereign portfolio

• Google Cloud Data Boundary: software-defined residency and access controls in the public cloud, external key management, personnel access restricted by region and optional partner oversight of keys and audits. See the Assured Workloads and Sovereign Controls Guide.
• Google Cloud Dedicated: isolated infrastructure run by a local partner, built with Thales in Europe; Google states it is designed to operate for up to 12 months if the connection to Google is severed.
• S3NS: a French-law company controlled by Thales, in partnership with Google Cloud. Its PREMI3NS offering received SecNumCloud 3.2 qualification announced on 18 December 2025, covering services including Compute Engine, Cloud Storage, Cloud SQL, GKE and BigQuery, operated by S3NS staff in France.
• Google Distributed Cloud: on-premises in connected or air-gapped mode; the air-gapped mode cannot be remotely accessed or shut down by Google.

European providers and assurance schemes

• OVHcloud: SecNumCloud-qualified services include Managed VMware vSphere (qualified December 2020), SAP HANA on Private Cloud, Bare Metal Pod and, according to OVHcloud, the SNC Cloud Platform from September 2026, hosted in France and operated by staff based in Europe.
• STACKIT: the Schwarz Group's cloud, operated by Schwarz Digits Cloud GmbH and Co. KG, with seven European data centres, BSI C5 and ISO/IEC 27001, and a catalogue spanning compute, Kubernetes, databases, key management, secrets management and AI serving.
• SecNumCloud (France): ANSSI's qualification, which includes requirements on immunity from non-European extraterritorial law; ANSSI publishes a catalogue of qualified services updated at least monthly. Check the catalogue, not press releases, before relying on status. See the France SecNumCloud Guide.
• BSI C5 (Germany): an attestation of cloud controls widely used by German buyers; it is an audit report, not a jurisdiction guarantee. See the Germany BSI C5 Guide.
• European Commission Cloud Sovereignty Framework: eight sovereignty objectives (strategic, legal, operational, environmental, supply chain transparency, technological openness, security and EU law compliance) and Sovereignty Effectiveness Assurance Levels from SEAL-0 to SEAL-4, where SEAL-4 requires a full EU supply chain. In its sovereign cloud tender awarded on 17 April 2026 (up to EUR 180 million over six years), SEAL-2 was the minimum; the Post Telecom, OVHcloud and CleverCloud partnership, STACKIT and Scaleway reached SEAL-3, and the Proximus partnership using S3NS reached SEAL-2.
• EUCS: the planned EU cloud certification scheme under the Cybersecurity Act; for its current status see the EU Cybersecurity Act and EUCS Guide.

Where identity and keys fit

• Control plane identities: in a separate partition such as aws-eusc your IAM is separate, so roles, federation, service accounts and pipelines must be rebuilt, not copied. Plan workload identity and CI/CD federation per environment. See the Cloud Workload Identity Guide.
• Where your IdP lives: a sovereign cloud federated to a global identity provider moves part of your trust to that provider's jurisdiction. Decide whether the IdP itself must be sovereign for the workloads in scope.
• Provider operator access: look for approval-based operator access and logs you can review, such as access approval and access transparency features, and include operator identities in your threat model.
• Keys: external key management or customer-held HSMs reduce the provider's ability to decrypt, but only if the key service is outside the provider's control and outages are planned for. See the BYOK, HYOK and External Key Management Guide.

How to choose

Small versus large organisations: a small firm is usually best served by sovereign controls in a mainstream cloud plus strong key management, because running a second estate is costly. A large or public organisation often runs a portfolio: mainstream cloud for general workloads, a qualified or EU-owned provider for regulated data, and private cloud for the most sensitive systems.

Selection and rollout steps

1. Classify data and workloads by the sovereignty dimension each one needs, using legal advice for regulated categories. See the Data Classification Guide.
2. Shortlist by evidence: check the ANSSI catalogue, C5 reports, Commission SEAL results and the provider's own service matrix for the specific services you need.
3. Test identity and operations: pilot one workload, rebuilding federation, pipelines, logging and key management in the sovereign environment.
4. Verify exit and resilience: test data export and, where offered, disconnected operation; record the contractual exit terms. Financial entities should align this with DORA third-party requirements. See the DORA ICT Third-Party Risk and Register of Information Guide.
5. Migrate in waves with a rollback path to the original environment until each wave is stable.
6. Re-validate yearly: qualifications expire and service lists change.

Detection and measurement

• Monitor provider operator access logs and approval requests, and alert on any access without a matching ticket.
• Alert on resources created outside approved regions or partitions, using location policies.
• Monitor key service usage and denial events for external keys.
• Metrics: share of in-scope data in environments that meet its sovereignty class; number of services used that sit outside the provider's sovereign scope or data boundary; operator access events reviewed within SLA; days to renewal for each qualification or attestation relied on; percentage of sovereign workloads with tested exit plans.

Framework mapping

Common failure patterns

• Buying a label: choosing an offering called sovereign without mapping which dimension it actually satisfies.
• Assuming status: relying on a provider being "SecNumCloud" when only some services are qualified, or the qualification is still in progress.
• Forgetting metadata and support: data stays in region but logs, support tickets or configuration flow elsewhere under documented exceptions.
• Global identity, sovereign data: workloads in a sovereign environment authenticate through a global IdP and pipelines with tokens held outside it.
• Ignoring feature lag: a partner-operated cloud or new sovereign partition is chosen for a workload that depends on services or AI models not yet available there, and teams quietly route those calls back to the global cloud, undoing the sovereignty case. Check the service matrix for every dependency before committing.
• Keys inside the same trust boundary: external key management is configured, but the key service is run by the same provider under the same jurisdiction, so it adds little against compelled access.
• No exit test: the contract promises portability but nobody has exported a full workload.

Practitioner checklist

• Write down the sovereignty dimensions each workload class needs.
• Check qualification status in the ANSSI catalogue or the latest C5 report, not marketing pages.
• Confirm which specific services are within the sovereign scope.
• Review documented exceptions to data boundaries, including support and telemetry.
• Decide where the identity provider and keys for sovereign workloads must live.
• Rebuild federation, workload identities and pipelines inside separate partitions.
• Test exit and, where offered, disconnected operation.
• Diarise yearly re-validation of every status this decision relied on.

Standards and references

• European Commission: Commission advances cloud sovereignty through strategic procurement
• AWS: Opening the AWS European Sovereign Cloud
• Microsoft Learn: Microsoft Sovereign Cloud
• Microsoft Learn: What is the EU Data Boundary
• Microsoft Learn: National Partner Clouds overview
• Google Cloud: Sovereign cloud solutions
• ANSSI: Produits et services qualifiés
• OVHcloud: SecNumCloud

Related NHI Mgmt Group resources: Data Sovereignty and Residency Guide · AWS European Sovereign Cloud Guide · France SecNumCloud Guide · EU Cybersecurity Act and EUCS Guide. This guide summarises provider offerings and EU sovereignty schemes as checked on 27 October 2026 and is not legal advice.