European Sovereign Clouds vs Hyperscalers in 2026: Compliance, Pricing and Maturity Compared for Public Sector Projects

Key Points:

• The decision comes down to two variables, not a philosophy of digital sovereignty: whether your tender legally mandates SecNumCloud, BSI C5 or a national equivalent, and how egress-heavy the workload is. Everything else is secondary.
• European sovereign providers win on jurisdiction. OVHcloud, Scaleway, StackIt, Deutsche Telekom/Open Telekom Cloud, Clever Cloud, Proximus, POST Luxembourg, Exoscale and IONOS are EU/EEA-controlled entities outside the reach of the US CLOUD Act, and several hold SecNumCloud - a qualification no US-controlled entity holds on its own today.
• Hyperscalers win on breadth and managed-service maturity, and they are not non-compliant. AWS, Azure and Google Cloud all meet GDPR and ISO 27001. AWS alone publishes more than 200 services across 39 Regions worldwide; the largest European providers publish a few dozen across a handful of EU regions. The gap is jurisdictional immunity, not security.
• Pricing differs structurally. OVHcloud and Scaleway bundle instance egress; AWS, Azure and Google Cloud meter it per GB and only close the compute gap with 1-3 year commitments that clash with fixed-term public tenders.
• The decision that survives the next tender is portability. Standardize on Kubernetes, S3-compatible object storage, PostgreSQL and Terraform/OpenTofu so the same workload runs on Scaleway, OVHcloud, StackIt or a hyperscaler. Qovery is one way to get that developer experience while the cloud contract, bill and data stay in your own account and jurisdiction.

Three US providers - AWS, Microsoft and Google - held about 70% of the European cloud market in 2024, while Europe's own providers sat at roughly 15%, down from 29% in 2017 (Synergy Research Group, July 2025). Over half of EU enterprises now buy paid cloud services (Eurostat, February 2026). So most public buyers are already committed to cloud. The only open question is whose.

I have watched teams lose a year re-platforming because they treated this as a binary yes-or-no on sovereignty. It is not binary, and it is not political. It is a procurement problem with three axes - compliance, price and maturity - and a portability clause that decides whether you are trapped after the next tender. This is the version I would paste into a decision memo, with the numbers, the certificates and the primary sources behind each one.

What actually counts as a European sovereign cloud, and what doesn't?

A European sovereign cloud is one where the operating legal entity, the data, the administrators and the encryption keys all sit under EU/EEA jurisdiction. A hyperscaler region in Frankfurt or Paris does not qualify on its own, because the parent company stays subject to the US CLOUD Act regardless of where the servers physically sit.

Public-sector procurement tests three separate layers, and you should score each one:

• Data sovereignty - where the data physically resides.
• Operational sovereignty - who can technically access and administer it, and under which law those people work.
• Technical sovereignty - an open stack, a documented exit, no proprietary trap in the critical path.

The legal reason a Frankfurt region is not enough is written into US law. Under the CLOUD Act, codified at 18 U.S.C. §2713 (enacted March 2018), a US provider must disclose data in its "possession, custody, or control... regardless of whether such communication, record, or other information is located within or outside of the United States." FISA Section 702 adds intelligence-collection powers aimed at non-US persons. In their joint response to the LIBE Committee (July 2019), the EDPB and EDPS called this a genuine conflict of laws with GDPR, and - this is the part vendors gloss over - left the question of whether the CLOUD Act reaches EU subsidiaries of US companies expressly open. Unresolved is not the same as safe.

That splits the market into three categories that behave very differently in a tender:

• EU/EEA-headquartered providers: OVHcloud, Scaleway, Clever Cloud, StackIt (Schwarz Group), Deutsche Telekom / Open Telekom Cloud, Proximus, POST Luxembourg, Exoscale and IONOS.
• Hyperscaler sovereign constructs: AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, Google's S3NS with Thales, Delos Cloud with SAP.
• Plain hyperscaler EU regions, which are not sovereign in the procurement sense, whatever the region label says.

The labels that actually appear in tenders are national: SecNumCloud 3.2 (ANSSI, France), BSI C5 (Germany), ENS (Spain), the ACN qualification (Italy), and the still-unfinished EUCS scheme at EU level. Paste these five questions straight into your RFP: which legal entity signs the contract, where the support staff sit and under which law, who holds and can revoke the encryption keys, what the reversibility clause says, and what the documented data-export format and timeframe are.

How do compliance requirements differ between European sovereign providers and hyperscalers?

Both sides can document GDPR, ISO 27001 and SOC 2. The split appears at jurisdiction-based qualifications: SecNumCloud 3.2 and the sovereign tiers of national schemes require immunity from non-EU law, which a US-controlled entity cannot satisfy on its own - it needs a joint venture or a separately controlled entity to get there.

A GDPR statement never answers a sovereignty question. GDPR governs how data is processed; it says nothing about jurisdictional immunity, and since Schrems II the burden of proving supplementary measures sits on you, the controller.

SecNumCloud 3.2 is the sharpest line. The referential was updated by ANSSI in March 2022 to add explicit protection against non-EU extraterritorial law. On ANSSI's qualified-products catalogue (September 2026 edition), the qualified cloud services are French-controlled: OVHcloud (including its SNC Cloud Platform), 3DS Outscale, Cloud Temple, Orange Business Cloud Avenue, Numspot, Worldline, and - the one that matters for the hyperscaler debate - Thales's "Cloud de confiance S3NS," qualified since December 2025. Note what is not there: Scaleway is listed only as "in progress" on ANSSI's pending-qualification page, alongside Scalingo and others, and no US-controlled hyperscaler appears at all. Do not quote a provider's marketing page for its own status; quote the catalogue.

BSI C5 works differently, and buyers get this wrong constantly. C5 is not a certificate BSI issues - it is an attestation delivered by an independent auditor under ISAE 3000 against BSI's criteria catalogue, and BSI keeps no central registry of who holds one. Type 1 attests the design of controls at a point in time; Type 2 attests design and operating effectiveness over a period. So "we have C5" is not verifiable from a public register - demand the actual ISAE 3000 report, its type, and its observation period.

EUCS, the EU-wide scheme, is still a candidate as of September 2026 - not adopted, no implementing regulation. The only adopted EU cloud-adjacent scheme is EUCC (Common Criteria). The sovereignty requirements that were reportedly softened in 2024 exist in working drafts, not a published ENISA text, so treat any claim about the current EUCS immunity wording as unconfirmed and check the ENISA EUCS page and the Commission's certification framework directly.

Public buyers also get hit by sector overlays regardless of provider: NIS2 (Directive (EU) 2022/2555, in application since October 2024) covers public administration; DORA (Regulation (EU) 2022/2554, since January 2025) covers financial-sector bodies; and the EU Data Act adds switching and reversibility duties (more on that below). The practical rule: every requirement line in the tender maps to a certificate number, an audit-report reference and an expiry date, never to a web page.

Sovereignty and compliance matrix. SecNumCloud status verified against the ANSSI catalogue (September 2026); all listed IaaS providers additionally hold ISO 27001. BSI C5 is an ISAE 3000 attestation with no central registry - confirm each provider's own report. "Contested" CLOUD Act exposure means EU-incorporated but ultimately US-parented.

How does pricing really compare between OVHcloud, Scaleway, StackIt and AWS?

On list price for a comparable VM, European providers are typically cheaper than hyperscaler on-demand rates, and the gap widens sharply on egress-heavy workloads because OVHcloud and Scaleway include or zero-rate outbound instance traffic while AWS, Azure and Google Cloud meter it per GB. Hyperscalers close the compute gap mainly with 1-3 year commitments, which sit awkwardly inside a fixed-term public contract.

Break public-sector TCO into four drivers and price all four in the same spreadsheet:

• Compute - list price versus committed price.
• Egress and inter-AZ transfer - the line item that quietly dominates media, open-data and analytics workloads.
• Managed-service premium - what you pay to not run it yourself.
• In-house operations headcount - the honest counterweight, below.

Egress is where the structural difference lives. AWS gives 100 GB/month free then charges about $0.09/GB for the first tier of internet egress from an EU region (AWS); Azure is 100 GB free then about $0.087/GB (Azure); Google Cloud's Premium Tier starts around $0.12/GB with only 1 GiB/month free (Google Cloud). OVHcloud includes unlimited outbound internet traffic on Public Cloud instances, capped on speed not volume (OVHcloud), and Scaleway bundles instance egress the same way (Scaleway). For a platform pushing 5 TB a month to the public, that is the difference between a rounding error and a real bill. The EU Data Act (Regulation (EU) 2023/2854, Article 29) reinforces the direction: switching charges must be fully withdrawn from 12 January 2027.

Commitment models - Savings Plans, Reserved Instances, Committed Use Discounts, Enterprise Discount Programs - are real money, often 30-60% off. But they trade flexibility for price at exactly the moment a tender demands reversibility. Locking three years of spend to win a discount, then being asked to prove you can exit in 90 days, is a contradiction you have to resolve on paper before you sign.

The honest counterweight: fewer managed services on the sovereign side usually means more platform and SRE effort. One extra platform engineer in Western Europe costs well north of €80,000 a year loaded - frequently more than the entire infrastructure delta on a mid-size workload. If you save €1,500 a month on compute and spend it plus more on a headcount to operate raw Kubernetes, you did not save anything. Price the people in the same model as the machines.

To keep the comparison falsifiable, here is a reference basket you can re-price yourself: 3 x 8 vCPU / 32 GB nodes, 1 TB block storage, 5 TB monthly internet egress, one managed PostgreSQL (4 vCPU / 16 GB) and one managed Kubernetes control plane. Price it from the public pages, date the snapshot, and the egress line alone will usually decide the ranking.

Pricing and commercial model. On-demand compute for a ~8 vCPU / 32 GB general-purpose instance, monthly (730h), as of September 2026 from each provider's public pricing page; treat figures as list-price snapshots and re-verify before quoting. "Included" egress means instance traffic is bundled and speed-capped, not volume-metered. IONOS prices per component, so use its calculator.

How mature is the infrastructure of European sovereign clouds compared to hyperscalers?

European sovereign providers now cover the 80% most public-sector workloads actually need - VMs, bare metal, S3-compatible object storage, managed Kubernetes, managed PostgreSQL, load balancing and EU-hosted GPUs - but they trail badly on catalog breadth, global region count, deep IAM and mature managed analytics. If your project is a web application with a database, the gap is irrelevant. If it depends on a specific managed analytics or serverless stack, the gap is the whole decision.

The breadth numbers are not close. AWS publishes more than 200 services across 39 Regions and 124 Availability Zones worldwide (AWS); Azure states 80+ regions and 200+ products (Azure); Google Cloud lists 43 regions and 130 zones (Google Cloud). Against that, OVHcloud runs 46 datacentres across four continents (OVHcloud), Scaleway operates three core regions plus Milan (Scaleway), StackIt runs seven datacentres in Germany and Austria (StackIt), and Exoscale spans eight zones across six European cities (Exoscale). Dozens of services versus hundreds - real, and usually irrelevant to a standard web workload.

Where European providers are genuinely strong: bare-metal and price-performance (OVHcloud, Scaleway), CNCF-conformant managed Kubernetes (Scaleway Kapsule, OVHcloud MKS, StackIt SKE, Exoscale SKS, IONOS), S3-compatible object storage across all of them, and EU-hosted GPU capacity - OVHcloud runs H100/H200 in Gravelines, Scaleway H100 in Paris. Where the gap bites: serverless and event-driven breadth, mature managed data warehousing, global multi-region failover, fine-grained IAM and organization hierarchies, and marketplace depth.

Resilience is evidence you demand, not assume. The reference case is the OVHcloud SBG2 fire in Strasbourg on the night of 9-10 March 2021: the datacentre was destroyed, roughly 14,000 servers lost, and around 3.6 million websites went offline. The French BEA-RI investigation report (May 2022) found the site had fire detection but no automatic fire-suppression system. It reshaped French public tenders, which now routinely require multi-region backup and a tested restore. Ask any provider - European or hyperscaler - for its SLA percentage and credit schedule, its status-page incident history, and public postmortems. And read the SLA fine print: AWS EC2's 99.99% needs multiple AZs (a single instance is 99.5%), OVHcloud publishes 99.99% monthly per instance, Scaleway's production tier is 99.5% monthly, Exoscale is 99.95% monthly, and Clever Cloud's headline is 99.9% annual. A monthly 99.5% and an annual 99.9% allow very different real downtime.

Tooling compatibility decides migration cost more than feature count. If a provider has an official Terraform/OpenTofu provider, CNCF Kubernetes conformance, S3 API compatibility and OIDC, most of your existing IaC and CI/CD runs unchanged. All the major European providers below clear that bar.

Infrastructure maturity. Kubernetes conformance from the CNCF conformance program; Terraform providers from the Terraform Registry; SLAs from each provider's official SLA document; verified September 2026. "Verify" means not confirmable from a primary source at time of writing.

Are hyperscaler sovereign cloud offerings a real alternative for public sector buyers?

They are a real option and often the pragmatic one, because you keep the same APIs, tooling and skills. But they reduce operational-access risk without removing vendor lock-in, they carry a price premium, they lag the mainline regions on features, and EU lawyers still disagree on whether an EU-incorporated subsidiary of a US parent is genuinely out of CLOUD Act reach.

The four main constructs, each factual and sourced:

• AWS European Sovereign Cloud launched its first region in Brandenburg, Germany, in January 2026, backed by a committed €7.8 billion investment through 2040 and run by a dedicated German-incorporated entity operated exclusively by EU residents (AWS). The ultimate parent is still Amazon.
• Microsoft Cloud for Sovereignty, layered on the EU Data Boundary, which Microsoft completed in February 2025, keeping customer data, system-log personal data and professional-services data within the EU/EFTA.
• Google S3NS, a French company controlled by Thales with Google Cloud technology, whose PREMI3NS offering obtained SecNumCloud 3.2 qualification in December 2025 - the one hyperscaler-adjacent stack that clears the French bar, precisely because Thales, not Google, controls it.
• Delos Cloud, an SAP subsidiary running on Microsoft Azure technology, operated in Germany by Arvato Systems for German public administration.

The unresolved legal question is not mine to settle, so I will point at the institution instead of an opinion piece: the EDPB and EDPS, in their 2019 joint response, explicitly left open whether corporate separation defeats a CLOUD Act production order, while confirming the conflict of laws with GDPR. No court has ruled on it. So these constructs offer operational separation and a commitment to challenge orders, not adjudicated legal immunity.

The honest upside: no retraining, no re-platforming, your Terraform and Kubernetes manifests carry over, and a migration avoided is often a year of engineering saved. The honest downside: premium pricing, delayed feature parity with mainline regions, a smaller catalog than the parent cloud, and an exit cost that is unchanged. My advice is to stop treating sovereignty as pass/fail and score two separate axes in the tender - jurisdictional risk (who can be compelled to hand over data, under which law) and delivery risk (feature fit, maturity, exit cost) - then weight them for your specific workload rather than arguing the politics.

How do you choose a provider, and stay able to switch, without betting the whole project on one vendor?

Choose in this order: first eliminate anything that fails the tender's legal bar, then weigh egress volume and managed-service dependency, then pick on price. Whatever you pick, design the workload so switching costs stay low - Kubernetes for compute, the S3 API for objects, PostgreSQL for data, Terraform or OpenTofu for provisioning, OpenTelemetry for observability, and nothing proprietary in the critical path.

A four-question decision path you can run in an afternoon:

1. Does the tender mandate SecNumCloud, C5 or a national equivalent? If yes, your shortlist is the qualified list, full stop.
2. Is the workload egress-heavy (more than ~2 TB/month)? If yes, bundled-egress providers move up hard.
3. Does it depend on a managed service with no EU equivalent? If yes, a hyperscaler or its sovereign construct may be unavoidable.
4. Is there in-house capability to operate Kubernetes? If no, favour a fully-managed PaaS or price the headcount in.

The portability checklist, each item testable in a review:

1. CNCF-conformant Kubernetes.
2. S3-compatible object storage.
3. Standard PostgreSQL/MySQL with no proprietary extensions.
4. OpenTelemetry for traces, metrics and logs.
5. Terraform/OpenTofu state owned by the buyer.
6. Container images in a registry you control.
7. No proprietary queue or event service in the critical path.

Then write the contract to match: data-export format and a maximum export timeframe, zero switching or egress fee at exit (grounded in the EU Data Act, Article 29), a documented and tested exit runbook, and buyer ownership of the IaC repository.

This is where Qovery fits, and only here. Qovery is a cloud-agnostic, Kubernetes-native internal developer platform that deploys into your own cloud account (AWS, GCP, Azure, Scaleway) or your own existing Kubernetes cluster - including one running at OVHcloud, StackIt, IONOS or any other European provider. The cloud contract, the bill and the data stay in the buyer's name and jurisdiction. You get git-push deployments, a preview environment per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services.

Let me be precise about what Qovery is not, because this audience deserves it: Qovery is not a cloud provider, it holds no sovereignty certification, and it does not make any provider compliant. It is the developer-experience and portability layer on top of whichever provider your tender selects. If SecNumCloud is mandatory, you still pick a SecNumCloud-qualified provider - Qovery just means the same workflow works there and on the next provider too.

And the alternatives, fairly: Clever Cloud is a legitimate fully-managed French PaaS if you want the provider to run the infrastructure as well; Scalingo is a comparable French PaaS; a self-built platform on Backstage plus Argo CD suits teams with a dedicated platform group. Qovery suits teams that need the infrastructure inside their own account and want to stay portable across providers.

Decision guide by scenario. "Provider category" points at a class, not a single vendor; the portability checklist applies in every row.