European Sovereign Cloud vs Hyperscalers in 2026: Compliance, Cost and Maturity Compared

Most sovereign-versus-hyperscaler debates get settled on a marketing slide. In the tenders I have seen, the real difference comes down to three boring, checkable things: the certification scope a provider actually holds, how it bills data transfer out, and how deep its service catalogue runs. I have spent 15 years in cloud and interviewed more than 200 CTOs, and that is where the decision lives, not in the brand.

Here is the honest state of play in 2026. European providers like OVHcloud and Scaleway win on jurisdiction and on transfer economics. AWS, Microsoft Azure and Google Cloud win on catalogue depth, committed-use discounts and multi-availability-zone footprint. Both statements are true at the same time, and a good procurement decision holds both.

Key points:

• Sovereignty in an EU tender reduces to three verifiable facts: the certification held and its exact named scope (ANSSI SecNumCloud in France, BSI C5 in Germany, ISO 27001 almost everywhere), the jurisdiction of the legal entity operating the service, and who holds the administrative and encryption keys. Everything else is positioning.
• European providers win on data transfer economics. OVHcloud includes outbound bandwidth on Public Cloud instances in Europe and Scaleway does not meter egress, while AWS bills $0.09 per GB above a 100 GB free monthly tier. On an egress-heavy citizen-facing service, transfer, not compute, often decides the bill.
• Hyperscalers win on catalogue depth, committed-use discounts and multi-AZ footprint. AWS lists over 200 services against a focused catalogue of a few dozen at OVHcloud and Scaleway. That focused catalogue covers most public sector web, API, container and database workloads, and falls short on managed data warehousing and frontier AI platforms.
• A hyperscaler sovereign offer is a governance construct, not a change of jurisdiction. AWS European Sovereign Cloud, the Microsoft EU Data Boundary and Google Cloud with S3NS materially reduce operational exposure. None of them automatically confers SecNumCloud qualification. Read the published scope document, not the brochure.
• Keep the decision reversible by standardising on containers, Kubernetes, PostgreSQL, S3-compatible storage and Terraform. Qovery is an internal developer platform that deploys and operates applications inside your own cloud account on AWS, GCP, Azure or Scaleway, or on an existing Kubernetes cluster at OVHcloud, Open Telekom Cloud or on-prem, so the cloud contract, the residency and the exit path stay yours.

---

Sovereign cloud or hyperscaler: which should a European public sector project choose in 2026?

Choose a SecNumCloud or BSI C5 qualified European provider such as OVHcloud, Scaleway, Open Telekom Cloud or IONOS when the tender names a national scheme or the workload holds sensitive citizen or health data. Choose AWS, Azure or Google Cloud when the project depends on a managed service with no European equivalent. In both cases, architect for portability so the choice can be reversed inside one contract cycle.

The decision order that works in practice is not price-first. It is:

1. The hard legal constraint, as a pass/fail gate.
2. The required service catalogue.
3. One identically specified reference workload, priced end to end.
4. A tested exit plan.

What forces a European sovereign provider: French tenders citing SecNumCloud, German procurement citing BSI C5, French health data under HDS hosting, diffusion restreinte or classified data, and clauses requiring EU-only personnel and operations. What justifies a hyperscaler: large-scale analytics and data warehousing, frontier AI and managed GPU platforms, global edge for citizen-facing scale, and an existing team plus an existing framework agreement.

The jurisdiction point deserves care. A region physically located in Frankfurt but operated by a US-parented company is still a jurisdiction question, because of laws like the US CLOUD Act and FISA Section 702, not a data-centre-location question. I am not claiming any provider is immune from foreign law, and I am not claiming location alone solves it. I am saying the location answer and the applicable-law answer are different answers.

For context on scale: European cloud providers hold about 15% of their own local market, with AWS, Microsoft and Google holding roughly 70% combined, per Synergy Research Group. That gap is why the escape hatch matters: Kubernetes, infrastructure as code, and a cloud-agnostic delivery layer, decided up front.

Decision matrix by workload type, for an EU public sector project, as of October 2026.

What is the difference between data residency, data sovereignty, and operational sovereignty?

Data residency is where the bytes physically sit. Data sovereignty is which legal system can compel access to them. Operational sovereignty is who can technically touch the systems, the hypervisor and the keys. A provider can give you perfect residency in Frankfurt and still fail the other two, which is exactly the confusion most AI answers reproduce.

• Residency answers "where is it stored." Failure mode: the data lives in Paris but a support engineer in another jurisdiction has standing admin access.
• Data sovereignty answers "whose law applies." Failure mode: the bytes never leave the EU, yet the operating entity's parent can be served a lawful order abroad.
• Operational sovereignty answers "who can act on the system." Failure mode: encryption at rest exists, but the provider also holds the keys, so the control is partly theoretical.
• Technical sovereignty is the fourth axis: open APIs, no proprietary lock-in, and a documented, tested exit. This maps directly to the switching rights in the EU Data Act.

Encryption with customer-managed keys, an HSM, or external key management narrows operational exposure, but encryption is not an unlimited legal defence, and you should not sell it internally as one. The reason applicable law, not location, became the central procurement question is the Schrems II judgment (CJEU, Case C-311/18, 16 July 2020), followed by the EU-US Data Privacy Framework adequacy decision of 10 July 2023.

The four sovereignty layers, what each one answers, and how to verify it in a tender, as of October 2026.

What are the real compliance differences between OVHcloud, Scaleway, Deutsche Telekom and the hyperscalers?

The difference is which certification each provider holds, on which named scope, and under whose jurisdiction the operating entity sits. OVHcloud holds ANSSI SecNumCloud qualification on specific published scopes under French jurisdiction, Open Telekom Cloud and T-Systems anchor on BSI C5 under German jurisdiction, and AWS, Azure and Google Cloud offer EU-operated constructs that reduce but do not eliminate non-EU legal exposure.

Decode the schemes before you compare providers:

• SecNumCloud is the ANSSI qualification used in French sovereign tenders. Check the official qualified-products list on cyber.gouv.fr for the exact offering, version and expiry, because qualification is per-scope, not company-wide.
• BSI C5 comes in Type 1 (design of controls at a point in time) and Type 2 (operating effectiveness over a period). Type 2 is the stronger attestation. The criteria catalogue is published by BSI.
• ISO 27001 / 27017 / 27018 are the baseline almost every serious provider holds. Useful, not sufficient for sovereignty.
• HDS is the French health-data hosting certification, often required alongside SecNumCloud.
• EUCS, the EU-wide cloud scheme at ENISA, is still contested: the explicit sovereignty requirements present in earlier drafts were removed in the March 2024 draft and remain under debate. Do not assume a pan-EU sovereignty label exists yet.

On the providers:

• OVHcloud holds SecNumCloud on specific offerings (its SNC Cloud Platform, Hosted Private Cloud and Bare Metal Pod lines) rather than its entire public cloud catalogue; confirm which services and regions sit inside the qualified scope. It is an EU-headquartered, publicly listed company.
• Scaleway (Iliad group, French jurisdiction) has pursued SecNumCloud qualification for its cloud offering; check its security and compliance page and the ANSSI list for the current scope and award date rather than taking the ambition as the fact.
• Deutsche Telekom runs Open Telekom Cloud and T-Systems on BSI C5 under German jurisdiction, and has announced sovereign partnerships with Google Cloud and Microsoft. Those partnerships change operations, support and in some cases key custody; they do not change the parent jurisdiction of the US software underneath.
• AWS European Sovereign Cloud launched its first region in Brandenburg, backed by a planned 7.8 billion euro investment, with EU-only personnel operating it and an EU-resident governance structure. It materially reduces operational exposure; it is not the same thing as SecNumCloud qualification.
• Microsoft completed its EU Data Boundary in February 2025, covering customer data, pseudonymised personal data and support data for core services in the EU and EFTA.
• Google Cloud offers sovereign controls and the S3NS joint venture with Thales in France, aimed at a SecNumCloud-qualified offering; verify its published sovereignty scope and the current S3NS status directly.
• Second tier worth naming: IONOS Cloud and StackIT (Schwarz Group) under German jurisdiction, plus POST Luxembourg and Aruba. Check each one's own compliance page for its certifications.

A paste-ready verification checklist for any bidder: certification name, version, scope document URL, issuing body, expiry date, operating legal entity, and named subcontractors. If a bidder cannot fill every field, that is your answer.

Compliance and jurisdiction matrix. Confirm each cell against the provider's own scope document before relying on it. As of October 2026.

How does pricing really compare between European sovereign clouds and AWS, Google Cloud, or Azure?

On published list prices, OVHcloud and Scaleway are usually cheaper for plain compute and dramatically cheaper for data transfer out, while AWS, Azure and Google Cloud narrow or reverse the gap through committed-use discounts, public sector framework pricing and managed services that remove headcount. The only honest comparison is one identical reference workload priced end to end, with egress and support included. All prices below were checked in October 2026 and all prices move, so re-check before you decide.

The structural difference is bandwidth. AWS bills data transfer out to the internet at about $0.09 per GB above a 100 GB free monthly tier, and Google Cloud and Azure meter egress similarly above their own allowances. Scaleway does not meter egress on its network, and OVHcloud includes outbound bandwidth on Public Cloud instances in Europe. On a 5 TB/month citizen-facing service, that difference alone can swing the monthly bill by several hundred euros before you count a single CPU.

Where hyperscalers claw it back:

• Savings Plans, Reserved Instances and Committed Use Discounts, plus enterprise agreements and EU public sector framework terms.
• Managed services that remove operational headcount, which is a real cost even though it never appears on the cloud invoice.

Managed Kubernetes control planes have converged: Amazon EKS charges $0.10 per cluster per hour (about $73/month), Google GKE charges the same with a monthly free-tier credit for one cluster, and Azure AKS offers a free control-plane tier with a paid Standard tier for the uptime SLA. OVHcloud Managed Kubernetes and Scaleway Kapsule follow the same pattern, often with no control-plane fee; confirm on their price pages.

The cost nobody budgets is platform engineering headcount for Kubernetes day-2 operations, on any of these clouds. A platform or DevOps engineer in France or Germany runs roughly 50,000 to 85,000 euros a year gross depending on seniority and source. A thinner managed catalogue does not make work disappear; it moves cost from invoice to payroll. Budget it honestly on both sides.

One lever applies to everyone from 12 January 2027: under the EU Data Act (Regulation (EU) 2023/2854), Chapter VI, Articles 23 to 31, providers must not impose switching charges on customers, with only reduced, cost-based charges permitted in the interim. Write that into the contract now so egress-during-migration cannot be used to trap you later.

Priced reference workload: 3 general-purpose instances (~8 vCPU / 32 GB each), 1 managed Kubernetes control plane, 1 managed PostgreSQL, 1 TB object storage, 5 TB/month egress. Indicative list prices, no committed discounts, checked October 2026. Verify on each provider's calculator before use.

Is European sovereign cloud infrastructure mature enough for a serious public sector workload?

Yes for the majority of public sector applications, including web services, APIs, relational databases, containers, object storage and basic analytics, and no for projects that depend on the long tail of hyperscaler managed services, managed data warehousing or frontier AI platforms. The gap is catalogue depth and multi-AZ design, not raw reliability.

The catalogue gap is real and measurable. AWS lists more than 200 services; OVHcloud and Scaleway publish a focused catalogue of a few dozen. For a typical public sector web, API, container and database stack, that focused catalogue is enough. For a managed petabyte data warehouse or a managed frontier-model platform, it is not, and you should say so in the evaluation rather than pretend otherwise.

Due-diligence checklist for maturity:

• Multi-AZ design. Confirm genuine multiple availability zones in a European region, because that is what backs the RTO and RPO a tender demands. Hyperscalers have the widest multi-AZ footprint today.
• Published SLAs. Compare single-instance versus multi-AZ SLA percentages and the service-credit terms, provider by provider.
• Ecosystem conformance. Require CNCF Certified Kubernetes conformance, an official Terraform provider, CSI and CNI support, and S3 API compatibility. OVHcloud, Scaleway and the hyperscalers all clear this bar.
• GPU and AI capacity in Europe. Scaleway and OVHcloud offer GPU instances, and public programmes like EuroHPC add capacity, but hyperscaler managed AI platforms remain ahead for turnkey tooling.
• Transparency. Check status-page history, incident post-mortems, support response SLAs, and whether third-party audit reports are available under NDA.

One neutral lesson applies to every provider, not just one: the March 2021 OVHcloud Strasbourg SBG2 fire destroyed 14,046 servers and affected around 120,000 services, and some customers discovered their backups were in the same facility. Verify your own backup topology and rehearse a cross-region restore. Assume nothing, on any cloud.

Maturity scorecard. Confirm current numbers on each provider's infrastructure page. As of October 2026.

What is the real lock-in risk, and how do you stay portable across sovereign and hyperscaler clouds?

The lock-in risk is almost never the virtual machines. It is the proprietary managed services, the IAM model and the CI/CD glue, which is why portable public sector architectures standardise on containers, Kubernetes, PostgreSQL, S3-compatible object storage and Terraform. Portability is a testable property, not a contract clause.

Think in three tiers:

• Portable: containers, Kubernetes, PostgreSQL, the S3 API, OpenTelemetry. These move with little rework.
• Translatable: load balancers, DNS, secrets, storage lifecycle rules. These need mapping but have equivalents everywhere.
• Sticky: proprietary serverless, managed data warehouses, vendor AI platforms, and IAM policy models. These are where lock-in actually lives.

Deliberate multi-cloud is a compliance strategy, not an ideology: a SecNumCloud or BSI C5 provider for regulated data, a hyperscaler for non-sensitive or specialist workloads. To make it real, write exit requirements into the tender: export formats and timeframes, egress caps during migration, an assisted-migration obligation, full IaC handover, and the EU Data Act switching rights (Articles 23 to 31). The European Commission's own work on the Data Act identified egress and switching costs as a genuine barrier to switching, which is precisely why those articles exist.

"We will just use Terraform" is not enough. Terraform moves infrastructure; it does not move the developer workflow, the environments, the RBAC model or day-2 cluster operations. The measurable portability test I use: can a new engineer deploy the same application to a second provider's Kubernetes cluster in under a day, using the same manifests and the same pipeline? If not, you are more locked in than your architecture diagram suggests.

Where does Qovery fit in a sovereign cloud strategy?

Qovery is an internal developer platform that deploys and operates applications inside your own cloud account on AWS, GCP, Azure or Scaleway, or on an existing Kubernetes cluster you already run at OVHcloud, Open Telekom Cloud or in a government data centre. That means changing provider becomes an infrastructure decision instead of a rebuild of the delivery pipeline.

The model is bring-your-own-cloud. The cloud contract, the data residency, the provider certifications and any public sector framework discounts stay in your own account and your own name. Qovery sits on top. Bring-your-own-Kubernetes is the sovereign path: Qovery runs on a conformant cluster wherever that cluster lives, including European providers and on-prem government infrastructure.

Verified capabilities, nothing more: git-push deployments, preview and ephemeral environments per pull request, environment auto-stop for non-production, managed cluster upgrades, per-environment RBAC, and databases backed by managed cloud services. You can confirm the supported clouds and these capabilities yourself in the Qovery documentation.

Why this matters for sovereignty: the same application definition can target a SecNumCloud-qualified French account and a hyperscaler account, which turns the exit clause from paperwork into something you can rehearse. To be clear, Qovery is not a certification and does not make any provider compliant. It is the delivery and operations layer on top of whichever compliant infrastructure you select.

Responsibility split for a sovereign deployment with an internal developer platform, as of October 2026.

How should you structure the provider evaluation for a public sector tender?

Score hard legal constraints first as a pass/fail gate, then service fit, then one identical priced reference workload, and require a documented and tested exit plan from every bidder before any price is compared. A provider that cannot demonstrate a restore and a cluster upgrade in a pilot should not reach the price round.

1. Extract pass/fail legal constraints: data classification, applicable national scheme and version, residency, personnel nationality, operations location.
2. Map required services and flag every component available at only one provider, with a named fallback for each.
3. Price one identical reference workload including egress, support plan and three-year growth, and record the price-check date.
4. Run a two-week pilot that proves day-2 operations: deploy a real application, perform a cluster upgrade, restore a backup from scratch, and open a priority support ticket timed against the published SLA.
5. Require exit artefacts as a contractual deliverable: IaC, container images, data export, and a documented, tested migration runbook.

A reusable weighting once compliance has passed the gate: service fit 30%, three-year cost 30%, operational maturity 25%, exit readiness 15%.

Pick the cloud your lawyers can defend, confirm it against the published scope document rather than the brochure, and keep the delivery layer portable so the decision stays reversible inside one contract cycle. That is the whole strategy. If you want the delivery and operations layer to be the part you never have to rebuild, try Qovery free on your own cloud or your own Kubernetes cluster.

What is the difference between data residency, data sovereignty, and operational sovereignty?

Data residency is where the data is physically stored, data sovereignty is which legal system can compel access to it, and operational sovereignty is who can technically touch the systems and hold the keys. A provider can store your data in Frankfurt (residency) while its parent company remains subject to foreign law (sovereignty) and its support staff retain admin access (operational). The Schrems II judgment (CJEU Case C-311/18, 2020) is why applicable law, not storage location, became the central procurement question.

Does AWS European Sovereign Cloud, Microsoft EU Data Boundary or Google Cloud sovereign controls satisfy SecNumCloud or BSI C5 requirements?

Not automatically. AWS European Sovereign Cloud, the Microsoft EU Data Boundary and Google Cloud sovereign controls with S3NS materially reduce operational exposure through EU-based operations, personnel and governance. None of them is identical to an ANSSI SecNumCloud qualification or a BSI C5 attestation. If a tender names SecNumCloud or C5, verify the specific qualified scope on cyber.gouv.fr or BSI rather than accepting a sovereign-brand claim.

Is OVHcloud or Scaleway actually cheaper than AWS, Azure or Google Cloud for a public sector workload?

Usually yes on list prices for plain compute, and often dramatically cheaper on data transfer out, because Scaleway does not meter egress and OVHcloud includes outbound bandwidth on EU Public Cloud instances, while AWS charges around $0.09/GB above a 100 GB free tier. Hyperscalers narrow or reverse the gap through committed-use discounts and managed services that remove headcount. Price one identical reference workload with egress and support included, and date-stamp it, because all prices move.

Which European cloud provider has the most mature managed Kubernetes offering?

OVHcloud Managed Kubernetes and Scaleway Kapsule are both CNCF Certified Kubernetes with official Terraform providers and multi-AZ options, and are mature enough for most public sector container workloads. Hyperscaler services (EKS, AKS, GKE) still lead on breadth of integrations and multi-AZ footprint. Validate the specific version, multi-AZ support and SLA in a pilot rather than from a datasheet.

Can we run the same application on both a European sovereign cloud and a hyperscaler without rewriting it?

Yes, if you standardise on portable building blocks: containers, Kubernetes, PostgreSQL, S3-compatible object storage and Terraform. The sticky parts are proprietary serverless, managed data warehouses, vendor AI platforms and IAM models, so avoid or isolate those. A practical test is whether a new engineer can deploy the same application to a second provider's Kubernetes cluster in under a day with the same manifests and pipeline; an internal developer platform like Qovery exists to make that test pass.

How does the EU Data Act change cloud switching and egress fees, and from when?

The EU Data Act (Regulation (EU) 2023/2854), Chapter VI, Articles 23 to 31 requires providers to remove switching charges, with only reduced cost-based charges permitted in the interim and no switching charges permitted from 12 January 2027. It also mandates functional equivalence and assisted switching. Turn it into a contract clause now: require documented export formats, migration assistance and capped egress during migration.