There is a slightly uncomfortable question hiding behind the growing market for sovereign cloud. What happens when the sovereign cloud is built on top of a hyperscaler?

The question is no longer theoretical. Across Europe, the Gulf and other regions that are trying to strengthen their digital sovereignty, we increasingly see architectures that combine local infrastructure and governance with technology provided by companies such as Microsoft, Amazon or Google. It is not difficult to understand why.

There is little point in pretending that every country needs to build its own version of Azure or AWS from scratch. Hyperscalers have spent decades and enormous amounts of capital building infrastructure, software platforms, security capabilities and global service ecosystems that are extraordinarily difficult to reproduce. Even countries with substantial resources would find it difficult to recreate that entire technology stack simply for the sake of being able to call it local. So why not use them?

Put the infrastructure in the country, apply local controls, keep the data within the required jurisdiction, introduce local operational capabilities and compliance monitoring, and use the scale and technology of the hyperscaler underneath.

On paper, this sounds like a sensible compromise. Local infrastructure. Global technology. Local governance. Hyperscale. And, of course, sovereignty. At least that is the promise.

The interesting question is what exactly that compromise gives us.

The elephant in the room
There is a good example of this in the UAE. Core42's Sovereign combines Microsoft Azure’s hyperscale capabilities with UAE-specific sovereignty and security controls through the Core42 Insight application. The company describes the service as providing access to the Azure service portfolio while hosting data in the UAE through Azure regional infrastructure and applying additional sovereign controls and continuous compliance monitoring.

I find this architecture interesting precisely because there is nothing inherently contradictory about it. The UAE does not need to recreate Microsoft's global cloud infrastructure in order to provide cloud capabilities that satisfy particular local requirements. If the objective is to give regulated organizations access to hyperscale technology while keeping workloads and data within the UAE and applying additional local controls, using Azure as the underlying infrastructure is a perfectly understandable architectural choice.

The company itself does not present the model as Microsoft disappearing from the picture. Quite the opposite: the proposition is explicitly about combining Azure's capabilities with UAE-centric sovereignty and security controls. But that brings us to the question that interests me much more than whether the product should be called sovereign - what exactly has become sovereign?

The data and infrastructure are in the UAE. There are UAE-specific controls around the environment, and there is local compliance monitoring. But the underlying technology is still Microsoft Azure (US).

That does not make the solution illegitimate, nor does it make the sovereignty proposition meaningless. It simply means that sovereignty exists at several different levels, and those levels do not necessarily belong to the same organization or jurisdiction.

And that is where the discussion becomes considerably more interesting than the label on the product.

A data center is not a jurisdiction
We tend to treat physical location as if it answers more questions than it actually does.

If the data is stored in a data center in Abu Dhabi or Dubai, we know where the data center is. If a workload is running in an Azure region in the UAE, we know where that particular infrastructure is located. If the environment is operated according to UAE regulatory requirements, we also know something about the controls applied to it.

What we do not know from the physical location alone is who owns the underlying technology, who develops and maintains the software, who ultimately controls the platform, which dependencies remain outside the country, or which legal obligations apply to the companies involved.

This distinction becomes particularly important with hyperscalers because the cloud region is only one part of a much larger technology relationship.

The servers may be in the UAE while the software stack comes from elsewhere. The infrastructure may be operated locally while the technology is developed and maintained globally. The data may remain in the country while the organization providing the underlying cloud platform is incorporated and subject to laws in another jurisdiction.

The dependency therefore does not disappear simply because the physical infrastructure has moved closer to the customer. It has changed its shape.

And perhaps this is the point at which the word sovereignty becomes slightly dangerous. It encourages us to look for one answer to a problem that actually has several different dimensions.

The mammoth in the room
This is where the US CLOUD Act inevitably enters the conversation and it is also where the discussion tends to become unnecessarily dramatic.

The simplified version is usually something along the lines of: if your data is stored in the UAE but your cloud provider is American, the US government can access it anyway. That is a convenient sentence.

It is also not a particularly precise description of what the law does. The CLOUD Act made explicit that a service provider subject to U.S. jurisdiction can be compelled to produce data within its possession, custody or control regardless of where that data is physically stored. The U.S. Department of Justice describes this as an established principle made explicit by the Act. That does not mean that the U.S. government has a magic key to every Azure data center in the world.

This is not unique to the United States; the underlying principle - that a jurisdiction can impose obligations on providers subject to its authority even when the relevant data is stored elsewhere - is also reflected in the laws of a number of other countries and in the Budapest Convention framework.

What makes the CLOUD Act particularly relevant to the sovereignty discussion is therefore not simply that it reaches beyond the physical border of the United States, but that it makes clear why data residency and jurisdictional control are two different things.

There is legal process involved, and Microsoft's own explanation of the CLOUD Act stresses that the law does not create direct or unfettered government access to customer data. Microsoft also says that, when it receives demands for enterprise customer data, it generally seeks to redirect the requesting authority to the enterprise itself and provides notification where legally permitted.

Those qualifications matter. The CLOUD Act is a legal mechanism, not a technical back door into an Azure region. But the underlying sovereignty question remains. The physical location of the data does not, by itself, determine the jurisdictional relationship of the company that controls the underlying service.

We are therefore no longer asking only where is the data? We are also asking who can legally compel whom to provide access to it? Those are two different questions, and they can have two different answers.

The problem with “local”
Imagine that we take a workload belonging to a UAE financial institution and place it in a UAE Azure region. The data remains inside the UAE. The organization can apply UAE-specific compliance controls. The environment can be continuously monitored, and access can be restricted according to local requirements. The customer can benefit from Microsoft's global technology and Azure services without moving the workload to a region somewhere else.

That is clearly different from simply running the same workload in an overseas cloud region. But it does not mean that Microsoft has ceased to be part of the architecture. Azure remains the underlying platform.

This is where I think we need to be careful with the word “sovereign”. A local cloud region can provide very meaningful sovereignty benefits without eliminating the dependency on the company that provides the underlying technology. Those two things can be true at the same time. In fact, they probably have to be.

Because if sovereignty means the complete elimination of external dependencies, we quickly arrive at an absurd conclusion.

How far does sovereignty actually go?
We could try to solve the problem by continuing to move down the technology stack.

If the cloud platform is not sufficiently sovereign, perhaps we should own the infrastructure. If the infrastructure is not sufficient, perhaps we should own the software. If the software is not sufficient, perhaps we should own the hardware. If the hardware is not sufficient, perhaps we should manufacture the chips.

And once we have reached that point, we have somehow moved from discussing sovereign cloud into rebuilding the global technology supply chain inside a national border. That is obviously not how modern technology works.

Even a completely locally operated data center depends on networking equipment, processors, operating systems, security products, firmware, software libraries, maintenance capabilities and a supply chain that almost certainly crosses multiple jurisdictions. There will always be dependencies.

The realistic question is therefore not whether a country has eliminated every external dependency. It has not.

The more useful question is whether it has identified the dependencies that matter, understood the consequences of those dependencies and retained enough control over the critical ones.

That is a very different definition of sovereignty. And, incidentally, a much more useful one.

Oh, the layers
Perhaps the easiest way to make this distinction is to stop thinking about sovereignty as a single property.

At the data layer, we can ask where information is stored, processed and transferred. At the operational layer, we can ask who operates the environment, who can administer it and who has privileged access.

At the technology layer, we can ask how dependent the organization is on a particular platform, technology or supplier. At the jurisdictional layer, we can ask which legal systems can reach the organizations involved and under what circumstances.

Then there is the supply-chain layer. Where do the hardware, networking equipment, chips, firmware and other critical components originate, and how dependent is the architecture on suppliers that sit outside the country?

And finally there is the strategic layer, which may be the least visible when we are filling in a procurement questionnaire - what happens if the relationship changes? What happens if the provider changes its terms? What happens if a particular service is discontinued? What happens if the organization needs to migrate? What happens if the provider becomes unavailable? What happens if a new regulation makes the existing architecture unsuitable? And what happens if geopolitical circumstances turn a previously acceptable dependency into a strategic risk?

A solution can therefore be highly sovereign at one layer and heavily dependent at another. That does not make the solution fraudulent. It makes it complicated.

Technology usually is.

The CLOUD Act
This is also why I would be careful about making the CLOUD Act the villain of the story. The underlying principle is not particularly exotic. Governments routinely impose legal obligations on companies operating within their jurisdiction. The U.S. Department of Justice itself describes the CLOUD Act in the context of a broader, longstanding principle that companies subject to a country's jurisdiction may be required to produce information within their custody or control.

Other countries have their own legal mechanisms.

The uncomfortable part is not simply that the United States has jurisdiction over companies subject to U.S. law. The uncomfortable part is what happens when a country is trying to establish digital sovereignty while depending on infrastructure whose provider remains subject to another country's jurisdiction.

That is where the distinction between data sovereignty and jurisdictional sovereignty becomes important.

You can have data in the UAE and still have a technology dependency on an American company. You can have local operations and still depend on foreign software. You can have a local cloud region and still depend on a global supply chain. None of this makes the local cloud meaningless.

It simply means that the word sovereignty is describing only part of the architecture.

What does a sovereign cloud actually buy us?
Perhaps the better way to test a sovereign cloud proposition is not to go through a list of sovereignty requirements and check how many boxes have been ticked, but to look at the architecture from the moment when things stop working as expected. What happens if the cloud provider becomes unavailable, if a service on which the workload depends is discontinued, or if the organization suddenly needs to move that workload somewhere else? How difficult would that move actually be, and how much of the application could be transferred without taking the provider's proprietary services with it? And if the relationship with the provider changes for legal, commercial or geopolitical reasons, is there another operator that could realistically take over?

This is where the less visible part of sovereignty becomes important. A cloud environment may provide local infrastructure, local operations and local compliance controls, but the real measure of control may only become apparent when those controls need to be exercised: when a legal request reaches the provider, when a critical service becomes unavailable, when a dependency can no longer be used, or when the customer decides that it needs to leave. These situations rarely produce convenient yes-or-no answers, but they reveal much more about the actual resilience and control of the architecture than the location of the data center alone ever could.

Perhaps this is where the sovereign cloud discussion should mature: not by becoming more suspicious of hyperscalers, but by becoming more precise about what we expect them to provide, what we expect the local sovereign layer to control, and what choices remain available when the relationship with the underlying provider changes.

The hyperscaler is not necessarily the problem
There is an irony here. The more we talk about sovereignty, the more tempting it becomes to treat hyperscalers as the problem that sovereignty is supposed to solve. But hyperscalers are also part of the reason sovereign cloud architectures are possible at the scale we are discussing.

A country does not have to build a global cloud platform in order to provide local cloud capabilities. A regulated organization does not necessarily have to operate its own data center in order to satisfy every sovereignty requirement. And a government does not have to reject global technology companies simply because it wants greater control over its digital infrastructure.

The more interesting model is often somewhere in between: use global technology where it makes sense, introduce local control where it matters, and be explicit about the dependencies that remain.

Any type of Sovereign Public Cloud is an obvious example of this model. Its own description often describes a proposition to combine XYZ hyperscale capabilities with national controls, governance and compliance monitoring rather than attempt to replace the hyperscaler underneath.

That may not satisfy the purist definition of sovereignty. But I am not sure the purist definition is particularly useful in the real world.

The uncomfortable part
The uncomfortable part is that the word “sovereign” has become a very attractive word. It sounds reassuring. It sounds strategic. It sounds like control. And because of that, there is a natural temptation to attach it to products, platforms and architectures without always explaining exactly what the word refers to.

A sovereign cloud can therefore be sovereign in one dimension and dependent in another. It can provide local data residency while relying on foreign technology. It can provide local operational control while depending on a foreign software stack. It can reduce some risks without eliminating others.

None of this makes the architecture meaningless. It simply means that the word needs a little more precision. Perhaps instead of asking whether a cloud is sovereign, we should ask what it is sovereign over, and what it remains dependent on.

That is a much harder question to put into a marketing brochure but, at the same time, it is also a much better question to put into an architecture review or questionnaire.

Sovereignty is not a switch
There is a tendency to frame the discussion as a binary. Either we use the hyperscaler and give up sovereignty, or we build everything ourselves and become sovereign. Only few countries in the world (if not one, to be honest) can do it as desired scale.

Reality is considerably less elegant.

A UAE organization may decide that using Azure infrastructure in the UAE, combined with local governance and additional controls, gives it an acceptable level of sovereignty for a particular workload. Another organization may decide that the same architecture leaves too much strategic dependency on Microsoft. A third may decide that a private cloud is necessary. A fourth may decide that the dependency is acceptable given the nature of the workload and the cost of eliminating it. Those can all be rational architectural decisions because they are answers to different risk profiles.

The important part is knowing what has actually been decided and that is perhaps the biggest lesson from this discussion. Sovereignty is not a switch. It is an architecture. It has layers. It has dependencies. It has costs. And it has trade-offs.

The hyperscaler does not magically disappear because the data center has a UAE address. But neither does the sovereignty value of a local cloud disappear because Microsoft, Amazon or Google is somewhere underneath it. Both things can be true at the same time.

That is probably the uncomfortable middle ground we should become better at discussing.

And perhaps that is where we should leave it
We started this series by asking what sovereignty means in digital life. We have moved through the philosophical idea, the policy discussion, the practical questions of data location and operational control, and finally into the architecture that organizations actually have to procure and operate.

The hyperscaler brings us back to the same problem from another direction. It shows us that sovereignty was never a binary property in the first place.

There will always be dependencies. The interesting question is whether we understand them, whether we have deliberately accepted them, whether we can control the dependencies that matter, and whether we have meaningful alternatives when one of them becomes unacceptable.

Perhaps this is the most useful way to think about sovereign cloud. Not as the absence of foreign technology. Not as a guarantee that nothing can ever cross a border. And not as a label that makes the underlying dependency disappear.

Rather, as an architectural decision about which dependencies we are prepared to accept, which ones we need to control, and what happens when we can no longer accept them. That may sound less impressive than simply saying that something is “sovereign”.

But it is probably much closer to what sovereignty actually means. And perhaps that is the question worth putting into the next 650-question spreadsheet…

Sovereign over what?