EU Cloud Infrastructure Comparison Finale 2026: Hetzner vs Scaleway vs OVHcloud vs IONOS — CLOUD Act Immunity Decision Framework

Post #1307 in the sota.io EU Cyber Compliance Series — EU-CLOUD-INFRA #5/5 COMPLETE

The most common misconception in enterprise cloud architecture is that AWS's Frankfurt region is "European infrastructure." It is not. AWS eu-central-1 is a facility operated by a Delaware C-Corporation subsidiary under parent-company control of Amazon.com Inc. (NASDAQ: AMZN), incorporated in Delaware and subject to the full scope of 18 U.S.C. § 2703 — the CLOUD Act. The physical servers are in Germany. The legal jurisdiction is the United States of America.

This finale closes the EU Cloud Infrastructure Providers series. Over five posts, we ran Hetzner, Scaleway, OVHcloud, and IONOS through the same five-dimension CLOUD Act exposure framework used across every series on this blog — and compared each against AWS (23/25), Azure (22/25), and GCP (21/25). The results reveal a structural divide that cannot be bridged by contractual means.

All four EU providers score between 0/25 and 1/25 on CLOUD Act exposure. All three US hyperscalers score 21-23/25. The gap between them is not a matter of compliance certifications, security posture, or SLA quality. It is a matter of corporate jurisdiction — and corporate jurisdiction cannot be changed with a data processing agreement.

CLOUD Act Exposure Matrix — All Seven Providers

Higher score = higher CLOUD Act exposure risk. All four EU providers have genuine CLOUD Act immunity due to non-US corporate structure.

The D1 score (Corporate Jurisdiction) is the decisive variable. AWS, Azure, and GCP each score 5/5 because their respective parent companies — Amazon.com Inc., Microsoft Corporation, and Alphabet Inc. — are incorporated in Delaware and subject to CLOUD Act §2703 compelled disclosure without any threshold of harm to US foreign policy interests. The EU providers all score 0/5 on D1 because none of them has a US parent, a US subsidiary that controls EU data, or a legal obligation to respond to US CLOUD Act demands.

Everything else in the matrix — routing, subprocessors, personnel, legal framework — flows from that single D1 determination.

Why the CLOUD Act Matters for IaaS Specifically

The IaaS layer is where the discussion of CLOUD Act risk is most straightforward, and most commonly misunderstood in enterprise architecture reviews. Let us be precise about what CLOUD Act §2703 actually permits.

A US government agency — federal law enforcement, intelligence services, or agencies acting under FISA — can compel an entity that is a "provider of electronic communication service or remote computing service" to produce stored communications and records without notifying the data subject and without the requirement to first seek legal assistance through the EU-US MLA Treaty (Mutual Legal Assistance). The compelled production order can be issued to any US-incorporated entity that has control over the data, regardless of where the data physically resides.

For IaaS specifically, the practical consequence is as follows:

When you run workloads on AWS eu-central-1, your data exists on physical hardware in Frankfurt. But the entity that controls access to that hardware — including the ability to snapshot volumes, provide encryption keys, copy object storage buckets, or grant emergency access to support engineers — is AWS Inc., a Delaware corporation. A CLOUD Act order directed to AWS Inc. requires AWS to produce your EU-hosted data to US authorities. AWS cannot legally refuse. The physical location of the servers is irrelevant to the jurisdictional analysis.

The EU-US Data Privacy Framework (2023) does not change this. The DPF applies to transfers of EU personal data to the US for commercial purposes. CLOUD Act compelled disclosure is a law enforcement process, not a commercial data transfer. The European Commission's adequacy decision for the DPF explicitly does not constitute a determination that CLOUD Act compelled disclosure of EU personal data is lawful under GDPR Chapter V.

This is the jurisdictional gap that cannot be contracted around.

The Three Category-Level Risk Patterns in EU Cloud Infrastructure

Across this series, three structural risk patterns emerged that are specific to the IaaS category — patterns that apply regardless of which hyperscaler you use, and that disappear entirely when you move to EU-incorporated IaaS providers.

1. The EU-Region Sovereignty Illusion

This is the most pervasive misconception in enterprise cloud governance. The EU-Region Sovereignty Illusion is the belief that running workloads in an AWS, Azure, or GCP EU region provides meaningful sovereignty protection because the data is "in Europe."

The illusion operates on a conflation of two distinct concepts: data residency and data sovereignty. These are not the same thing:

• Data residency means the physical storage location of data. AWS Frankfurt provides German data residency.
• Data sovereignty means the jurisdictional authority over data access. AWS Frankfurt provides US data sovereignty — because the corporate entity controlling the data is subject to US law.

An EU-region deployment on AWS provides data residency in Europe but data sovereignty in the United States. For GDPR Article 44-49 purposes (third-country transfer restrictions), the relevant analysis is jurisdictional control, not physical location. The EDPB's Recommendations 01/2020 on supplementary measures establish that the relevant question for cross-border transfer risk assessment is: "which national law applies to the provider's obligation to disclose the data?" For AWS eu-central-1, that law is US federal law.

The EU-Region Sovereignty Illusion affects the majority of "EU data strategy" documents produced by European enterprises. It is reinforced by AWS marketing language around "AWS European Sovereign Cloud" — a commercial differentiation that addresses some operational sovereignty concerns (EU staff, EU governance) without addressing the fundamental CLOUD Act jurisdictional exposure of the parent corporation.

2. The Compliance Certification vs. Jurisdiction Immunity Confusion

AWS, Azure, and GCP each hold comprehensive EU compliance certifications: ISO 27001, ISO 27017, ISO 27018, BSI C5, ENS (Spain), SecNumCloud (GCP France), HDS (France), and dozens of others. These certifications are operationally valuable. They are also jurisdictionally irrelevant to CLOUD Act exposure.

BSI C5 (Cloud Computing Compliance Criteria Catalogue) audits operational security controls: access management, encryption at rest and in transit, incident response, vulnerability management, physical security of data centres. A positive BSI C5 attestation Type II means the audited provider operates its security controls effectively and consistently.

BSI C5 does not address whether the provider is subject to US CLOUD Act compelled disclosure. The German Federal Office for Information Security (BSI) has explicitly stated in its BSI-CC-PP documentation that the C5 framework does not evaluate legal jurisdiction exposure and does not constitute a determination of CLOUD Act immunity. A provider can hold BSI C5 Type II attestation while being fully subject to CLOUD Act §2703 compelled disclosure.

This confusion is consequential: DPIAs (Data Protection Impact Assessments) produced by legal teams frequently treat BSI C5 or ISO 27018 certification as evidence that cross-border transfer risks are adequately mitigated. They are not — because those certifications address a different risk dimension than jurisdictional compelled disclosure.

For DPIA purposes under GDPR Article 35, the relevant assessment for CLOUD Act exposure requires evaluating corporate jurisdiction, not compliance certifications. EU-incorporated providers (Hetzner, Scaleway, OVHcloud, IONOS) are the correct mitigating control.

3. The Support Engineer Access Gap

All four US hyperscalers operate global support engineering organisations with personnel in the United States, India, and other non-EU countries. When you open a support ticket for a production incident on your EU-region workload, the engineer who accesses your environment metadata, reviews your instance configuration, or applies a fix to your running container may be located in Seattle, Hyderabad, or Singapore.

This personnel access creates a secondary CLOUD Act exposure pathway that is distinct from direct subpoena of stored data. Support engineer access to EU-hosted data from US-located personnel constitutes a data transfer under GDPR Article 44-49. Standard "EU data residency" commitments do not address support access — they typically apply only to data storage locations, not to operational access by support personnel.

Hetzner, Scaleway, OVHcloud, and IONOS all operate with predominantly EU-based support staff and explicitly contractually limit support access to EU-jurisdictional personnel for enterprise tiers. This closes the support-access transfer gap.

Provider-Level Differentiation: Choosing Within the EU Tier

All four EU providers provide CLOUD Act immunity through EU corporate structure. The differentiation within the EU tier is not jurisdictional — it is operational, regulatory, and geographic.

Hetzner — The Sovereign Baseline (0/25)

Hetzner Online GmbH (Gunzenhausen, Bavaria) remains the most structurally sovereign option in this comparison. As a privately held GmbH with zero US investor exposure, no US-listed parent, no US cloud regions, and no US support operations, Hetzner achieves 0/25 across all five CLOUD Act dimensions.

The Hetzner risk profile is operationally different from the 1/25 providers: there are no partial scores anywhere. D4 (Personnel Access) is 0/5 because there is no US-based engineering or support organisation. The residual 1/5 scores that Scaleway, OVHcloud, and IONOS carry in D2 or D4 reflect minor architectural or organisational components with non-EU elements — Hetzner has none.

Best for: Price-sensitive EU workloads where CLOUD Act immunity is required, German BaFin-regulated financial services, healthcare under German KBVS/DIGA regulations, and workloads where cost-efficiency matters as much as sovereignty.

Limitation: Smaller managed service catalogue than hyperscalers; fewer geographic regions than OVHcloud; no SecNumCloud certification (French government procurement).

Scaleway — The French EU Alternative (1/25)

Scaleway SAS (Paris, France) achieves 1/25 due to a minor D4 exposure: Scaleway's parent company (Iliad Group) has some internationally distributed operational staff. The core jurisdictional protections are complete: Scaleway is a French SAS with EU-only data centres, protected by the French Blocking Statute (loi n° 68-678) which criminalises compliance with foreign law enforcement demands for French business records without prior French judicial authorisation.

The loi de blocage adds a layer of legal defence that other EU providers lack. A CLOUD Act §2703 compelled disclosure directed at Scaleway SAS encounters not just jurisdictional inapplicability but active French criminal law prohibiting compliance.

Best for: French public sector procurement requiring ANSSI-recognised providers, EU workloads where French Blocking Statute legal defence is valued, and organisations in Iliad's managed service ecosystem.

Limitation: The SecNumCloud ANSSI qualification applies to Scaleway's sovereign cloud products, not to its standard commercial products. Enterprise customers should verify which tier of service they require for their compliance context.

OVHcloud — The SecNumCloud Option (1/25)

OVHcloud SAS (Roubaix, France) achieves 1/25 due to a D2 partial exposure: OVHcloud's global data centre network includes non-EU facilities (US, APAC), and the routing architecture for global load balancing includes some traffic management infrastructure with non-EU components. For EU-region workloads with explicit EU-region network configuration, this exposure is effectively zero — but the score reflects the architectural possibility of D2 exposure in misconfigured deployments.

OVHcloud's SecNumCloud ANSSI qualification (awarded 2024 for specific product tiers) is the most significant regulatory certification in this comparison for French government and defence procurement contexts. SecNumCloud is the only EU certification framework that explicitly evaluates and certifies CLOUD Act immunity — it requires the provider to be incorporated in France, operated by predominantly French personnel, and structured to prevent compelled disclosure to non-French authorities.

Best for: French government procurement (only SecNumCloud-qualified providers are eligible for many French public sector contracts), defence-adjacent workloads, organisations that need both SecNumCloud and global availability.

Limitation: D2 routing exposure in global configurations; SecNumCloud qualification applies only to specific product tiers, not OVHcloud's entire portfolio.

IONOS — The German Compliance Architecture (1/25)

IONOS SE (Montabaur, Rhineland-Palatinate) achieves 1/25 due to D2 partial exposure: IONOS's global hosting subsidiary (1&1 IONOS Inc., a US entity) handles some North American market operations, which creates a theoretical D2 exposure pathway for organisations using IONOS's global product portfolio. EU-region dedicated products do not route through US infrastructure, but the organisational structure of the global IONOS group includes US legal entities.

IONOS's BSI C5 Type II attestation (the only BSI-certified provider in this comparison alongside AWS) is operationally significant for German federal procurement. While BSI C5 does not certify CLOUD Act immunity, it is the mandatory certification framework for providers serving German federal government entities under the BSI-Grundschutz methodology.

Best for: German federal and state government procurement contexts where BSI C5 is a procurement requirement, enterprises already within the United Internet AG ecosystem (1&1, IONOS), and organisations requiring both CLOUD Act immunity and German federal compliance certification.

Limitation: The 1/25 D2 score reflects the global subsidiary structure; EU-dedicated deployments can mitigate this but require configuration diligence.

Enterprise Decision Framework: Choosing EU Cloud Infrastructure

The following framework maps enterprise use cases to the appropriate EU IaaS provider based on regulatory context, geographic requirements, and operational needs.

Framework Input Variables

Regulatory Authority — Which national or EU authority has primary jurisdiction over your compliance obligations?

Certification Requirement — Does your regulatory context mandate a specific certification (BSI C5, SecNumCloud, ISO 27001)?

Geographic Reach — Do you require global PoPs, multi-region EU distribution, or single-region concentration?

Cost Sensitivity — Is infrastructure cost a primary selection criterion alongside sovereignty?

Decision Matrix

Hard Blockers for US Hyperscalers

The following regulatory and contractual contexts should be treated as hard blockers for AWS/Azure/GCP regardless of EU-region deployment:

1. Sector-specific data localisation mandates — German eHealth (§ 393 SGB V), French données de santé (HDS Décret), and KRITIS-Dachgesetz (expected 2026-07-17) all contain language that legal counsel has increasingly interpreted as requiring EU-incorporated provider corporate structure, not merely EU-region data residency.

2. DORA Art.28 Critical ICT Third-Party Risk — Financial entities subject to DORA must perform legal jurisdiction analysis of critical ICT third-party providers as part of the contractual arrangements review. Law firms advising EU financial entities have begun issuing guidance that CLOUD Act exposure of critical ICT providers requires board-level risk acceptance, not merely DPA execution.

3. NIS2 Art.21 Security Measures — The supply chain security requirements of NIS2 (transposed into national law by most EU member states since late 2024) require operators of essential services to assess the jurisdictional exposure of their IaaS providers. A CLOUD Act-exposed provider used for NIS2-covered infrastructure creates a documented supply chain risk that national NIS2 authorities can flag during audits.

4. Public procurement rules in France and Germany — French ITAR/DPAR procurement rules and German BSI-Grundschutz procurement guidelines both create certification requirements that de facto exclude CLOUD Act-exposed providers from specific contract categories.

The Sovereignty Spectrum: A Unified View

Across all five posts in this series, one pattern is consistent: the gap between 0/25 and 23/25 is not a gradient — it is a categorical divide.

The CLOUD Act exposure gap between EU providers and US hyperscalers is not primarily about features, pricing, performance, or even security practice. All four EU providers in this series are significantly less feature-rich than AWS. All four are cheaper than AWS for comparable compute. None of them has closed the managed service gap on ML, serverless, or managed database offerings. These are real operational trade-offs.

But the sovereignty trade-off is structural and categorical. A company running workloads on Hetzner cannot receive a CLOUD Act compelled disclosure order targeting its infrastructure provider's control over customer data — because Hetzner is a German GmbH that is not subject to US law enforcement jurisdiction. A company running the same workloads on AWS eu-central-1 can. The physical location of the servers does not change this.

The decision between EU IaaS and US hyperscaler IaaS is therefore not primarily a technical decision. It is a legal and governance decision: is the company prepared to accept US law enforcement jurisdiction over its infrastructure provider as a component of its third-party risk register?

For an increasing number of European enterprises — particularly those subject to NIS2, DORA, sector-specific German and French regulations, and public procurement rules — the answer to that question has a correct and a wrong answer. This series has provided the technical framework to make that determination precisely.

EU-CLOUD-INFRA Series Summary

Data current as of May 2026. CLOUD Act scores apply five-dimension framework: D1 Corporate Jurisdiction, D2 Data Routing, D3 Subprocessors, D4 Personnel Access, D5 Legal Framework.

The EU-CLOUD-INFRA series joins a growing body of technical sovereignty analysis on this blog covering every major SaaS and IaaS category. The pattern is consistent across categories: EU-incorporated providers eliminate D1 (Corporate Jurisdiction) exposure entirely, reducing total CLOUD Act risk by approximately 80-100% compared to their US counterparts, at the cost of a smaller managed service catalogue and reduced global reach.

For European enterprises making IaaS decisions in 2026 — under NIS2 enforcement, DORA application, evolving KRITIS-Dachgesetz requirements, and continued EDPB enforcement of GDPR Chapter V — the technical sovereignty case for EU IaaS is stronger than it has ever been. The compliance case is approaching the point of being determinative in regulated sectors.

What Comes Next

The EU-CLOUD-INFRA series closes here. Future series on this blog will continue to apply the same CLOUD Act five-dimension framework to additional SaaS categories where jurisdictional analysis is material to EU enterprise procurement decisions.

For organisations building the EU sovereignty infrastructure stack, the complete sovereign baseline across all analysed categories is documented in posts throughout this series. The pattern does not change: EU corporate structure eliminates CLOUD Act exposure; US corporate structure — regardless of EU-region deployment, contractual commitments, or compliance certifications — does not.

This analysis is based on publicly available corporate registry information, legal scholarship on CLOUD Act jurisdiction, EU regulatory guidance from EDPB, ENISA, CNIL, BSI, and ANSSI, and provider documentation. It does not constitute legal advice. Organisations with specific regulatory requirements should seek qualified EU data protection legal counsel for their DPIA and third-party risk assessment processes.