The sovereign cloud that isn't: a label for the wrong level

Contents

Digital sovereignty has become a sales argument in 2026, moving from a political buzzword. In mid-January, Amazon Web Services launched the AWS European Sovereign Cloud in Brandenburg, its partition fully operated in the EU with separate billing in euros, its personnel, and a separate legal entity under German law. A few weeks later, Microsoft followed suit with “Microsoft 365 Local,” allowing services like Exchange and SharePoint to be run on customer-owned hardware, decoupled from the public cloud. Both offerings carry the same label, and it is a weighty one: sovereign.

the next big thing – Golo Roden

Golo Roden is the founder and CTO of the native web GmbH. He works on the design and development of web and cloud applications and APIs, with a focus on event-driven and service-based distributed architectures. His guiding principle is that software development is not an end in itself, but must always follow an underlying technical expertise.

I consider this label misleading. Not because the technical and organizational measures are worthless; on the contrary, they are considerable. But because they leave untouched precisely the one level that matters for sovereignty. Anyone who wants to understand why a cloud operated in Brandenburg legally remains tied to the United States must first clearly distinguish what “sovereign” can mean. Hardly anyone in the debate makes this distinction, and without it, the participants are talking past each other.

What does sovereign mean here?

Cloud sovereignty breaks down into three levels that are regularly confused. The first is data residency, i.e., the question of where data is physically located. The second is operational autonomy, i.e., the question of who operates, maintains, and, in case of doubt, can access a system. The third is legal sovereignty, i.e., the question of whose law applies in case of conflict and who can issue directives to a provider that it must follow.

These three levels are not equivalent, and that is the crucial point. Data residency and operational autonomy can be established contractually and technically, and this is precisely what the new offerings are doing with great effort. The legal level, however, eludes such measures, as it depends not on the location of the servers but on the jurisdiction to which the parent company is subject.

A simple thought experiment makes the difference tangible. Imagine all data were located in a data center in Brandenburg, operated by people residing in the EU, encrypted, and contractually secured. As long as the corporation owning this operation is subject to a foreign legal system, that legal system can compel it to take action, and no server location changes that. Data residency is a matter of geography, sovereignty a matter of power.

This core meaning is not accidental. Sovereignty has always meant the highest decision-making authority, i.e., the question of who has the final say. Applied to the cloud, this means: sovereign is not whose data is in the EU, but who can determine what happens to it in a dispute. Everything else is convenience, not control.

The new offerings in 2026

The AWS European Sovereign Cloud is technically impressive; I don't want to downplay that. It runs as a separate partition with its region, completely separated from other AWS regions, with its identity and billing system in euros, and operations staffed exclusively by individuals residing in the EU. For certification and digital signatures, Amazon has even founded a separate company under German law. There is no cross-regional data traffic to other AWS partitions; even metadata remains within the EU infrastructure.

However, even the details show how sensitive the matter is. Amazon applies the criterion of residence in the EU, while the BSI prefers nationality, and for government contracts and critical infrastructure, this difference can be significant. A seemingly technical detail determines how far the autonomy actually extends.

Microsoft takes a different approach with “Microsoft 365 Local.” Instead of an isolated cloud region, the offering moves the most sensitive services, such as Exchange and SharePoint, back to hardware on the customer's premises, separate from the public cloud. This is essentially a return to in-house operation, repackaged as a sovereignty solution.

Both approaches address real requirements, and for many use cases, they are sufficient. Data residency, operational separation, and traceable access control are not trivial matters. The problem only arises where these measures are marketed as complete sovereignty, even though they do not touch the legal level at all.

The unresolved core: CLOUD Act and FISA

The CLOUD Act of 2018 obliges US companies to disclose requested data, regardless of where in the world it is stored. In addition, FISA Section 702 and Executive Order 12333 allow US intelligence agencies to collect data of non-US citizens abroad without those affected in Europe having effective legal remedies. These laws have extraterritorial effect, and this is not a minor detail but the core of the issue.

This conflict is not new. As early as 2020, the European Court of Justice declared the Privacy Shield data protection agreement invalid in the Schrems II ruling, precisely because US surveillance laws do not offer European data subjects an equivalent level of protection. The current wave of sovereign cloud offerings is essentially the industry's response to this tension, which has remained unresolved for years, and it tends to shift the problem rather than eliminate it.

A subsidiary under German law changes little as long as the US parent company retains control. This very structure is legally untested. What happens if a US authority orders the parent company to compel its European subsidiary to take a specific action? There is no reliable answer to this yet; it would have to be fought out in court first, and until then, it remains an open flank.

Microsoft itself has admitted how little this can be resolved by technology. Before the French Senate in 2025, the company could not guarantee that European data would never reach US authorities. This is not a marketing issue or a matter of goodwill, but a question of jurisdiction, and it cannot be answered with any number of data centers in the EU.

There is a serious counter-argument, and I don't want to ignore it. Access is rarely practical, it is argued, trustworthiness trumps country of origin, and legally binding contractual assurances are sufficient for many companies. This may be true for non-critical workloads. For public administration, critical infrastructure, and particularly sensitive data, I am not convinced, because sovereignty is not measured by the frequency of access but by the question of who can prevent it in an emergency.

A label for the wrong level

This precisely identifies what is bothersome about the word “sovereign.” It describes the first two levels, data residency and operation, and remains silent about the third, legal control. The label is not a lie, but it is incomplete in a way that obscures the essential, and this gap is no coincidence.

Remarkably, it is precisely those providers whose dependency it is supposed to resolve who are applying the label. An analysis of 17 providers across 31 criteria concludes that none can be called a clear sovereignty winner. US corporations mask structural jurisdictional risks with EU subsidiaries, and European providers also have weaknesses in cryptography and supply chains. Industry associations like CISPE have coined the term “sovereignty washing” for this.

This pattern is not new and it is worth recognizing. I have described elsewhere how corporations appropriate the term “open source” and reinterpret it for their purposes. In the case of sovereign cloud, the same is happening with a different term: a word that originally meant independence becomes a product name for an offering that does not eliminate dependency at all. Whoever occupies a term controls the debate, and that is precisely what it is about.

For the buyer, this has concrete consequences. Anyone who purchases a product labeled as sovereign may be buying data residency and believing they have acquired independence. The difference between the two only becomes apparent when it is too late, namely in a conflict situation for which the label does not prepare them.

Regulation recognizes the problem

Politics has also understood that “sovereign” must become measurable instead of remaining a free promise. In early June 2026, the EU Commission proposed the Cloud and AI Development Act, the first EU law specifically targeting cloud services and artificial intelligence. It is a response to a simple number: around two-thirds of the European cloud market is accounted for by three US corporations, and this dependency is increasingly considered a strategic risk.

At its core is a cloud sovereignty framework with several tiers, which public bodies should use as a guide for procurement. These tiers precisely capture the distinction that is at issue here. The lowest only requires data to be processed in the EU. Only the higher tiers demand independence from third countries and transparency about the software supply chain, and the highest demands ownership and control from within the EU, down to the nationality of the personnel and freedom from any influence by third countries.

In other words, only the highest tier describes what “sovereign” means in its literal sense, while the lowest demands little more than data residency. The BSI pursues a similar line with its catalog of criteria for when a cloud is truly sovereign. The very need for such catalogs is the real admission: If the label were reliable, no one would need to define what constitutes real sovereignty.

The Cloud and AI Development Act is not alone in this; it is part of a larger package with which the EU aims to reduce its digital dependency. This includes specially designated zones for accelerated data center construction, which are intended to multiply Europe's computing capacity within a few years. European providers currently hold only about 15 percent of the market, and it is precisely through public procurement that they could gain ground, provided that the higher sovereignty tiers are actually demanded there.

However, regulation alone does not create an alternative, and that is its limitation. It can describe what is missing, it can steer demand through procurement, and it can force providers to be transparent. But someone else must build the alternative, and this is precisely where the responsibility shifts from politics back to those who design and operate software.

Control over the Stack

Anyone who is serious about sovereignty should treat it as what it is: not a property one buys, but a degree of control one earns. The crucial question is not where the servers are located, but who can take over operations in an emergency and who truly masters the stack, from hardware to platform to data.

This control has several prerequisites, and none of them is sufficient on its own. Open standards and open-source software are a necessary foundation because only open-source systems are auditable and transferable. They are not sufficient because even open-source stacks depend on supply chains, operation, and financing. In addition, there is data sovereignty and the ability to operate services yourself in case of doubt, as well as an architecture in which the specific provider remains an interchangeable detail and not a foundation that can no longer be removed.

Sovereignty is not an all-or-nothing proposition but a spectrum, and the necessary degree is a technical decision. Not every workload requires the highest level, because a public marketing portal has different requirements than a specialized application with social data. The mistake is not using a hyperscaler but failing to make a choice at all and migrating everything there without question. Anyone who consciously decides for each system what degree of control is appropriate practices sovereignty as a design discipline rather than a purchase.

Even where full sovereignty is not achievable, there is a fallback line, namely resilience: customer-controlled encryption, data portability, and technical reversibility as protection against extraterritorial access. These are precisely the demands that European providers are making, and they are more pragmatic than the maximum demand for complete independence. They shift the focus from the provider's origin to the actual control over one's own data.

This stance is essentially nothing new but an old principle of good design. Vendor lock-in is coupling, and good architecture keeps coupling deliberately low. The only difference is that coupling to a hyperscaler is rarely perceived as a design decision. It is inherited rather than chosen, and that is precisely the real sovereignty problem, long before any law or label comes into play.

Europe is beginning to learn this lesson. Initiatives like EuroStack aim for an open, shared infrastructure, and in public administration, real migrations away from proprietary platforms are underway, from Schleswig-Holstein to France. Whether a viable alternative emerges from this is open, and honestly, this path is more arduous and expensive than clicking on an offering labeled as sovereign.

That is precisely why clarifying the term is more than just hair-splitting. As long as “sovereign” remains a label that omits the legal level, you are buying data residency and calling it independence. Sovereignty is not created by a word on a data sheet but by control over one's own stack, and this control must be desired before it can be possessed.

(rme)