Skip to content
Home Blog Vendor Strategy

Sovereign cloud is a promise about technology. Whether it is also one about law appears in no press release.

The European sovereignty offerings from the big cloud providers are described with unusual technical precision: separate legal entities, operation by people resident in the EU, no critical dependencies outside the EU. That very precision makes visible what the announcements stay silent about.

Fabian Weiss, founder of FW Delta Fabian Weiss
Jul 22, 2026 7 Min Read

Key Takeaways

  • AWS made the European Sovereign Cloud generally available on 15 January 2026. The first region is in Brandenburg, the announced investment in Germany is more than 7.8 billion euros.
  • The announcement describes a new parent company, three German GmbH subsidiaries and operation exclusively by people resident in the EU.
  • The US CLOUD Act does not appear in the announcement. That is not a gap in the text but the difference between a technical and a legal commitment.

What is actually promised

It pays to read the announcements closely rather than judge them. The AWS press release of 15 January 2026 is a good example, because it is unusually specific.

It promises a dedicated corporate structure in Europe, with a new parent company and three subsidiaries incorporated in Germany as GmbH entities. It promises operation exclusively by people resident in the EU. It promises no critical dependencies on infrastructure outside the EU. It promises that authorised employees resident in the EU can, in exceptional cases, independently access a copy of the source code. And it contains the sentence that there is zero operational control outside of EU borders.

The first region is in Brandenburg. The announced investment in Germany is more than 7.8 billion euros. Further locations in Belgium, the Netherlands and Portugal are announced.

That is notable. It is considerably more than the promise, standard for years now, that the data sits in Europe. The location of the data only says where the disks are. These commitments say who operates the system, who can reach it and where the entity carrying the liability is incorporated. If you understand digital sovereignty as a technical question, this is a serious answer.

The point in one sentence

A technical commitment describes what the system can do and who operates it. A legal commitment would describe which orders the operator has to follow. The first is in the announcement at length, the second is not, not even by implication.

What the announcement does not say

The US CLOUD Act does not appear in the press release. Neither confirming nor denying. It simply does not appear. The CLOUD Act is a US law that, under certain conditions, allows US authorities to access data stored by US companies, even when the data sits outside the US.

Getting this right matters. It is not evidence that the law would apply to this structure. It is equally not evidence that it would not. It is the finding that the question is not answered in the announcement. For a purchasing decision, nothing can be derived from it that you could write into a document.

That reticence is understandable. Whether a German GmbH with a US parent is subject to orders under US law is a legal question with many moving parts: corporate structure, actual control, the type of order, conflicting jurisdictions. No provider can settle that question in a press release, because in the end courts settle it. A provider making a hard commitment here would be less credible, not more.

The error therefore does not sit with the providers. It sits wherever a technical commitment gets booked in procurement as the answer to a legal question, because both questions travel under the same word.

This is not legal advice

This text assesses no legal position and makes no statement about whether a particular structure is subject to a particular order. It only describes which statements were made publicly and which were not. The legal classification belongs with your lawyer and has to happen for your specific case.

Why the word sovereign does so much work

Sovereignty has become a collective term in the cloud discussion. Underneath it sit at least four distinct properties. They are independent of one another but routinely treated as one package in procurement.

Location of the data. Where does the data physically sit? Easiest to promise, easiest to verify, least meaningful.

Operational control. Who can reach the running system, with which rights, from where? Considerably stronger, verifiable through access logs and personnel processes. This is precisely where the new offerings aim.

Legal reach. Which jurisdiction governs the operator and which orders can it face? Not solvable through technology and not provable through commitments.

Technical replaceability. How long does it take, what does it cost and what is lost if you have to leave this provider? Entirely in your hands and independent of where the servers stand.

The new offerings serve the first two points very directly and strongly. They do not serve the third and they do not claim to. They do not serve the fourth at all. In one respect they make it harder: an environment with its own user management, its own billing and its own network services is by design more self-contained than a standard region.

The point the debate loses

If you choose a sovereignty offering in order to become less dependent on a provider, it is worth looking at the direction of travel.

You are not moving from one provider to another. You are moving within the same provider into an environment that is more tightly bounded than the one you were in. The location of your data improves. Your operational control improves. Your ability to leave again moves in a direction that appears in no announcement, because nobody promises it and nobody disputes it.

That quantity is exactly what our report on EU cloud switching and exit readiness measures. It puts law, transfer costs, technical portability and recoverability into one shared model, across five big providers, with open raw data. The report deliberately does not rate what a provider says about sovereignty. It rates what is in that provider’s documentation for leaving. Those are two different things and only the second one helps you on the day you switch.

The Data Act has, since 12 September 2025, moved part of this question out of the negotiating room and into the legal one. That noticeably changes the starting position for switching conversations. It does not change the fact that a move which is not technically prepared still takes a long time, even with a legal right behind it.

What you can check now

The useful response to these offerings is neither enthusiasm nor rejection, but a clean separation of the questions inside your own organisation.

  1. Establish which of the four properties you actually need. Write them down separately. Most requirements contain exactly one that is genuinely binding. The other three came along for the ride.
  2. For operational control, demand evidence rather than commitments. Access logs, personnel requirements, process descriptions. That is verifiable and precisely the area where the new offerings are strong.
  3. Let a lawyer answer the legal question. For your specific case, with your specific data. Not a press release and not an architecture diagram.
  4. Measure replaceability independently. How many days to restoration in another environment, how much data volume, which functions have no equivalent? No provider knows those numbers. They are yours.

Point four is the only one entirely in your hands. It is the only one that still holds when the legal position or a provider strategy changes. It is also the only one that involves work. That is why procurement so often replaces it with a commitment.

The actual benchmark

Sovereignty cannot be bought, because it is not a product property. What can be bought is the location of the data and operational control. The new offerings deliver noticeably more of both than what existed before. That is real progress and should be named as such.

What cannot be bought is the ability to leave a provider. That only comes from building systems so they can run elsewhere. And from occasionally trying it rather than assuming it. That requires no European region, but portable data formats, documented interfaces and a restore test that has actually run once.

How to build applications so that a provider change stays a task rather than becoming a project is described on our custom development page. The short version: the location of the servers is the easiest property of a system to change. Everything else is the work.

Newsletter

Research for technical decisions

New reports, benchmarks and technical analyses on SaaS economics, AI engineering and owned infrastructure.

Original research Public sources No sales mail

By subscribing you receive new analyses and updates from FW Delta by email. You can withdraw your consent at any time. Further information is available in the privacy policy.

Newsletter

Research for technical decisions

New reports, benchmarks and technical analyses on SaaS economics, AI engineering and owned infrastructure.

Original research Public sources No sales mail

By subscribing you receive new analyses and updates from FW Delta by email. You can withdraw your consent at any time. Further information is available in the privacy policy.