Europe has been repeating a familiar mantra for years that sounds good in speeches and presentations: digital sovereignty. But by 2026, that word no longer functions as a slogan. It has become a matter of architecture, procurement, and risk management. The most recent trigger is the AWS European Sovereign Cloud, announced on January 15, 2026 as an “independent” cloud for Europe, located within the EU and separated from other AWS Regions, with declared investments of more than 7.8 billion euros in Germany and plans to expand into Belgium, the Netherlands, and Portugal.
The message is clear: US hyperscalers have understood that Europe is no longer just asking “Where are my data?” but “Who has ultimate control over the provider that holds my data?” And that’s where the contradiction that the continent can no longer ignore begins.
The problem isn’t technical: it’s about jurisdiction and ultimate control
AWS, Microsoft, and Google have invested in European regions, residence controls, and compliance promises. Microsoft, for instance, formalizes commitments such as the EU Data Boundary for customer data in enterprise services. AWS, meanwhile, assures that its European sovereign cloud will operate within the EU under reinforced controls.
However, the critical issue isn’t encryption, number of zones, or certifications. It’s about a tricky but essential question for any public administration or company managing sensitive data:
What happens when the laws of the provider’s country of origin conflict with European interests or standards?
This isn’t about suggesting that “someone will access data without control tomorrow.” It’s about recognizing a structural reality: An American provider is subject to U.S. legal obligations, including extraterritorial frameworks. The US CLOUD Act is the most cited example in Europe: it clarifies that if a company under U.S. jurisdiction is legally compelled to provide data, that request can reach data stored outside the U.S. European data protection authorities have precisely analyzed the impact of this on the European framework.
And this isn’t an academic debate: contextualizing the launch of the European AWS Sovereign Cloud within Europe’s growing concern over the CLOUD Act’s reach and dependence on U.S technology providers.
In other words: there may be European residence, European operation, and European audits, but if the “ultimate control” (ownership, headquarters, legal obligations, command chain) is outside the EU, sovereignty can only be partial. More robust, more “Europeanized,” perhaps more defensible in certain scenarios. But not fully.
“100% Sovereignty” requires an honest definition
When it’s said that true European sovereignty must be “100%,” it’s worth specifying what that means. In practice, that “100%” is understood as a combination of four elements:
- Provider owned and controlled by European entities (decision-making center in Europe).
- Primary European jurisdiction (without structural dependence on a legal framework from a third country).
- Operation and infrastructure within the EU (support, equipment, and processes under European standards).
- Contracts and mechanisms for reversibility (actual capacity to migrate and avoid captivity).
If that’s the definition — and for many administrations and regulated sectors it is — then the straightforward conclusion is: European sovereignty can only be fully built on European providers. Not out of technological nationalism but for risk coherence.
Why Europe should avoid structural dependence on U.S. hyperscalers
There are three main reasons that outweigh any marketing campaigns about “sovereign clouds”:
1) Geopolitical risk turned into operational risk
Geopolitics is no longer just scenery. Some outlets have even mentioned that this new cloud is designed to keep operating in extreme scenarios like digital disconnection between the U.S. and the EU or export restrictions on software.
If a provider needs to craft a “continuity plan” to survive a conflict between blocks, it indicates dependence exists. And where dependence exists, it must be managed by reducing it.
2) Legal conflicts and power asymmetry
Even with technical controls in place, asymmetry persists: Europe regulates through compliance; the U.S. can regulate through the provider’s jurisdiction. European legal assessments of the CLOUD Act precisely warn about this complex fit within the European data protection framework.
The practical consequence is that, for critical data (healthcare, justice, defense, energy, registry, education, digital identity), sovereignty should not rely on optimistic interpretations.
3) Risk of technological dependence and exit costs
Sovereignty also means capacity to change. Many European organizations have discovered too late that part of their cloud infrastructure was built on proprietary services that are hard to replace. The problem isn’t using advanced services; it’s not having an exit plan.
The European ecosystem: more than alternatives, an industrial strategy
Europe isn’t starting from scratch. There exists a network of providers, with varying scales and specializations, that share a decisive advantage: their center of gravity is in Europe.
- OVHcloud has positioned data sovereignty at the core of its proposition for years, presenting itself as a European provider focused on freedom of choice and control.
- Hetzner, a German company operating data centers in Europe (among other locations), markets cloud and servers with an explicit compliance and control narrative.
- Stackscale, a European infrastructure provider offering IaaS and bare-metal services, emphasizes its presence in European data centers and its focus on performance and high availability.
And yes, there are many more. The point isn’t to turn this into a brand list but to understand the strategic logic: Hiring European providers not only reduces risks but also strengthens local industrial capacity, talent, investment, energy sovereignty linked to data centers, and an ecosystem that can compete on its own terms.
A simple table to decide without falling into marketing trap
| Key Question | If answer is “yes” | Why it matters |
|---|---|---|
| Is the provider controlled by a company within the EU? | There is legal sovereignty of origin | Reduces extracomunitary legal exposure |
| Are the operation, support, and billing conducted in the EU? | Operational European control | Less dependence on external decisions |
| Is there a realistic and tested exit plan? | Practical sovereignty | Avoids technological captivity |
| Do infrastructure and copies reside in the EU by contract? | Enhanced residence | Aligns compliance and auditing |
Conclusion: Europe cannot outsource its sovereignty
Digital sovereignty isn’t something you “buy” as a premium option within a global catalog. It’s built — with local providers, fixed standards, interoperability, and autonomous decision-making capacity.
US hyperscalers can offer useful layers: residence, controls, audits, commitments. But Europe shouldn’t confuse “compliance” with “sovereignty.” Because in a world of rising tensions, structural dependence always leaves a mark: in the form of legal uncertainty, political pressure, or exit costs.
If European sovereignty is to be taken seriously — 100%, with no asterisks — the coherent strategy is to reinforce and prioritize the European cloud infrastructure ecosystem. Not as an ideological gesture, but as a policy for security, continuity, and economic autonomy.
Frequently Asked Questions
What does “real” cloud sovereignty mean for a European public administration?
That the provider is under European control and jurisdiction, with operation and data within the EU, and with clear mechanisms for auditing and reversibility to avoid captivity.
Why doesn’t a “European” cloud from an American company equal 100% sovereignty?
Because geographic residence doesn’t eliminate the provider’s country of origin jurisdiction nor its ultimate corporate control.
Which European providers are often cited as sovereign alternatives?
OVHcloud, Hetzner, and Stackscale are common examples, along with others covering from IaaS and bare metal to managed services.
How can dependency risks be reduced if already using AWS, Azure, or Google Cloud?
By designing an exit plan: prioritizing portable technologies (containers, Kubernetes, migratable databases), exportable copies, and architecture that avoids relying on proprietary services without alternatives.