Sovereign Cloud Is a Claim About Architecture. Whether It Is Also One About Law Appears in No Press Release.

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 governance structure in Europe, with a new parent company and three subsidiaries incorporated in Germany as GmbH entities. It promises operation exclusively by EU residents. It promises no critical dependencies on non-EU infrastructure. It promises that authorised EU-resident employees have independent access in exceptional cases to a replica of the source code. And it contains the phrase that there is zero operational control outside of EU borders.

The first region sits in Brandenburg, the announced investment is more than 7.8 billion euros in Germany, further regions are announced.

That is notable. It is considerably more than the data residency commitments that have been standard for years. Data residency says where bytes sit. 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 an architecture question, this is a serious answer.

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.

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 communication, and that nothing can be derived from it for a procurement decision that you could write into a document.

That reticence is understandable, incidentally. Whether a German-incorporated subsidiary 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 the provider does not settle it. Courts do. 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 an architecture commitment gets booked in a procurement process as the answer to a legal question, because both questions travel under the same word.

Why the word “sovereign” carries so much weight

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

Data residency. 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, and precisely where the new offerings aim.

Legal reach. Which jurisdiction governs the operator and which orders can it face? Not solvable through architecture 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 address the first two points very directly and strongly. They do not address the third, and they do not claim to. They do not address the fourth at all, and in one respect they make it harder: an environment with its own identity management, its own billing, its own DNS and its own certificate authority is by construction 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. Your data residency improves, your operational control improves, and your exit capability 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 providers, with open raw data. The central observation from it fits in one sentence: documented exit capability correlates weakly with what a provider communicates about sovereignty.

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 migration which is not technically prepared still takes a long time, even with a legal right behind it.

What follows in practice

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, and write them down separately. Most requirements contain exactly one that is genuinely binding and three that 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 lawyers 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, and the only one that still holds when the legal position or a provider strategy changes. It is also the only one that involves work, which 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 data residency and operational control, and 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 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.