Cloud sovereignty is becoming one of the most consequential infrastructure questions facing governments and enterprises. Europe is spending billions on sovereign cloud platforms, AWS is investing €7.8 billion in its European Sovereign Cloud, and policymakers are asking whether storing data locally is enough when the provider itself may remain subject to another country’s laws.

For much of the last decade, cloud risk discussions treated location as the decisive variable: choose the right region, keep customer records inside the appropriate geography, configure backups correctly, and satisfy the residency requirement. That remains important. But the deeper sovereignty question is harder. Where the data sits is only one part of who ultimately has power over the service.

A workload may be physically hosted in London, Frankfurt or Paris while depending on a foreign-owned control plane, proprietary identity systems, overseas legal entities, vendor-managed encryption services and technical components that cannot be recreated economically elsewhere. In that situation, the organisation may have achieved residency while retaining substantial strategic dependence.

Why Cloud Sovereignty Is More Than Data Residency

The easiest sovereignty promise for a provider to demonstrate is geographic: customer data, replicas and backups stay inside an approved territory. The harder test is whether the customer retains meaningful control when jurisdiction, technology and supplier incentives change.

This distinction matters because sovereign-cloud marketing tends to concentrate on the controls easiest to describe: local data centres, EU personnel, separate operations, encryption boundaries and restricted administrative access. All are valuable. None, individually, answers the larger question of strategic autonomy.

How Residency Becomes Sovereignty Debt

The mechanism is straightforward. An organisation localises its data, then adopts progressively more proprietary platform services because doing so improves development speed and reduces operational burden. Over time, identity, databases, eventing, analytics, serverless functions and AI services become embedded in application architecture. The workload remains “portable” in theory while becoming progressively more expensive to recreate somewhere else.

This is where cloud sovereignty becomes fundamentally different from conventional data localisation. The sovereignty risk is not the existence of a foreign cloud provider. It is the accumulation of dependencies that become difficult to alter precisely when the political, regulatory or commercial environment makes alteration most valuable.

The CLOUD Act Changes the Question From “Where?” to “Who Controls It?”

The US CLOUD Act is often described too casually. It does not give American authorities unrestricted access to every European workload operated by a US company. Legal process remains necessary, and the statute includes mechanisms addressing certain conflicts of law. But its core extraterritorial principle is directly relevant to sovereignty.

Section 2713 of US law states that a covered provider must preserve, back up or disclose information within its “possession, custody, or control” regardless of whether that information is located within or outside the United States. That phrase is why a purely geographic definition of sovereignty is inadequate.

AWS Is Spending Billions Because Sovereignty Has Become Commercially Unavoidable

AWS’s response is substantial. The company has committed more than €7.8 billion through 2040 to its European Sovereign Cloud, which is designed as a separate European environment with additional operational autonomy, European governance and controls intended for governments and highly regulated industries.

That investment should not be dismissed as marketing. It reflects real engineering work and real demand. European customers increasingly require stronger guarantees over operator location, metadata, administrative access and continuity. The sovereign-cloud model addresses many of those concerns more effectively than a conventional public-cloud region.

When Two Providers Dominate the Market, Supplier Risk Becomes Systemic

The UK Competition and Markets Authority concluded that AWS and Microsoft together accounted for roughly 60–80 percent of combined UK IaaS and PaaS revenues in 2024. In IaaS alone, concentration was higher still. That matters because sovereignty risk changes character when large parts of government, healthcare, finance and enterprise computing depend on the same small group of suppliers.

Concentration does not make the leading platforms technically inferior. In many respects the opposite is true: scale funds world-class security engineering, global networks and deep service portfolios. But concentration increases the strategic cost of correlated dependency. If the same legal, geopolitical or commercial shock affects a dominant provider, the consequence can propagate across many customers simultaneously.

Stop Asking Whether a Cloud Is Sovereign. Ask How Sovereign the Workload Is.

Cloud sovereignty is better treated as a multidimensional architecture property than a vendor label. The same provider can be entirely appropriate for one workload and inappropriate for another depending on legal sensitivity, exit requirements, service criticality and the organisation’s tolerance for external dependence.

Architecture	Residency	Jurisdictional autonomy	Portability	Operational control
Standard hyperscaler region	High	Low	Low–Medium	Medium
Hyperscaler sovereign cloud	Very high	Medium	Low–Medium	High
Locally owned / governed cloud	Very high	High	Medium	High
Open portable multi-cloud design	High	High	Very high	Very high

Illustrative architecture framework, not a certification rating. Actual outcomes depend on contracts, key management, operational model, service selection and workload implementation.

Can You Still Say “No” to the Provider Five Years From Now?

The most revealing sovereignty question is not whether the provider has a local region. It is whether the customer could credibly leave when circumstances change. Could the organisation export its data? Recreate identity and access controls? Replace proprietary databases? Rebuild event-driven services? Transfer operational knowledge? Restore applications somewhere else before disruption becomes unacceptable?

If the answer is no, the organisation has accumulated sovereignty debt even if every byte remains inside the approved geography. This is why exit capability may be the most useful single proxy for strategic autonomy.

Six Controls That Matter More Than a “Sovereign” Label

Can Hyperscalers Deliver Real Cloud Sovereignty?

Yes — to a degree that may be entirely sufficient for many workloads. Sovereignty is not a purity test. AWS, Microsoft and Google can deliver extraordinary security, resilience, scale and engineering capability, and sovereign variants can materially reduce several classes of risk.

The mistake is not using a US hyperscaler. The mistake is using one without understanding the dependencies being accepted. The right architecture therefore starts with workload requirements: which systems genuinely need stronger legal autonomy, which need technical portability, which require independently controlled keys, and which can rationally accept ordinary hyperscaler dependence in exchange for speed and capability?