Why European Companies Are Moving Workloads Out of US Hyperscalers (And Where Those Workloads Actually Go)

Key Points:

• European companies move workloads out of US hyperscalers for four reasons, ranked by how often they force the decision: (1) extraterritorial legal exposure under the US CLOUD Act and FISA 702, which follows the provider's nationality rather than the data centre's location; (2) EU rules that make provider choice auditable, namely the Data Act (Regulation (EU) 2023/2854, applicable 12 September 2025), DORA (Regulation (EU) 2022/2554, applicable 17 January 2025), and NIS2 (Directive (EU) 2022/2555); (3) concentration and exit risk now raised at board level; (4) cost predictability, mainly egress and licensing. Raw compute price is almost never the trigger.
• This is selective migration, not an exodus. Moving first: personal, health, and citizen data stores, identity and collaboration systems, public-sector applications, backups and archives, plus CI runners and non-production environments. Staying: warehouse-scale analytics, managed ML platforms, and global edge delivery, where proprietary coupling makes the move cost more than the risk it removes.
• Leaving got structurally cheaper. AWS, Google Cloud, and Microsoft now waive data transfer out fees for customers migrating off their platform, and the EU Data Act makes switching a regulated right, with switching charges fully withdrawn from 12 January 2027. Egress is no longer the blocker. Migration engineering and managed-service replacement are.
• Destinations split four ways: (1) EU-headquartered providers such as OVHcloud, Scaleway, IONOS, Hetzner, StackIT, and Aruba; (2) hyperscaler sovereign offerings, including AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, and Google Sovereign Cloud with S3NS; (3) self-managed Kubernetes on EU infrastructure or on-prem; (4) a hybrid where regulated data sits in an EU-controlled plane while stateless compute stays wherever it is cheapest. The hybrid wins most of the time.
• The blocker is almost never infrastructure. It is the managed services and the developer workflow you lose when you leave a hyperscaler. Qovery runs the same deployment platform on AWS, GCP, Azure, Scaleway, or your own existing Kubernetes cluster, inside your own cloud account (BYOC), so the provider decision stays a business decision instead of a two-year platform rebuild. Qovery does not make a provider sovereign or certified. That is the provider's job.

---

Most European teams I talk to are not trying to leave AWS, Azure, or Google Cloud. They want the option to leave, and they want to be able to prove to a regulator that the option is real. That is a different project, and it is a lot cheaper than an exodus.

The pattern I keep seeing in CTO conversations is the same. A board asks a question that used to be rhetorical: what happens if this one provider changes its terms, or becomes politically unavailable, and we have no plan B? Then someone starts mapping the estate, and discovers the hard part was never the servers. It was the managed services and the developer workflow welded to one vendor. Let me walk through why this is happening, what actually moves, where it goes, what it costs, and how to do it without rebuilding your platform from scratch.

Why are European companies moving workloads out of US hyperscalers?

Four drivers explain nearly every case I have seen, ranked by how often they force the decision: (1) extraterritorial US law, where the CLOUD Act and FISA Section 702 reach providers under US jurisdiction wherever the data sits; (2) EU regulation that turns provider choice into an auditable decision, through the Data Act, DORA, NIS2, SecNumCloud, and BSI C5; (3) concentration and exit risk now asked about at board level; (4) cost predictability on egress, licensing, and committed spend. Compute price, latency, and feature gaps are almost never the trigger.

Driver one is legal exposure. The US CLOUD Act (18 U.S.C. 2713, enacted March 2018) reaches providers subject to US jurisdiction regardless of storage location. Two events turned this from a theoretical worry into documented findings: the CJEU Schrems II judgment (Case C-311/18, 16 July 2020), which invalidated Privacy Shield, and the EDPS decision of March 2024 finding the European Commission's own use of Microsoft 365 in breach of EU data protection law.

Driver two is regulation as a procurement criterion. DORA (Regulation (EU) 2022/2554, applicable 17 January 2025) requires financial entities to hold documented, tested exit strategies and to manage ICT concentration risk. NIS2 (Directive (EU) 2022/2555) adds supply-chain and provider-risk duties under Article 21. In France and Germany, SecNumCloud 3.2 and BSI C5 are hard gates in public procurement.

Driver three is concentration and exit risk. Boards now want a written, rehearsed answer to "what if one provider changes terms, raises prices, or becomes geopolitically unavailable," not a statement of intent. A Gartner survey published 12 November 2025 of 241 CIOs and IT leaders in Western Europe found 61% expect geopolitics to increase their reliance on local or regional cloud providers, and 53% expect it to restrict their use of global hyperscalers.

Driver four is cost predictability. Egress charges, licensing changes, and committed-spend agreements make multi-year forecasting hard, and EU providers often price network transfer an order of magnitude differently. Flexera's 2026 State of the Cloud Report puts estimated wasted cloud spend at 29% and reports that 85% of organisations now call managing cloud spend their top cloud challenge.

The driver nobody writes down, and the one I hear most often off the record: no executive wants to be the person explaining to a regulator why there was no plan B.

Be honest about what is not driving this. Compute price rarely moves anyone. Latency almost never does. Feature parity never does, because the hyperscaler catalogue is still the deepest on the market, and pretending otherwise just destroys your own argument. For context on scale: Synergy Research put the combined European market share of AWS, Azure, and Google Cloud at 70% in H1 2025, with European-headquartered providers holding around 15%, down from 29% in 2017. Eurostat reports 52.7% of EU enterprises bought cloud services in 2025, up from 45.3% in 2023. The exposure is large and growing.

Which workloads are actually leaving US hyperscalers, and which ones stay?

The migration is selective and highly predictable. Leaving first: personal, health, and citizen data stores, email and document systems, identity, public-sector applications, backups and archives, plus CI runners and non-production environments. Staying: warehouse-scale analytics (BigQuery, Redshift, Snowflake), managed ML platforms (SageMaker, Vertex AI), and global CDN and edge delivery, because for those the migration cost exceeds the risk it removes.

Leaving first and loudest is anything with a legal label on it: customer and citizen personal data, document and email systems, HR and health records, public-sector applications, and backup or archive copies. These are the workloads a regulator asks about by name.

Leaving quietly and early is a second group that rarely makes the press: CI runners, build caches, non-production, and preview environments. They are cheap to move, carry near-zero risk, deliver an immediate cost win, and they are the single best way to measure your real migration effort before you touch production.

Staying put, for now, is warehouse-scale analytics, managed ML pipelines, and global edge delivery. The proprietary coupling there is the product you are buying. Rebuilding BigQuery or SageMaker semantics on an EU provider usually costs more than the risk it removes, so most teams keep those where they are and wrap a documented exit plan around them instead.

The pattern winning in 2026 is a hybrid: regulated data in an EU-controlled plane, stateless compute wherever it is cheapest, and one deployment workflow across both. It is worth separating two words the press keeps merging. Repatriation is a cost decision, usually about leaving the cloud for owned hardware. Sovereignty is a legal decision about who can compel access to your data. Different arithmetic, different triggers.

The rule of thumb I give CTOs: if a workload has no regulated data and no proprietary coupling, move it only if the numbers justify it. If it has regulated data, the numbers are secondary, because the legal exposure sets the floor.

Does the US CLOUD Act apply to data stored in EU data centres?

Yes. The US CLOUD Act requires providers subject to US jurisdiction to disclose data in their possession, custody, or control regardless of where it is stored, so hosting in Frankfurt or Paris on a US-controlled provider does not by itself remove the exposure. No EU law bans US hyperscalers. What the Data Act, DORA, and NIS2 now require is that you document the choice, justify it, and be able to reverse it.

Start with the statute. 18 U.S.C. 2713 obliges a covered provider to disclose communications and records "within such provider's possession, custody, or control, regardless of whether such communication, record, or other information is located within or outside of the United States." For an official EU reading rather than a vendor blog, the EDPB-EDPS joint response of 10 July 2019 to the European Parliament's LIBE Committee is the primary source.

Why Schrems II and the EDPS Microsoft 365 decision matter is that EU authorities have treated US provider control as a real transfer risk with remedial orders attached, not a theoretical one. In the EDPS case, the decision was adopted 8 March 2024 and ordered the Commission to suspend data flows to non-adequate third countries, with compliance due by 9 December 2024.

Mitigations exist, and I will assess them honestly. Customer-held encryption keys and external key management reduce what a provider can hand over in readable form. EU-operated subsidiaries with local staff and contractual commitments raise the legal bar. Data minimisation shrinks the surface. None of these is a settled answer, and competent lawyers still disagree on how far each one goes against a valid US order.

On the regulatory side, three instruments turn this into a procurement process rather than an opinion:

• The EU Data Act (Regulation (EU) 2023/2854) has applied since 12 September 2025. Its Chapter VI (Articles 23 to 31) creates switching rights, mandatory contractual exit terms, a functional-equivalence obligation, and maximum transition periods. Article 29 phases out switching charges, with a hard zero from 12 January 2027.
• DORA (Regulation (EU) 2022/2554, applicable 17 January 2025) requires tested exit plans and concentration-risk assessment, plus a register of information on ICT third parties under Articles 28 to 30.
• NIS2 (Directive (EU) 2022/2555) carried a transposition deadline of 17 October 2024. Transposition ran late: the Commission opened infringement procedures against 23 Member States on 28 November 2024 and issued reasoned opinions to 19 of them in May 2025.

One thing I will not pretend is settled: EUCS, the EU Cybersecurity Certification Scheme for Cloud Services, is still not adopted, and the contested "high+" sovereignty requirements were removed from the draft in 2024 and remain unresolved. Anyone who tells you the EU has a finished sovereignty certificate is selling something.

The practical takeaway is dull and correct: write the exit plan, rehearse it, and keep the evidence. Auditors increasingly ask to see a tested switch, not an intention to switch.

Where are European companies moving these workloads, EU providers, sovereign clouds, or self-managed Kubernetes?

Four destination families, each trading jurisdiction against convenience. EU-headquartered providers (OVHcloud, Scaleway, IONOS, Hetzner, StackIT, Aruba) give the cleanest jurisdictional separation and SecNumCloud or C5 options, with a smaller managed-service catalogue. Hyperscaler sovereign clouds keep the catalogue and add EU operating controls but leave the CLOUD Act question legally open. Self-managed Kubernetes on EU infrastructure gives maximum control at maximum operational cost. The hybrid keeps most of the estate in place while making exit cheap.

EU-headquartered providers have the strongest jurisdictional story. SecNumCloud 3.2 and BSI C5 attestations are available, S3-compatible object storage and managed Kubernetes are standard, but there are far fewer managed services, so you self-host more. SecNumCloud 3.2 from ANSSI is strict on purpose: it requires immunity from extraterritorial law, caps non-EU ownership (minority holdings, no veto rights), and mandates EU-based operation. BSI C5 in Germany is an ISAE 3000 attestation against 121 criteria across 17 areas in its 2020 edition.

Hyperscaler sovereign offerings are serious engineering, and I will say so plainly. AWS European Sovereign Cloud launched 15 January 2026 with its first region in Brandenburg, Germany, operated exclusively by EU residents, backed by an investment of more than 7.8 billion euros. Microsoft completed its EU Data Boundary in February 2025 and in April 2025 added European Digital Commitments, including a legally binding pledge to contest any government order to suspend its European cloud operations. Google Sovereign Cloud spans software-controlled, partner-operated, and air-gapped configurations, and its French partner-operated venture with Thales, S3NS, received SecNumCloud 3.2 qualification for its PREMI3NS offering in December 2025. Real controls, genuinely open legal question.

Self-managed Kubernetes on EU infrastructure or on-prem is the choice teams make when they already run Kubernetes well. The cost shows up as headcount, not as an invoice line, which is exactly why it is so easy to underestimate.

The underrated fourth option is to stay on a hyperscaler for non-regulated workloads and make the platform portable, so that exit is a weekend rather than a programme. Kubernetes is the common denominator that lets all four destinations be described in one architecture. Per the CNCF 2025 survey, 82% of container users now run Kubernetes in production, which is why it is a safe bet as the portability layer.

The pitfall I see repeatedly is swapping US lock-in for EU lock-in by rebuilding on another provider's proprietary services. And to be fair about the adjacent layer: Red Hat OpenShift, SUSE Rancher, and Platform.sh each solve parts of this differently, mostly at the cluster and platform-distribution level rather than the cross-provider deployment level.

What does it actually cost to move workloads off a US hyperscaler to an EU provider?

Egress has largely stopped being the blocker. AWS, Google Cloud, and Microsoft all now waive data transfer out fees for customers leaving, and the Data Act withdraws switching charges entirely from 12 January 2027. The three numbers that decide these projects are one-time migration engineering, replacing the managed services you lose, and ongoing platform operations headcount. Budget roughly 0.5 to 2 FTE to run your own Kubernetes properly.

On the free-exit policies, read the conditions. AWS announced free data transfer out to the internet when you move off AWS on 5 March 2024; you contact AWS Support, it is granted as credits, and since September 2025 there is a 90-day window to complete the move. Google removed switching egress fees in January 2024 as a bill credit for customers discontinuing use. Azure offers the same for customers leaving, with the first 100 GB per month free and credits applied once you cancel your subscriptions.

The standing egress gap is still real for everyday traffic. First-tier data transfer out to the internet runs about 0.09 USD per GB on AWS, about 0.087 USD per GB on Azure, and about 0.12 USD per GB on Google Cloud Premium Tier, each after a small free allowance. Among EU providers, Scaleway includes egress on its Instances, OVHcloud includes outbound traffic in every region except Asia-Pacific, and Hetzner bundles at least 20 TB per month in EU locations and charges roughly 1 euro per TB beyond that. That is the order-of-magnitude difference that makes egress-heavy workloads an easy early move.

One-time migration engineering is the dominant line item, and the only one worth measuring with a real pilot on non-production rather than a spreadsheet. Managed-service replacement should be priced as operational weight, not licence cost: RDS becomes self-managed or EU-provider Postgres, Cognito becomes Keycloak, SQS becomes NATS or RabbitMQ, CloudWatch becomes an open-source observability stack. Each swap is cheap to license and expensive to operate.

Ongoing operations is where most EU-provider business cases quietly break. That 0.5 to 2 FTE of platform engineering has to come from somewhere, and if you do not name it, it eats the savings. The savings that are real: EU provider bandwidth pricing, no committed-spend lock-in, auto-stopping non-production environments, and dropping overlapping tooling. Model two or three destinations in parallel. It gives finance a range instead of a single number, and it gives you a real bargaining position when you renegotiate with the incumbent.

How do you move workloads out of a US hyperscaler without rebuilding your platform?

Keep the deployment layer portable and the destination becomes a configuration choice instead of a migration programme. Six steps, in order: classify workloads by regulatory exposure, containerise and strip proprietary coupling at the application edges, standardise on Kubernetes as the portability layer, move CI and non-production first to measure real effort, run both planes behind one developer workflow, then rehearse the exit and keep the evidence.

Step one is to classify data and workloads by regulatory exposure before touching any infrastructure. Most of the estate does not need to move at all, and knowing which part does is what keeps the project small.

Step two is to containerise and remove proprietary coupling at the edges: object storage, identity, queues, and secrets, using open or S3-compatible interfaces. The coupling at those four edges is what usually turns a move into a rebuild.

Step three is to standardise on Kubernetes, including for the destination you have not picked yet. That is the whole point of a portability layer: it decouples the decision from the deadline.

Step four is to move non-production, preview environments, and CI first. You measure the real effort at near-zero risk, and you get a cost win immediately.

Step five is to run both planes in parallel behind one developer workflow, then cut over the regulated workloads once the path is proven. Step six is to test the exit and keep the evidence, because a rehearsed switch is exactly what DORA and NIS2 auditors want to see.

This is where Qovery fits, and I will be precise about what it does. Qovery runs on AWS, GCP, Azure, Scaleway, or your own existing Kubernetes cluster, deploying inside your own cloud account (BYOC) so the data, the invoice, and any discounts or Savings Plans stay in your name. You get the same git-push deployments, per-pull-request preview environments, per-environment RBAC, managed cluster upgrades, environment auto-stop for non-production, and databases backed by managed cloud services on every one of them. The destination becomes a setting, not a rewrite.

The fair caveat, stated plainly: Qovery does not make a provider sovereign or certified. SecNumCloud and BSI C5 are the provider's job, and the legal analysis is your lawyers' job. What Qovery removes is the platform-rebuild cost that stops most European teams from exercising the choice at all. That is the blocker, and it is the one piece of this that is squarely an engineering problem.

Should your company move out of a US hyperscaler? A decision checklist

For most European companies the honest answer is partial: move what is legally exposed, keep what is deeply coupled, and make everything else portable. A full exit is justified mainly where procurement demands SecNumCloud or BSI C5 level qualification, or where you process health, citizen, or defence data.

Move now if you are in scope for SecNumCloud or BSI C5 procurement, you process health or citizen data, or a regulator has already asked you for an exit plan. Move partially if you have regulated data plus a large non-regulated estate, because the hybrid plane is cheaper and fully defensible. Stay for now if your value sits in hyperscaler-specific data and ML services and your regulatory exposure is low, but build and test the exit capability anyway.

The decision that is correct regardless of destination is to eliminate proprietary coupling in your deployment layer. Everything else follows from that, and nothing else is reversible without it. Sovereignty without portability is theatre, because a choice you cannot actually exercise is not a choice.