European data sovereignty has moved from policy aspiration to procurement constraint, and the cloud market is responding along two divergent paths. On one side, the global hyperscalers are constructing dedicated European entities and regions designed to satisfy sovereignty requirements while keeping customers on familiar platforms. On the other, an ecosystem of open-source infrastructure and European providers offers a structurally different model of sovereignty — one rooted in independence from any single vendor rather than in a vendor’s promise to operate locally. The choice between these paths is now one of the central infrastructure decisions facing European organizations in regulated sectors.

What’s Driving the Race

The pressure is regulatory and accumulating. The European Union’s data protection regime, anchored by GDPR, has long created friction with cloud services operated by U.S.-headquartered companies, because of the possibility that a U.S. parent could be compelled to disclose data under U.S. legal processes regardless of where the data physically sits. National frameworks have sharpened the requirement further: France’s SecNumCloud qualification, Germany’s BSI C5 criteria catalogue, and the developing EU Cloud Cybersecurity Scheme all push toward operational independence from non-EU control for the most sensitive workloads.

The EU Data Act adds another dimension. Its provisions on cloud switching and interoperability — which we examined in our coverage of the Data Act’s entry into force — are designed to reduce the technical and commercial barriers that keep customers locked to a single provider. Sovereignty and switchability are related concerns: an organization that cannot leave its provider has limited sovereignty regardless of where its data sits, and the Data Act’s portability requirements are part of the same broad European push toward customer control over infrastructure.

The net effect is that for an expanding set of European buyers — government, financial services, healthcare, critical infrastructure — “use a U.S. hyperscaler’s local region” is no longer automatically sufficient. The requirement has shifted toward genuine operational and technological independence, and that is what both paths claim to provide.

Path One: The Hyperscaler Sovereign Entity

The hyperscalers’ answer is to build dedicated sovereign offerings: infrastructure operated by EU-based legal entities, staffed by EU personnel, with technical and contractual controls intended to ensure that data and operations remain under European control and beyond the reach of non-EU legal demands.

The most prominent example is the European Sovereign Cloud that AWS announced in October 2023 — a separate cloud, physically and logically isolated from existing AWS regions, with its first region planned in the German state of Brandenburg and targeted to come online by the end of 2025. As of mid-2025 it remains a forthcoming offering rather than an operational one, but it represents the clearest statement of the hyperscaler approach: a ring-fenced European entity, with European control structures, running the same APIs and services customers already use. Microsoft and Google have pursued comparable strategies through EU data boundary commitments and partnerships with local operators.

The appeal of this path is continuity. An organization can claim sovereignty compliance without abandoning the platform, tooling, skills, and applications it has already built. The migration cost is low because, in principle, there is no migration — the same services run inside a sovereign boundary.

The objection raised by critics is structural. A sovereign entity operated by a subsidiary of a non-EU parent rests ultimately on the credibility of the contractual and organizational firewall between subsidiary and parent. Whether that firewall holds against a determined legal demand on the parent is a legal question that reasonable analysts dispute. And technological sovereignty — independence from the provider’s proprietary APIs and roadmap — is not addressed at all by a sovereign entity; the customer remains as locked in to the platform as before, merely within a European wrapper.

Path Two: Open Infrastructure and European Providers

The alternative path treats sovereignty as a property of the architecture rather than of the operator’s nationality. If the infrastructure is built on open-source components with neutral governance, and operated by an entity subject exclusively to European law, then sovereignty across all three of its dimensions — data residency, operational control, and technological independence — is structural rather than contractual.

This model assembles a stack from open components: a hypervisor and cloud management layer such as OpenStack or OpenNebula, open storage such as Ceph, container orchestration via Kubernetes, and open identity and policy layers. Because none of these components is owned by a single commercial actor that could relicense, withdraw, or be compelled to disclose, the resulting platform cannot be captured by any one vendor’s commercial or legal exposure. The Gaia-X initiative has worked toward the standards and governance framework that lets such stacks demonstrate interoperability and sovereignty compliance, and several national reference implementations build directly on the open stack.

There is a research lineage here that this site has long followed. The scheduling, virtualization, and federation concepts that make multi-site open clouds practical came substantially out of academic distributed-systems work, and OpenNebula’s origins in that tradition give the open path a heritage as well as a present-day rationale. Sovereignty by architecture is, in a sense, the natural endpoint of the open-infrastructure project: infrastructure that organizations can fully inspect, operate, and control because no part of it is anyone else’s proprietary black box.

The objection to this path is operational. Running open infrastructure requires cloud-operations competence that the hyperscaler model lets organizations outsource. The skills, staffing, and discipline to operate OpenStack or its peers reliably at scale are real costs, and not every organization has them. European providers and distribution vendors (Red Hat, SUSE, Canonical) exist precisely to bridge this gap with supported distributions and managed offerings, but the buyer must still accept more operational ownership than the hyperscaler path demands.

Comparing the Two

The two paths optimize for different things:

  • Migration cost. The hyperscaler sovereign entity wins decisively — for existing customers, it is nearly frictionless. The open path requires real migration effort and new operational capability.
  • Technological independence. The open path wins decisively — it eliminates proprietary lock-in by construction, while the sovereign entity preserves it.
  • Legal robustness of sovereignty. Contested for the hyperscaler path (it depends on the parent-subsidiary firewall); structural for the open path (no non-EU entity is in the control chain at all).
  • Operational burden. The hyperscaler path keeps the burden with the provider; the open path shifts it to the customer or a European operator.
  • Negotiating leverage over time. The open path preserves it through genuine portability; the sovereign entity does not improve it, since the customer remains coupled to the platform.

Many organizations will not choose one path exclusively. The pragmatic pattern emerging is workload classification: place the most sensitive and most lock-in-averse workloads on open sovereign infrastructure, while keeping less sensitive workloads on hyperscaler platforms — including their forthcoming sovereign entities — where the convenience outweighs the independence concerns.

The Outlook

The race is genuinely open as of mid-2025. The hyperscalers’ sovereign offerings are arriving but, in the most-discussed case, not yet operational; the open ecosystem is mature enough to deploy but demands more of the buyer. Which path dominates will depend partly on how regulators interpret sovereignty — specifically, whether the contractual firewall of a hyperscaler sovereign entity is deemed sufficient for the highest-assurance tiers, or whether genuine architectural independence is required. That regulatory question, still being worked out through the EU’s certification frameworks, will shape billions of euros of procurement.

For European infrastructure teams, the practical advice is to decide deliberately rather than by default. The hyperscaler path is the path of least resistance, which is exactly why it deserves scrutiny: convenience is how lock-in accumulates. The open path costs more upfront in skills and migration but buys a sovereignty that does not depend on anyone’s promise to behave. The right answer depends on the workload, the regulatory tier, and the organization’s appetite for operational ownership — but it should be a decision, not an accident.

Further Reading

Back to Blog