Two things can be true of the same server: your data never leaves your country, and a foreign court can still order the company running it to hand that data over. Governments spent a decade discovering the gap between those two sentences, and the cloud industry has spent the last three years building products to close it. This page covers what the term actually means, the four layers of control it rests on, the four separate reasons national governments now treat cloud infrastructure as strategic territory, what capability you lose when you move, and how to tell a real guarantee from a label.
A sovereign cloud is cloud infrastructure built so that the data, the operations and the legal control over both stay inside one country’s or region’s jurisdiction. It goes further than storing data locally: it restricts who can reach the systems, who holds the encryption keys, and which government’s courts can compel disclosure.
Key Takeaways
Data residency puts your data in a country, while sovereignty decides whose courts can reach the company holding it, which is why an in-country data centre on its own does not make a cloud sovereign.
Sovereignty runs across four layers, data, operational, technical and jurisdictional, and most commercial offerings satisfy the first two and stop, so the label alone tells you very little.
Countries want their own cloud for four separable reasons, foreign legal reach, continuity risk, capturing domestic spending and AI compute, so a provider answering only the compliance one is answering the easiest question.
Sovereign environments run a restricted service catalogue, and Google’s Germany Data Boundary documentation states that any product not on its supported list is unsupported, disabling named features such as Local SSDs, VM suspension and uptime checks.
Gartner forecasts that worldwide sovereign cloud IaaS spending will total US$80 billion in 2026, a 35.6 percent increase on 2025, with governments as the main buyers.
What Is a Sovereign Cloud?
A sovereign cloud is a cloud environment where the infrastructure, the people operating it and the legal entity running it are all bound to the jurisdiction whose rules the data has to follow. The design goal is that no foreign government, court or parent company can compel access to the data or switch the service off. Location is one input to that goal, not the goal itself.
In practice, four conditions get written into a sovereign contract. Data stays inside a named geography, and that includes backups, logs and metadata rather than payload alone. Only staff who are residents or citizens of that jurisdiction can reach production systems. Encryption keys are held by the customer or a local trustee rather than the provider. And the operating company is incorporated locally, so a foreign parent cannot lawfully direct it.
The wider idea this sits inside is digital sovereignty: a state’s ability to make its own decisions about the technology its economy and public services run on. Cloud is the part of that argument with a budget line attached, which is why it moved first. The regulations that keep appearing in the discussion are the EU’s General Data Protection Regulation, which governs how personal data may be processed and transferred, and the United States CLOUD Act, which lets US authorities compel US-headquartered providers to produce data they hold anywhere in the world.
The most common mistake made at this stage is treating an in-country region as a sovereign one. Opening a workload in a provider’s local region satisfies a residency requirement and nothing more. The company operating that region, the engineers who can log into it and the courts that can issue orders against its parent are all unchanged, and it is worth understanding how edge and cloud architectures differ before assuming that moving the hardware closer moves the control with it.
Sovereign Cloud vs Public Cloud vs Private Cloud
The three models differ less in technology than in who holds which control. The table below compares them on the attributes that actually decide a sovereignty question.
| Attribute | Public cloud | Private cloud | Sovereign cloud |
|---|---|---|---|
| Where data sits | Provider’s chosen regions | Your data centre or hosted rack | A named country or bloc, backups included |
| Who operates it | Provider staff, any location | Your team or an outsourcer | Vetted staff resident in the jurisdiction |
| Who holds encryption keys | Provider, by default | You | You or a local trustee |
| Which laws can compel access | Host country and the provider’s home country | Host country | Host jurisdiction only, by design |
| Service catalogue | Full | Whatever you build and run | A restricted, published subset |
| Typical buyer | Any organisation | Regulated or legacy-heavy firms | Governments, defence, regulated industries |
A private cloud answers the control question by making everything yours, including the operational burden. A sovereign cloud answers the legal question while leaving the platform work with a provider, which is why governments buy it instead of building.
Data Sovereignty vs Data Residency: The Distinction That Decides Everything
Data residency is a statement about geography: the data is stored in a named country. Data sovereignty is a statement about law: the data is subject to the rules of that country, and no other government can compel the company holding it to produce it. Residency is a fact you can verify on a console. Sovereignty is a property of a corporate structure.
Data residency tells you where your data sleeps. Data sovereignty tells you who can wake it up.
Three terms get used interchangeably and should not be. Residency is where data is stored. Sovereignty is which legal system governs it and who can compel its disclosure. Localisation is a legal requirement, imposed by a government, that certain categories of data must remain physically in-country, which is the rule that creates residency obligations in the first place.
The gap between them is not theoretical. Microsoft France’s director of public and legal affairs told a French Senate inquiry on 18 June 2025 that he could not guarantee under oath that French citizens’ data held by the company would never be passed to United States authorities, answering “No, I cannot guarantee that”, as reported by The Register on 25 July 2025. The data in question was already stored in Europe. Residency was never the issue; corporate jurisdiction was.
That is the whole distinction in one exchange. A provider can move every byte you own into a building inside your borders and still owe a legal duty to a government on another continent. The question worth asking is not where the servers are, but which courts can issue an order the company must obey.
Sovereign Cloud Explained: The Four Layers That Have to Line Up
Sovereignty is not one property but four, and a cloud is only as sovereign as its weakest layer. Vendors tend to lead with whichever layer they satisfy most convincingly, so knowing all four is what lets you read a claim properly.
- Data sovereignty: the data, its backups, its logs and its metadata sit inside the jurisdiction and are governed by its law alone.
- Operational sovereignty: only vetted people inside the jurisdiction can reach production systems, and every access is logged and reviewable.
- Technical sovereignty: you can run, patch and move the workload without a dependency that reaches outside the jurisdiction, including the control plane.
- Jurisdictional sovereignty: the entity operating the service answers to local courts and cannot lawfully be directed by a foreign parent or government.
Most commercial offerings satisfy the first two convincingly, address the fourth through a local subsidiary, and leave the third largely untouched. That is where sovereign cloud explained by a vendor and sovereign cloud as a reader understands it tend to part company, because technical sovereignty is the layer that depends on chips, firmware, hypervisors and update channels that almost nobody controls domestically.
The layers also fail independently. A national cloud can hold every key locally and still call home for patches. A hyperscaler subsidiary can be perfectly incorporated in your country and still route support tickets through engineers who are not. Ask about each layer separately, because a strong answer on one is routinely offered as an answer to all four.
Why Countries Want Their Own Cloud
Countries want their own cloud for four reasons that usually get collapsed into one. Compliance is the reason that gets published. Legal reach, continuity risk, economic capture and AI compute are the reasons that move the budget.
Reach: Whose Courts Can Compel Your Provider
The first motive is jurisdictional reach: a government hosting citizens’ tax, health or court records with a foreign-owned provider has accepted that a foreign court order against that provider is a live possibility. No amount of local hosting removes it, because the duty attaches to the company, not the building.
What that costs a provider to neutralise is visible in how AWS structured its European Sovereign Cloud, which it opened with a first region in Brandenburg, Germany, in January 2026 according to its own launch announcement. AWS describes a separate parent company with three subsidiaries incorporated in Germany, day-to-day operations controlled only by employees resident in the EU, and EU-resident staff holding independent access to a replica of the source code needed to keep the services running. That is not a data centre decision. It is a corporate one, and it is the shape of the answer when reach is the question.
Continuity: What Happens If the Relationship Ends
The second motive is continuity. Sanctions, export controls, a licensing dispute or a diplomatic rupture can interrupt a commercial relationship that a national tax system or hospital network depends on. A country running core public services on foreign infrastructure has concentrated a political risk into an operational one.
This is why the AWS design promises operation through a connectivity interruption between the European estate and the rest of the world. Customers asked what happens if the parent is cut off, and a contractual answer was not accepted; the answer had to be architectural. Apply the same test to your own contracts. The practical version is to write the migration plan, with timelines, owners and funding, before you sign rather than after, because an exit route costed during a crisis is not an exit route.
Money: Who Captures the Spending
The third motive is economic. Cloud spending is large, permanent and, for most countries, denominated in a foreign currency and paid to a foreign company. A national cloud programme keeps a share of it domestic and builds data centre construction, operator skills and a local supplier base alongside it.
The scale is now material. In a February 2026 spending forecast, Gartner puts worldwide sovereign cloud IaaS spending at US$80 billion in 2026, a 35.6 percent increase on 2025, and names governments as the main buyers ahead of regulated industries and critical infrastructure operators such as energy, utilities and telecommunications. The counterweight is worth stating plainly: domestic providers are usually smaller, so money kept onshore is paid for in narrower service catalogues and slower feature delivery. Both halves of that trade are real.
Compute: Who Gets to Build AI at Scale
The fourth motive is the newest. Training and serving large models needs accelerators, power and data centre capacity, and a country without domestic capacity depends on someone else’s allocation decisions for a capability it now treats as strategic. Sovereign AI programmes are the response, and they extend the same jurisdictional logic to model weights and training runs.
The data side matters as much as the hardware. National language corpora, health records and defence data are often the most valuable training material a country has and the material least permitted to leave it. Understanding how generative AI systems work makes the constraint clearer: if the training data cannot cross a border, the compute has to come to the data, which turns a model-building question into an infrastructure-sovereignty question.
The Four Ways a Sovereign Cloud Actually Gets Built
Sovereign offerings fall into four architectures, and they differ in how high a sovereignty ceiling they can reach and how much operational work they hand you. Microsoft, for example, sells three of the four under one name, offering Sovereign Public Cloud, Sovereign Private Cloud and National Partner Clouds, with named controls including Data Guardian, External Key Management and a Sovereign Landing Zone.
| Model | How it works | Sovereignty ceiling | Real example |
|---|---|---|---|
| Public cloud with sovereign controls | A standard region plus contractual and technical controls: a data boundary, customer-held keys, local support staff | Strong on data and operations, weak on jurisdiction where the parent is foreign | Microsoft Sovereign Public Cloud |
| Dedicated sovereign region | Separate infrastructure run by a locally incorporated operating company inside the provider’s estate | Adds real legal separation, though parent ownership remains upstream | AWS European Sovereign Cloud |
| Partner-operated national cloud | A local company operates the platform under licence and holds the administrative rights and keys | The strongest jurisdictional position among the connected models | Google’s Germany Data Boundary with T-Systems |
| Air-gapped or on-premises | A disconnected deployment in your own or a national data centre | Highest ceiling, and you inherit all of the operational work | Microsoft Sovereign Private Cloud on Azure Local |
If the decision were mine for a typical regulated enterprise rather than a defence ministry, the partner-operated model is the trade I would take today, judged on two criteria: it puts administrative control and encryption keys with a company inside the jurisdiction, and it leaves platform engineering with an operator that does it at scale. Air-gapped deployments buy the last increment of sovereignty at a staffing cost most organisations underestimate badly.
What You Give Up: The Real Cost of Sovereignty
A sovereign environment is a smaller version of the cloud it came from. You trade a narrower service catalogue, delayed features, fewer regions to fail over into and higher unit costs, and the specifics are documented rather than hypothetical.
Google’s Germany Data Boundary by T-Systems documentation, last updated on 11 August 2026, is the clearest published example. It states that if a product is not listed, that product is unsupported and has not met the control requirements, which makes the catalogue an allow-list rather than a deny-list. It requires customer-managed encryption keys on every in-scope service. It constrains resource locations to a single region, europe-west3. And it names the features that are switched off, including Local SSDs and VM suspension on Compute Engine, log-based alerts and saved queries in Cloud Logging, uptime checks and Synthetic Monitor in Cloud Monitoring, and Gemini in BigQuery.
Those specifics generalise into five costs that apply across providers.
- Service catalogue: sovereign estates run allow-lists, so any product not explicitly named is unavailable, including services you already depend on.
- Feature lag: new capabilities ship to the main regions first and reach a sovereign boundary only after a separate control review.
- Region concentration: sovereignty usually means one or two regions, so the disaster recovery story shrinks to what fits inside the border.
- Managed AI: the sovereign catalogue is where managed model services are thinnest, so more of the AI stack becomes yours to run and patch.
- Operational load: customer-managed keys, local approval workflows and restricted vendor support all move work onto your own team.
The second common mistake follows directly from that list: approving a sovereign migration against the marketing page instead of the provider’s service-scope document. The marketing page describes the ambition, the scope document describes the estate you will actually get, and they are rarely the same in the first two years of a sovereign region’s life. Ask for the supported-services list and the location constraint in writing before the architecture review, then diff it against your real service inventory. The gap between those two lists is your migration project, and it is usually larger than the compliance work that prompted it.
How to Test a Sovereign Cloud Claim: Seven Questions
Marketing language around sovereignty has outrun the engineering, so the useful skill is knowing which questions produce a disqualifying answer. Run these seven against any provider making the claim.
- Which legal entity signs the contract, and where is it incorporated? A foreign parent on the signature page limits every other answer.
- Who can reach production, and what is their residency? Follow-the-sun global support means non-resident engineers hold access.
- Who holds the encryption keys, and can the service run without them? If the provider needs the keys to operate, you do not hold them.
- Does the boundary cover logs, metadata, backups and support tickets? Many data boundaries cover payload only, and say so in the fine print.
- Which services are in scope, in writing? You want an allow-list you can compare against your inventory, not a capability brochure.
- What happens if connectivity to the parent is cut? A credible answer describes architecture, not a contractual undertaking.
- What is the exit path, and who controls the data formats? If migration needs the provider’s active cooperation, you have swapped one lock-in for another.
Question two is where most claims fail quietly, because access is granted by role rather than geography in almost every large provider’s default setup, and tightening it is an identity project rather than a hosting one. Pairing a sovereignty review with a zero trust access model is what turns the residency promise into something auditable.
There is now a formal version of this test. The European Commission’s Cloud Sovereignty Framework, published on 1 June 2026, scores providers against criteria grouped into eight objectives, covering strategic, legal and jurisdictional, data and AI, operational, supply chain, technological, security and compliance, and environmental sustainability considerations. It produces a Sovereignty Effectiveness Assurance Level, abbreviated to SEAL, and the Commission applied it in the Cloud III Dynamic Purchasing System tender across 48 criteria. Even outside European public procurement it is the most useful published checklist available, because it was written by a buyer rather than a seller.
Can Any Cloud Be Fully Sovereign?
No commercial cloud is fully sovereign today, and the more careful providers say so. Gartner vice president analyst Douglas Toombs argued in May 2026, in remarks reported by The Register, that only the United States and China make all the technology a fully sovereign cloud requires, which leaves every other country buying part of its stack from abroad.
The dependency chain is long and mostly invisible from a console. Processors and accelerators come from a small number of foreign vendors. Firmware, hypervisors, operating systems and container runtimes are maintained by foreign-led projects and companies. Security patches arrive through update channels that originate outside the jurisdiction. On-premises appliances sold as sovereign options frequently need to call home for licensing, telemetry or fleet management. Each of those is a place where sovereignty leaks, and none of them are fixed by where the rack sits.
The honest framing is that sovereignty is a spectrum of risk reduction rather than a binary product, and that framing changes what you should buy. If the choice were mine, I would take a dedicated sovereign region with customer-held keys and a funded, rehearsed exit plan over an air-gapped estate the organisation cannot properly staff. The first reduces the risks that actually materialise, which are legal orders and supplier disputes. The second optimises for a scenario most organisations will never face while adding operational fragility they will face every quarter.
Regional Cloud Providers: The Middle Option
Regional cloud providers are companies that operate cloud infrastructure within one country or bloc and are incorporated there, competing on locality, support and price predictability rather than catalogue breadth. For many organisations they are the practical middle ground between a hyperscaler region and a national sovereign programme, because jurisdiction comes as a default rather than as a paid tier.
What you gain is straightforward: the operating company sits under the same law as you, support is staffed locally and named, pricing tends to be flatter and easier to forecast, and latency to domestic users is short. What you pay for it is equally straightforward. Catalogues are narrower, managed AI services and GPU availability are thinner and concentrated in one or two sites, documentation is less complete, and the ecosystem of third-party tooling that assumes a hyperscaler API is smaller.
There is a detail here worth knowing before you treat the two categories as rivals. Several hyperscaler sovereign offerings are operated by regional providers rather than competing with them, which is exactly what Google’s German data boundary arrangement with T-Systems is. European providers such as OVHcloud and Scaleway sell directly and also supply the local operating capability that a hyperscaler needs to make a sovereignty claim stand up. Evaluate a smaller provider the way you would evaluate any concentrated supplier dependency, using the same risk-based scoring discipline you would apply to a technical vulnerability, because supplier concentration and unpatched software fail in similar ways.
Do You Actually Need a Sovereign Cloud?
Most organisations do not. Sovereign cloud exists for workloads where a foreign legal order, a service cut-off or a failed regulatory audit would be an existential event, and for everyone else a narrower set of controls achieves the same practical outcome for considerably less money.
- Government, defence and national infrastructure: a sovereign environment is usually mandated by policy rather than chosen on merit.
- Banking, insurance and healthcare: check whether your regulator requires sovereignty or only residency, because they are different obligations with very different costs.
- Suppliers to the public sector: you may inherit the requirement through a procurement framework rather than through law, often at short notice.
- Multinationals with conflicting obligations: the real problem is mapping jurisdictions per data class, and one sovereign region rarely solves it.
- Startups, SMEs and SaaS teams: usually not, and the honest alternative is cheaper and faster to implement.
For that last group, four controls cover most of what enterprise customers and privacy regulators actually ask for: pin storage and processing to a named region, hold your own encryption keys, publish an accurate subprocessor list, and keep a documented, costed exit plan. That combination answers a due-diligence questionnaire without rebuilding your platform, and it is what you should reach for before anyone proposes a migration.
Frequently Asked Questions
Is an AWS or Azure region in my country already a sovereign cloud?
No, not by default. A region inside your country delivers data residency. Sovereignty additionally requires that the operating entity, the staff with production access and the encryption keys all sit under your jurisdiction. AWS and Microsoft both sell separate sovereign offerings precisely because a standard in-country region does not meet that bar.
Is a sovereign cloud more secure than a normal cloud?
Not inherently. It changes who can legally compel access and who can technically reach the systems, which is a governance improvement rather than a security one. The underlying platform is usually the same technology. A sovereign environment with weak identity controls is less secure than a well-run public cloud tenancy with strong ones.
Which countries have their own sovereign cloud programmes?
The most developed sit in the European Union, where the Commission has published a formal scoring framework, and in France and Germany, whose national certification schemes predate it. China operates the largest domestic cloud market of its kind. India, Saudi Arabia and Australia have each introduced localisation rules that push regulated workloads onshore.
Does a sovereign cloud cost more to run?
Usually yes, for three reasons that compound. Smaller infrastructure footprints carry less economy of scale, restricted catalogues push you toward self-managed alternatives that need staff, and the compliance work is continuous rather than one-off. Ask for unit pricing and an operational headcount estimate before comparing anything against your current bill.
What is sovereign AI, and how is it different?
Sovereign AI applies the same jurisdictional logic to model training and inference, keeping the compute, the training data and the model weights under national control. It matters most where national language corpora, health records or defence data cannot legally leave the country, and where a government treats access to accelerators as a strategic resource.
What to Do With This
Start with your data rather than with a vendor. Classify what you hold by the worst outcome if a foreign court, a regulator or a sudden service cut-off reached it, and most of it will turn out not to need a sovereign environment at all. For the fraction that does, run the seven questions above against whoever you are considering and insist on the supported-services list in writing before anyone draws an architecture. Sovereign cloud explained without the marketing is a spectrum of risk reduction with real costs attached, and data sovereignty is a legal outcome you can partly reach through contracts, key management and regional cloud providers without moving your whole estate. The one step worth taking this week is writing down which of your workloads could not survive a thirty-day loss of your current provider.
