In the global cloud infrastructure market, three companies hold approximately 65–70 % market share: Amazon Web Services, Microsoft Azure, and Google Cloud Platform. All three are US companies, subject to US law — including the CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), which allows US authorities to compel US-based providers, via warrant or subpoena, to produce data — regardless of where that data is physically stored. Providers can challenge such orders in court, but the jurisdictional exposure remains.

A common mitigation is to choose a US provider’s European data centre region. This reduces some risks — latency, certain data residency requirements — but does not resolve the jurisdictional question. The data remains under the control of a US-incorporated company subject to US law. The EU-US Data Privacy Framework (2023) provides additional legal safeguards for transatlantic data transfers — but it is the third such attempt, after Safe Harbor (struck down 2015) and Privacy Shield (struck down 2020), both invalidated by the European Court of Justice in the Schrems I and Schrems II rulings. Max Schrems has signalled he may challenge this framework too. Its long-term stability is an open question.

In Europe, the picture is even starker. US hyperscalers control around 70 % of the European cloud market. European providers — OVHcloud, Hetzner, IONOS, Scaleway, and dozens of smaller operators — account for roughly 15 %. The rest goes to smaller international players.

These are not just market share numbers. They describe a dependency: the majority of European businesses, public administrations, and increasingly critical infrastructure run on computing resources under US jurisdiction. The question is not whether concentration risk at this level is a problem — any risk manager would flag a 70 % dependency on providers under a single foreign jurisdiction. The European Parliament has said as much. The question is why it persists, and what — realistically — can be done about it.

The Price Myth

Ask any CTO why they use AWS, and the answer is usually some combination of “ecosystem,” “managed services,” and “it just works.” Rarely do they say “because it’s cheap.” And for good reason.

A comparison of like-for-like compute resources tells a story that undermines the conventional wisdom. A dedicated server with 64 GB RAM and an 8-core AMD Ryzen processor at Hetzner costs around €40–50 per month. A comparable EC2 instance on AWS — say, an m6a.2xlarge — runs at roughly $280 per month, or more than five times as much. The gap narrows somewhat when you factor in reserved instances and savings plans, but even then, the US hyperscaler price premium is typically 3–5x for compute and 5–10x for storage.

This is not a secret. Every European startup that has grown beyond its initial funding round has done the maths. What keeps organisations on hyperscalers is not price — it’s the ecosystem. Managed databases, serverless functions, machine learning APIs, identity services, monitoring, CDN, dozens of pre-integrated services that would each require separate setup, maintenance, and expertise on a European provider. The managed service layer is the moat, not the virtual machine.

For organisations running standard workloads — web applications, databases, file storage, CI/CD pipelines — European providers offer genuinely competitive alternatives at a fraction of the cost. For organisations deeply embedded in proprietary hyperscaler services (Lambda, DynamoDB, BigQuery), switching is expensive and complex. This distinction matters, because it determines whether a migration is a weekend project or a multi-year programme.

The EUCS Saga

If you want to understand why European cloud sovereignty is progressing at the speed it is, look no further than the EU Cloud Certification Scheme — EUCS.

Proposed by ENISA (the EU’s cybersecurity agency) in 2020, EUCS was supposed to define security levels for cloud services used by EU governments and critical infrastructure. Three levels were planned: Basic, Substantial, and High. The “High” level was, in early drafts, expected to include sovereignty requirements — meaning the cloud provider would need to be free from non-EU jurisdiction, with data processed exclusively in Europe by entities under European control.

France was the driving force behind this. Paris already had its own national scheme, SecNumCloud, operated by ANSSI (the French cybersecurity agency). SecNumCloud requires that the cloud provider be majority-owned by EU entities and that no non-EU law can compel data disclosure. It is, in effect, a sovereignty requirement. France wanted EUCS High to be compatible with SecNumCloud — or at least not weaker.

The US hyperscalers, unsurprisingly, lobbied hard against sovereignty requirements. Their argument: excluding US providers from the highest certification level would be protectionist, would reduce choice, and would not improve security. Several EU member states — particularly the Netherlands and the Nordic countries — were sympathetic to this position, arguing that sovereignty requirements would lock out the most capable providers.

The result, after more than four years of negotiation: the sovereignty requirements were removed from the EUCS draft. The “High” level now focuses on technical security measures — encryption, access controls, audit logging — but does not require European ownership or jurisdiction. France expressed disappointment but did not block the scheme, choosing instead to maintain SecNumCloud as a national complement.

The EUCS saga illustrates the difficulty of defining sovereignty requirements that all stakeholders accept. The scheme that will eventually emerge is better than nothing — but it is not what the word “sovereignty” implies.

Gaia-X: The Conference That Became a Project

No discussion of European cloud sovereignty is complete without mentioning Gaia-X. And no discussion of Gaia-X is complete without a certain amount of weariness.

Launched in 2019 by Germany and France with great energy, Gaia-X was supposed to be the European answer to hyperscaler dominance: a federated data infrastructure based on common standards, enabling European providers to offer interoperable services under European rules. The vision was compelling. The execution has been — to put it charitably — slow.

By 2024, the Gaia-X Association had over 350 members. Among them: AWS, Microsoft, and Google. The organisation that was supposed to reduce dependency on US hyperscalers had invited the US hyperscalers to help define the rules. This is either pragmatism or absurdity, depending on your perspective.

What Gaia-X has produced are standards documents, compliance frameworks, and a Trust Framework for labelling services. What it has not produced is anything a system administrator could deploy on a Monday morning. The Gaia-X Digital Clearing Houses — intended to verify compliance — have been slow to materialise. Lighthouse projects exist but remain niche.

The charitable reading: Gaia-X is a standards body, not a cloud provider. Standards take time. The less charitable reading: Gaia-X has become a symbol of European announcement culture — much discussed, well documented, never installed.

Sovereign Cloud Stack: The Quiet Success

If Gaia-X is the conference, Sovereign Cloud Stack (SCS) is the code.

Funded by the German Federal Ministry for Economic Affairs and Climate Action (BMWK) through the Gaia-X funding programme, SCS took a different approach: instead of defining standards in the abstract, it built a reference implementation. The stack is based on OpenStack for infrastructure, Kubernetes for container orchestration, and Keycloak for identity management — all open source, all proven at scale.

The practical value of SCS is interoperability: workloads running on one SCS-certified cloud can be moved to another SCS-certified cloud without modification. This directly addresses vendor lock-in — not by regulation, but by architecture.

Several German providers have adopted SCS: plusserver, REGIO.cloud, Wavecon, and others. The adoption is modest compared to hyperscaler scale, but it proves the concept works.

The challenge came at the end of 2024, when BMWK funding expired. SCS transitioned to community governance under the Open Source Business Alliance (OSBA). Whether a community-funded project can maintain the momentum of a government-funded one is an open question. The code is solid. The question is whether the ecosystem around it will grow fast enough.

When Physical Reality Strikes: The OVH Fire

On 10 March 2021, a fire destroyed the SBG2 data centre in Strasbourg, operated by OVHcloud — the largest European cloud provider. 3.6 million websites went offline. Customer data was lost. The fire also damaged the adjacent SBG1 facility.

The incident revealed an uncomfortable truth: some customers had assumed that “cloud” meant automatic geographic redundancy. It did not. OVHcloud’s lower-tier offerings did not include off-site backups as standard. Customers who had not explicitly configured multi-site replication lost data permanently.

The fire did not demonstrate that European providers are unreliable. Data centre fires can happen anywhere — a fire at a Cyxtera (US) facility in London in 2022 caused similar disruption. What the OVH fire demonstrated is that “cheaper” often means “fewer defaults.” Hyperscalers include geographic redundancy in their standard architecture. European providers, competing on price, often make it optional. For organisations migrating from AWS to Hetzner or OVH, understanding what is not included by default is as important as the price comparison.

The National Strategies

While the EU debates certification schemes, individual member states have been building their own cloud sovereignty strategies — with varying degrees of ambition and success.

France: SecNumCloud and Bleu

France has the most developed national framework. SecNumCloud, operated by ANSSI, sets strict sovereignty requirements. Certified providers must be majority-owned by EU entities. No non-EU jurisdiction may apply to the data.

The most visible outcome is Bleu — a joint venture between Orange and Capgemini, launched in 2024, that operates Microsoft 365 and Azure services under SecNumCloud certification. (The bleu.cloud domain is no longer active; see the Arvato Delos Cloud page for a comparable model.) The concept: Microsoft’s software, but running on French-controlled infrastructure, operated by French entities, under French law. Microsoft provides the technology under licence; Bleu operates it.

This is a pragmatic compromise. It gives French government agencies access to familiar Microsoft tools while maintaining legal sovereignty over the data. Critics argue it doesn’t address the deeper dependency — France remains reliant on Microsoft’s software, updates, and roadmap. Defenders counter that perfect shouldn’t be the enemy of good: if the alternative is government data on US-controlled Azure, Bleu is a meaningful improvement.

Germany: Delos Cloud and SCS

Germany has pursued two parallel tracks. The Sovereign Cloud Stack, described above, represents the open-source path. Delos Cloud — a joint venture between SAP and Arvato Systems (Bertelsmann) — mirrors the French Bleu model: Microsoft 365 services operated under German sovereignty by German entities.

Additionally, Microsoft itself announced Microsoft 365 Local in June 2025 — an on-premises option designed to address sovereignty concerns. Whether this represents genuine concession or a strategy to keep European governments on Microsoft’s platform by removing the jurisdictional objection is a matter of perspective. For Microsoft, the worst outcome is not reduced margins on a sovereign deployment — it’s a government switching to openDesk or LaSuite entirely.

Denmark: Systematic Vendor Diversification

In the summer of 2025, Denmark announced a systematic programme to reduce Microsoft 365 dependency across government. Digital Affairs Minister Caroline Stage Olsen framed it in concentration-risk terms: “We must never make ourselves so dependent on so few.”

The Danish approach is comprehensive. The Ministry of Digital Affairs began rolling out LibreOffice across government workstations in summer-autumn 2025. Copenhagen and Aarhus announced similar initiatives at the municipal level. The migration is ongoing, and the full picture will take years to emerge — but Denmark has become the most prominent case of a Western European government explicitly choosing to reduce Microsoft dependency at a national level.

The Managed Services Gap

Here is what sovereignty advocates sometimes skip: European cloud providers are weaker on managed services.

AWS offers over 200 managed services. Azure offers a comparable range. These include managed databases (RDS, Cosmos DB), serverless compute (Lambda, Azure Functions), AI services (SageMaker, Azure OpenAI), analytics (Redshift, Synapse), IoT platforms, and dozens more. Each managed service means less operational burden for the customer — and more lock-in.

European providers like Hetzner and OVH excel at infrastructure: virtual machines, bare-metal servers, storage, networking. Their managed service offerings are growing but remain modest by comparison. Scaleway has invested more in this direction, offering managed Kubernetes, databases, and AI GPU instances. But the gap is real.

For organisations evaluating a migration, this means: if you’re using EC2, S3, and RDS in a standard configuration, a European provider can likely serve you at 3–5x lower cost. If you’re deeply embedded in Lambda, Step Functions, and DynamoDB — a move is possible but requires significant re-architecture. The total cost of ownership calculation must include not just the monthly bill, but the migration effort.

The Data Act: Regulation as Enabler

One piece of EU regulation deserves mention for its direct relevance to cloud migration: the Data Act (EU 2023/2854), applicable from 12 September 2025.

The Data Act introduces obligations for cloud providers to facilitate switching: they must provide data export tools, support data portability, and are prohibited from charging excessive switching fees. From January 2027, switching charges must be eliminated entirely.

This is significant not because it makes migration easy — technical complexity remains — but because it removes one of the barriers that cloud providers have deliberately erected. Until now, extracting large datasets from a hyperscaler often involved substantial egress fees. The Data Act changes the economic calculus.

What a Realistic Migration Looks Like

The organisations that have successfully moved workloads off hyperscalers share common characteristics:

1. They started with new workloads. Rather than migrating existing applications (complex, risky, expensive), they deployed new projects on European providers from the start. Over time, the balance shifted.

2. They avoided proprietary services. Organisations that built on Kubernetes, PostgreSQL, and S3-compatible object storage (all available on European providers) found migration straightforward. Those built on Lambda and DynamoDB found it wasn’t.

3. They accepted hybrid. Most successful migrations don’t result in 100 % European hosting. Some services — particularly AI APIs and global CDN — may remain on hyperscalers, while core data and compute move to European infrastructure. A conscious hybrid strategy — with clear criteria for what stays and what moves — is more sustainable than an all-or-nothing approach.

4. They invested in operations. European providers offer less hand-holding. Organisations need in-house or contracted expertise for deployment, monitoring, and incident response. The total cost of ownership includes people, not just servers.

5. They used open standards. Kubernetes, S3-compatible APIs, PostgreSQL, OpenStack — the more standard the stack, the easier the migration. Proprietary lock-in is not a cloud problem; it’s a design choice.

What Remains

European cloud sovereignty is not a technology problem. European providers offer competitive infrastructure. SCS has demonstrated that interoperable, sovereign cloud stacks can work. The price advantage of European providers is real and substantial.

Two regulatory deadlines create a concrete window for action. The Data Act became applicable in September 2025, requiring cloud providers to support data portability. From January 2027, switching charges must be eliminated entirely. For the first time, the economic barriers that hyperscalers erected around their platforms are being dismantled by regulation.

If you are running workloads on a US hyperscaler and considering alternatives, the patterns above point to a clear sequence:

Start now:

  • Deploy all new workloads on European providers. New projects have no migration cost. A Kubernetes cluster on Hetzner or Scaleway costs a fraction of the equivalent on AWS — and you avoid building new lock-in.
  • Audit your existing stack for proprietary dependencies. How deeply are you embedded in Lambda, DynamoDB, or Azure-specific services? The answer determines your migration complexity and timeline. This audit takes days, not months.

Before January 2027 (Data Act switching-fee elimination):

  • Plan your migration for switching-fee-intensive workloads. Once the Data Act eliminates switching charges entirely, the cost of moving large datasets off hyperscalers drops significantly. Use the time until then to prepare: identify what moves, test the target environment, train the team.
  • Negotiate your next cloud contract with an exit clause. If your Enterprise Agreement renews before 2027, ensure it includes data portability provisions aligned with Data Act requirements.

Accept and manage:

  • Hybrid is not failure. AI APIs, global CDN, and niche managed services may remain on hyperscalers while core data and compute move to European infrastructure. The goal is conscious choice, not dogmatic purity. For a structured framework on what to control and what to rent, see The Limits of Digital Independence.

The cost of inaction: If you’re running standard infrastructure workloads (compute, storage, databases) on AWS or Azure, European providers offer the same at 3–5x lower cost. For a typical 50-server deployment, that’s tens of thousands of euros per year in unnecessary spending — money that could fund the operations expertise needed for sovereign infrastructure. Every year of delay compounds the cost and deepens the lock-in.

Sources

Topic overview: Cloud Infrastructure