Sovereign Cloud Strategy: Residency Is Not Enough

The requirement came in through a contract. I am working with a telco on a mission-critical business case, and the sovereignty requirement arrived from the customer. The written words were plain enough: sovereign cloud, data stored in the EU. Residency, spelled out in a procurement clause. Except every conversation we had about it circled back to something the clause did not say. They were not worried about which building the disks were in but about who could reach into the system and turn it off, and under whose law that instruction would be legal.

The words and the fear did not match. Somebody in the room had to say so out loud, because the gap between them is exactly where a sovereignty programme quietly fails: you satisfy the sentence that was written, you deploy into an EU region, everybody signs, and the thing the customer was actually afraid of is untouched. We ended up going to a European provider, and the requirement held instead of being watered down into a region selection on a hyperscaler. I have been through a version of this once before, at a bank that wanted sovereignty on a blockchain solution, and the pattern was identical. The requirement says "where." The fear is about "who."

My position is that either you buy structural independence from the jurisdiction you are worried about, or you should stop paying the sovereignty premium and admit the threat model is not real. Everything in between sells assurance it cannot deliver, and false assurance is worse than none, because at least none makes you keep thinking.

The Marionette

A marionette can have its own jointed limbs, a control bar close enough for the operator to feel every movement, and still answer, in the end, to whoever the strings actually run to above the bar, which is the part standing on stage can never see and never choose.

The stage is data residency: which theatre, which city, the easiest thing to point at in a slide deck and therefore the thing everybody points at. The near hand on the control bar is operational sovereignty, the operator who can be seen, named, vetted, given a nationality and a badge. That is EU-only support staff made literal. The puppet's own joints are technical sovereignty: whether the figure would still hold a usable shape if the strings were cut this second, or collapse into a pile.

And then there is where the strings actually terminate, above and behind the near hand, out of the lit area entirely. The control bar is a junction, not the top of the rig. The CLOUD Act does not reach for the puppet. It reaches for the bar, and the near hand's grip on the bar was never the thing deciding the performance.

Data residency tells you which stage the performance is on. Jurisdictional sovereignty tells you where the strings actually go.

Four Tiers of Cloud Sovereignty, One Word

Most sovereignty conversations go badly because four different things share a name. Naming them separately is most of the work.

Data residency is where the bytes sit. Cheapest to provide, most marketed, least protective.

Operational sovereignty is who can technically touch the running system. Support staff nationality, break-glass procedures, who holds the console at 3am.

Technical sovereignty is whether you could run this without the vendor. Encryption keys you actually hold, open formats, real portability.

Jurisdictional sovereignty is which government can legally compel disclosure or cut-off, regardless of where the data sits. US CLOUD Act section 2713 obliges US-headquartered providers to produce data in their "possession, custody, or control" on US legal request, wherever it is stored.

Buying an EU region from a US-headquartered provider addresses the first tier. A sovereign SKU addresses the first, much of the second, sometimes the third. Neither touches the fourth, which is what my telco's customer was afraid of.

There is a fifth thing worth separating out, which is exit and reversibility: whether the joints have a locking pin. A figure with no lock still needs the bar upright. One with a lock can be set down and left standing. Most architectures I have seen claim to be portable and have never tested it.

The Objection I Would Raise Myself

Before anyone else does: vendors resist. A well-built rig has slack in the line, enough give that a tug from above does not move the limb instantly or exactly. That slack is a general counsel's office. Legal challenge, procedural delay, minimum-necessary pushback, transparency reports. It is real, it changes timing, and it sometimes changes outcomes.

It is also not a control you own. Slack is still string, and string goes where it goes.

In February 2026, the ICC Chief Prosecutor lost access to his Microsoft mailbox weeks after being placed under US sanctions by executive order. The court subsequently migrated to OpenDesk, Nextcloud and Collabora. An institution discovered its continuity depended on a decision taken in another jurisdiction, and it discovered this after the fact rather than during architecture review.

This is where the analogy breaks, in a way worth naming. A puppet cannot choose to resist; a company can, and does. Real resistance comes from a corporation's legal strategy and structure, not from give in a mechanical line. If you are betting on vendor resistance, you are betting on something the analogy cannot model and you cannot audit.

Sovereign Cloud Offerings: AWS, Microsoft, S3NS Compared

All three are honest products, sold under one word while doing different jobs.

Offering	Stage	Hand on the bar	Joints	Where the strings terminate
AWS European Sovereign Cloud	Brandenburg, Germany, GA 15 January 2026	EU-only operational staff, independent IAM	Decent articulation	Same distant terminus, US parent
Microsoft Sovereign Landing Zone	Existing Azure regions	Described in detail, configurable	Configured by pattern	Unchanged, US parent
S3NS (Thales / Google Cloud JV)	France, SecNumCloud 3.2 across IaaS, CaaS and PaaS, 17 December 2025	French operator	Qualified to the strictest French bar	A different rig, French-controlled JV

AWS has invested seriously here and plans more than 7.8 billion euro in Germany by 2040. Good grip, good joints, same rig. Microsoft's Sovereign Landing Zone is a platform pattern layered on the existing Azure Landing Zone. It describes how the hand holds the bar. It does not move the strings.

S3NS is where the marionette reaches its honest limit. An operationally independent joint venture is not a puppet with a longer bar. It is closer to a different rig entirely, where the local operator owns the workshop the bar was built in. The marionette explains graduated control well and structural independence poorly, which is why the graduated-control offerings are easier to market: they fit the picture everyone already has.

The structurally independent option is not hypothetical. For the providers below, the strings terminate at home in every row. What varies is who owns them.

Provider	Home	Ownership
OVHcloud	France	Listed on Euronext Paris, Klaba family retains majority voting control
Scaleway	France	Iliad Group, controlled by Xavier Niel
Hetzner	Germany	Privately held by its founder
IONOS Cloud	Germany	Listed in Frankfurt, United Internet holds 63.8%
UpCloud	Finland	Privately held, investors include the Finnish state fund Tesi
Exoscale	Switzerland	Akenes SA, majority held by A1 Digital

Exoscale is the row that proves the method. It is Swiss-operated and almost universally described as Austrian-owned, which sounds like a European answer. Follow the chain to the top and A1 Digital belongs to Telekom Austria Group, of which América Móvil holds 60.6%, a controlling majority, from Mexico. Whether that troubles you depends entirely on the government you wrote down earlier. The label stops one level short of the answer, every time, and the only fix is to keep asking who owns that until you reach someone who owns themselves.

Regulators are converging on the same test. The European Commission's 3 June 2026 sovereignty package proposed jurisdictional risk tests that would place AWS, Azure and Google Cloud outside the highest assurance tier for sensitive EU public-sector contracts, sovereign regional offerings included.

I myself have some early hands-on with OVHcloud and Scaleway, and my employer has a partnership with Scaleway. It is too early to tell you how those comparisons land in practice, and I am keen to find out on the client implementations ahead of us.

Choosing a Sovereign Cloud Strategy: Decide the Threat Model First

Write down which government you are worried about, by name. If you cannot, you do not have a sovereignty requirement, you have an anxiety.

Separate the four tiers in the requirement document. A clause that says "EU" and means "not reachable by US legal process" will be satisfied by a region selection and will fail the actual test.

Treat operational and technical sovereignty as valuable in their own right. Better grip and better joints are worth buying. Just stop letting them stand in for the thing above the bar.

If tier four is the requirement, the operator has to be structurally outside that jurisdiction, by ownership, headquarters and control. If it is not the requirement, stop paying for it. The premium is real, the operational cost is real, and there is nothing noble about buying reassurance you did not need.

The telco engagement worked for one reason, and it was not architecture. Someone said out loud that the clause and the fear were two different documents. That is a five-minute conversation and it almost never happens, because naming the gap makes you the person who complicated the project and most people would rather ship the region selection.

So name it anyway. False assurance is the worst thing you can put into a sovereignty programme, because a team that knows it is exposed keeps thinking, and a team holding a certificate stops. Are you buying sovereignty, or the feeling of it? Whichever it is, decide on purpose, in writing, before someone else's contract decides for you.