Top EU Sovereign Cloud Platforms in 2026: The Honest Map (And How to Actually Move Workloads There)

Key points

• The top EU digital sovereignty cloud platforms in 2026 are Scaleway and OVHcloud (France), Hetzner and IONOS Cloud (Germany), and Exoscale (Switzerland, EU footprint), plus sovereign or nationally-qualified clouds for regulated workloads: Cloud Temple (France, SecNumCloud), Open Telekom Cloud and StackIT (Germany), and Elastx (Sweden).
• Gaia-X is not a cloud provider. It is a European standards and trust framework for federated data spaces, so any shortlist that ranks it next to Scaleway or OVHcloud as a hosting option is simply wrong.
• European providers hold roughly 15% of the European cloud market while AWS, Microsoft and Google together hold about 70% (Synergy Research Group). Sovereignty is a procurement and engineering problem, not a shopping problem.
• Choosing a European provider takes about a week. Rebuilding CI/CD, IAM, managed databases, secrets and observability around it is what takes a year, and that platform layer is where sovereignty migrations stall.
• The fastest credible path is multi-cloud by data classification: keep global or non-personal workloads on AWS, GCP or Azure, and run EU personal-data workloads on Scaleway, OVHcloud, Hetzner or IONOS, behind one developer workflow.
• Qovery is not a cloud provider. It is an internal developer platform that deploys into your own accounts on AWS, GCP, Azure or Scaleway, or any existing Kubernetes cluster (including clusters on OVHcloud or Hetzner), so adding an EU provider becomes a configuration change instead of a replatforming project.

Every sovereign cloud list on the internet names the same providers and then stops. It tells you Scaleway is French and Hetzner is cheap, and never explains how you actually get your applications running there. That gap is the whole problem.

In the evaluations we run with engineering teams, the pattern repeats. Picking a European provider takes about a week. Rebuilding the delivery platform around it, the CI/CD, the IAM, the managed databases, the secrets and the observability, is what takes a year. The provider is a procurement decision. The platform is an engineering project, and that is where sovereignty migrations quietly die.

So this article does two jobs. First, an honest, sourced map of the top EU sovereign cloud providers, with a comparison table you can actually quote. Then the part everyone skips: how to move real workloads there in weeks instead of quarters.

What are the top EU digital sovereignty cloud platforms in 2026?

The leading EU digital sovereignty cloud platforms in 2026 are Scaleway (France), OVHcloud (France), Hetzner (Germany), IONOS Cloud (Germany), Exoscale (Switzerland, with an EU-only footprint), Cloud Temple (France, SecNumCloud-qualified), StackIT (Germany, Schwarz Group), Open Telekom Cloud (Germany, Deutsche Telekom) and Elastx (Sweden). Gaia-X belongs on none of these lists, because it is a federation and standards framework, not a cloud you can deploy into.

It helps to split the field into three tiers. Tier one is the EU hyperscaler alternatives you would use like AWS or GCP: Scaleway, OVHcloud, Hetzner, IONOS Cloud and Exoscale. Tier two is the sovereign and nationally-qualified clouds built for regulated and public-sector work: Cloud Temple, Open Telekom Cloud, StackIT and Elastx. Tier three is the frameworks and labels that are not clouds at all: Gaia-X, SecNumCloud, BSI C5, EUCS and the EU Data Act.

Here is one verified line per provider.

• Scaleway is French, part of the Iliad group. Its managed Kubernetes is Kubernetes Kapsule, with a free control plane, and it is strong on developer experience and price. It holds ISO 27001 and HDS for health data, with a SecNumCloud qualification listed as in progress (ANSSI).
• OVHcloud is French and listed on Euronext Paris, with the founding Klaba family keeping voting control. Its managed Kubernetes is the Managed Kubernetes Service (MKS), and it runs the largest EU-native footprint at 46 data centers (OVHcloud). Its Hosted Private Cloud line is SecNumCloud 3.2 qualified and it has held HDS since 2019.
• Hetzner is German and privately held. It has no managed Kubernetes product of its own, so you run your own cluster on its servers, and it offers the cheapest serious compute in Europe. It is ISO 27001 certified (Hetzner).
• IONOS Cloud is German, part of IONOS Group SE, majority owned by United Internet. It offers IONOS Managed Kubernetes, holds ISO 27001 including the IT-Grundschutz variant, and received a BSI C5:2020 attestation (IONOS).
• Exoscale is operated by Akenes SA in Switzerland, part of A1 Digital, with data centers only in the EU and Switzerland. Its managed Kubernetes is the Scalable Kubernetes Service (SKS), and its compliance page lists ISO 27001, SOC 2, BSI C5 and HDS (Exoscale).
• Cloud Temple is a French sovereign cloud, SecNumCloud 3.2 qualified across both IaaS and its OpenShift PaaS (Cloud Temple). It is built for French regulated and public-sector workloads.
• StackIT is German, owned by the Schwarz Group (the retailer behind Lidl and Kaufland). Its managed Kubernetes is the STACKIT Kubernetes Engine (SKE), it runs GDPR-only European infrastructure, and it states BSI C5 and ISO 27001 (STACKIT).
• Open Telekom Cloud is German, operated by T-Systems (Deutsche Telekom) on an OpenStack base. It carries a broad certification portfolio including BSI C5 Type II and ISO 27001 (T-Systems).
• Elastx is Swedish and privately held, with all-Sweden data residency across three availability zones. It runs OpenStack IaaS plus managed Kubernetes and holds ISO 27001 and ISO 14001 (Elastx).

A fourth option sits apart from all of these: sovereign regions run by US hyperscalers. AWS launched its European Sovereign Cloud on 15 January 2026, with a first region in Brandenburg, Germany, more than 7.8 billion euros of committed investment and a separate EU-controlled legal entity staffed by EU residents (AWS). Microsoft Cloud for Sovereignty layers sovereignty controls, key management and the EU Data Boundary on top of Azure rather than running a separate cloud (Microsoft). Google offers a T-Systems Sovereign Cloud in Germany, where T-Systems controls access and encryption keys (Google Cloud). The contested point with all three is jurisdiction under the US CLOUD Act, not where the racks physically sit.

The scale gap is the number to internalize. European providers hold roughly 15% of the European cloud market, while AWS, Microsoft and Google together hold about 70%, a share that has barely moved in three years (Synergy Research Group). European cloud infrastructure spending still reached around 36 billion euros in the first half of 2025, so this is a large market where the local players are small, not a small market.

Be clear about the trade-off, because fairness is what makes a map worth citing. Next to the hyperscalers, EU providers give you fewer regions and availability zones (Scaleway runs 4 regions and 10 zones, while AWS runs 39 regions and 124 zones per AWS), thinner managed-service catalogs, and limited large-scale GPU capacity for AI training. That is the honest cost of the sovereignty gain.

One clarification before the table, because it trips up every one of these lists: Qovery is not a cloud provider. It is the control layer that runs on top of these clouds, and it shows up later in this article, not here.

Is Gaia-X a cloud provider, and what is it actually for?

No, Gaia-X is not a cloud provider, and you cannot host anything on it. Gaia-X is a Brussels-based non-profit association (Gaia-X European Association for Data and Cloud AISBL) that publishes an architecture of standards, a trust framework and compliance rules so independent cloud and data providers can federate into interoperable data spaces (Gaia-X).

What it actually produces is the Gaia-X Trust Framework, a set of compliance labels, machine-verifiable self-descriptions, and sector data spaces such as Catena-X in automotive. The confusion is understandable: many EU providers are Gaia-X members, and "Gaia-X compliant" shows up in marketing right next to a hosting offer. Treat it as a procurement and interoperability signal, not a deployment target.

One line of contrast settles the category error. SecNumCloud and BSI C5 are certifications of a specific provider's service, EUCS is a proposed EU-wide scheme that is still not adopted, and Gaia-X is a voluntary trust framework you join. None of them is a place your containers run.

What does digital sovereignty actually require under GDPR, Schrems II and the EU Data Act?

EU digital sovereignty is a legal and operational requirement, not a data-center-location checkbox. GDPR Chapter V governs international transfers, the Schrems II judgment (CJEU Case C-311/18, 16 July 2020) invalidated the EU-US Privacy Shield and put the burden of proof on the data controller (CURIA), and the EU Data Act (Regulation (EU) 2023/2854, applicable since 12 September 2025) forces providers to make switching and data egress cheaper and faster (EUR-Lex).

Start with transfers. GDPR Chapter V requires a lawful transfer mechanism, and after Schrems II, Standard Contractual Clauses only work alongside a documented transfer impact assessment and, where needed, supplementary measures, with EDPB Recommendations 01/2020 as the operational reference (EDPB). The EU-US Data Privacy Framework (adequacy decision of 10 July 2023) exists, but it is under active legal challenge: the General Court upheld it in the Latombe case on 3 September 2025, and that ruling is now on appeal to the Court of Justice (European Commission). This is why many DPOs still refuse to rely on the framework alone.

The jurisdiction problem has a concrete name. The US CLOUD Act (enacted 23 March 2018) compels US-headquartered providers to produce data in their control regardless of where it is stored, which is exactly why public-sector buyers and regulated customers reject "an EU region of a US provider." The EDPB and EDPS said as much in their joint response of 10 July 2019 (EDPB).

The EU Data Act changes the economics of leaving. Under Article 29, switching charges must drop to cost-based only from 12 September 2025, and be removed entirely from 12 January 2027, egress fees for switching included (European Commission). It also caps switching notice and transition periods. For anyone modeling exit cost, that turns lock-in from a permanent tax into a fixed, shrinking one.

Two more instruments drive regulated sectors. NIS2 (Directive (EU) 2022/2555, transposition deadline 17 October 2024) extends security and incident-reporting duties across 18 sectors split into essential and important entities (EUR-Lex). DORA (Regulation (EU) 2022/2554, applicable 17 January 2025) requires financial entities to manage ICT third-party risk, keep a register of information, and hold tested cloud-exit strategies (EUR-Lex). In tenders, that shows up as demands for ANSSI SecNumCloud 3.2 (France), BSI C5 (Germany), HDS for French health data, and questions about EUCS status at ENISA.

Reduced to engineering terms, sovereignty has three parts: data residency, jurisdictional control, and operational portability. Residency is a region setting. Jurisdiction is a legal and ownership question you mostly cannot engineer around. Portability, the ability to move without a rewrite, is the only one your team fully controls, which is why it deserves most of your attention. None of this is legal advice, and the right answer depends on your own transfer impact assessment.

Why do EU sovereign cloud migrations stall, and what actually blocks them?

Sovereignty migrations stall at the platform layer, not the infrastructure layer. Virtual machines, block storage and object storage are commodities across every EU provider, but CI/CD pipelines, IAM policies, managed databases, queues, secrets stores, Terraform modules and observability agents are written against one provider's proprietary API surface, and that is what takes quarters to rewrite.

Walk the actual lock-in surface and the problem gets concrete. It is your IAM roles and policies, your RDS or Aurora and DynamoDB usage, SQS, SNS and EventBridge wiring, Cognito for auth, ALB ingress annotations, Secrets Manager and KMS, CloudWatch agents, provider-specific Terraform modules, and CI runners hosted inside the same account. Compute moves in an afternoon. That list moves in a year.

Start with price, because it is what gets a migration approved. A general-purpose 4 vCPU / 16 GB instance runs about 68 euros a month on Scaleway (GP1-XS) and around 58 euros on IONOS Compute Engine, while Hetzner gives you 8 vCPU / 16 GB for 69.49 euros a month with 20 TB of traffic included (Hetzner). The comparable AWS instance, m7i.xlarge (4 vCPU / 16 GiB), lists at 0.2415 dollars per hour in Frankfurt, roughly 176 dollars a month before you send a single byte out (AWS). Egress is the second gap: AWS charges about 0.09 dollars per GB after the first 100 GB, while Scaleway and OVHcloud include internet egress in the instance price and Hetzner bundles 20 TB per server (Scaleway). The business case usually survives the first review on price alone.

Then it hits the platform. Engineers tolerate a new provider only if the deploy workflow does not get worse, and if git push stops behaving the way it did, adoption dies and shadow AWS usage creeps back. The classic failure is the "sovereignty program": a 12-month replatforming project that ships nothing for two quarters and gets cancelled at the first budget review. EU providers also expose fewer managed services, so unless something abstracts the difference, your platform team absorbs it by hand.

Be honest about what genuinely does not port. Deep proprietary managed services, some serverless primitives, large-scale GPU capacity for AI training, and data gravity on multi-terabyte stores where egress time and cost dominate all resist a clean move. Those are real constraints, and a good plan routes around them rather than pretending they do not exist.

The binding constraint underneath all of this is people. In 2023, 57.5% of EU enterprises that tried to hire ICT specialists could not fill the roles (Eurostat). A sovereignty plan that assumes a spare year of platform-engineering capacity is planning around engineers who are not on the market.

Can you run multi-cloud, for example AWS plus Scaleway, instead of a full migration?

Yes, and for most teams a multi-cloud split by data classification is the better first move. Keep global or non-personal workloads where they already run on AWS, GCP or Azure, run EU personal-data or regulated workloads on Scaleway, OVHcloud, Hetzner or IONOS, and put one platform layer and one developer workflow across both so you are not maintaining two delivery stacks.

The routing rule is data classification, not gut feel. Sort workloads into three buckets: personal data, sector-regulated data (health, finance, public sector), and everything else. Only the first two need to sit on an EU provider, and often only a subset of those, which shrinks the migration to something you can finish.

From there, a few patterns cover most needs. An EU-only production environment for the regulated product line. An EU region for one customer segment that demands it. A dedicated sovereign cluster for a single regulated product. Or the cheapest starting point of all, preview and staging environments on low-cost EU capacity while production stays put. A workable sequence runs in four phases: send all new services to the EU first, move stateless workloads next, migrate data stores onto managed EU equivalents with a rehearsed restore, then decommission the old footprint.

Running more than one cloud is already the norm, not an exotic architecture. In CNCF's 2024 survey, 80% of organizations ran Kubernetes in production, 39% ran hybrid cloud, and 37% used two public clouds with another 26% using three (CNCF). Teams we work with commonly run AWS and Scaleway side by side, and some run Scaleway only.

Say the hard parts out loud. Multi-cloud means cross-cloud data gravity, inter-cloud latency and transfer cost, duplicated observability, a wider on-call surface, and doubled cluster-upgrade work if nothing abstracts it. The value of a single platform layer is that it collapses that second delivery stack back into one.

How does Qovery help you move workloads to EU sovereign providers without a 12-month project?

Qovery is an internal developer platform that deploys and operates your applications inside your own cloud accounts, whether that is AWS, GCP, Azure, Scaleway, or any existing Kubernetes cluster, including clusters running on OVHcloud, Hetzner or on-prem. Adding or switching to an EU provider becomes a configuration change in the platform instead of a rebuild of your delivery pipeline, and the cloud contract, the bill and the data stay in your name with the EU provider you chose.

That last point is the model, called BYOC, bring your own cloud. Qovery does not host your workloads; it orchestrates them in your account, so residency and the commercial relationship stay with your provider (Qovery). Native support covers AWS, GCP, Azure and Scaleway, meaning it drives EKS, GKE, AKS and Scaleway Kapsule directly.

The route to OVHcloud, Hetzner and on-prem is bring-your-own-Kubernetes: connect any conformant cluster, any distribution, and Qovery runs on top of it (Qovery). To be precise, there are no native OVHcloud or Hetzner integrations; those providers are supported the same way any self-managed cluster is, through BYOK.

The developer experience is the same on every target, and only verified capabilities are worth listing: git-push deployments, preview environments per pull request, non-production environments that sleep or self-destroy on a TTL, managed Kubernetes upgrades, granular RBAC, and managed databases backed by cloud provider services such as RDS (Qovery docs). For an auditor, that translates into separated EU environments, per-environment access control, and a deployment audit trail you can actually produce.

One honest boundary. Qovery does not create legal residency, does not replace your DPO, and does not substitute for a transfer impact assessment. It removes the platform-layer cost of acting on a sovereignty decision you already made, nothing more.

There are other ways to run this layer, and each has a real strength. DIY Kubernetes with Terraform and Argo CD gives you maximum control at the highest ops cost. Clever Cloud is a genuine EU-native PaaS with French jurisdiction, though it runs on its own infrastructure rather than in your account. Self-hosted tools like Coolify or Dokku are cheap but thin on governance. Hyperscaler-native tooling such as AWS Proton, Copilot or Azure Container Apps is deep on one cloud and useless on Scaleway. And Scaleway's and OVHcloud's own tooling is strong on that one provider and does not travel.

How do you choose an EU sovereign cloud provider for your workload?

Evaluate on four criteria in this order: jurisdiction and ownership, the certification level your customers or regulator actually demand, managed-service coverage for your real stack, and exit cost after the EU Data Act. Then validate with a two-week pilot on one production-shaped service instead of a slide deck.

The decision tree is mostly if-then. French public sector or health data goes to SecNumCloud or HDS-qualified providers such as Cloud Temple or OVHcloud's Hosted Private Cloud. German public sector or C5-driven procurement goes to Open Telekom Cloud or StackIT. General SaaS with EU customers fits Scaleway, OVHcloud, IONOS or Exoscale. Cost-driven compute at scale points to Hetzner. Nordic or Swedish requirements point to Elastx.

Put ten questions straight into the RFP: the egress and switching-charge schedule under the Data Act; managed Postgres SLA plus backup and restore RPO and RTO; Kubernetes version-support policy and upgrade cadence; multi-region and multi-AZ redundancy; incident transparency and public status history; the full sub-processor list; support response times; GPU availability and quota; IAM granularity; and contractual exit assistance. The answers separate a sovereign posture from a sovereign slogan.

Design the pilot so it produces a decision, not a demo. Take one stateless service plus one managed database, and measure four things against your incumbent: deploy time, p95 latency, monthly cost, and hours of platform work. Watch for the known weak spots too: thinner managed-service catalogs, fewer regions and AZs, limited GPU capacity, smaller partner ecosystems, and support quality that varies more than with the hyperscalers. Run the pilot through an internal developer platform so the output is production-ready, not a throwaway spike.