What actually makes a cloud “sovereign” — the country where the servers sit, or the country whose laws can reach them? That question sounds academic until a regulator asks it during a procurement review. Then it decides which vendor you sign with.
By 2027, all three hyperscalers will sell you something called sovereign cloud. The marketing pages look similar. The architectures underneath are not. This article walks through where AWS, Microsoft, and Google genuinely diverge, which decisions you must lock in early, and the traps that catch teams halfway through migration.
Why sovereignty is a legal problem before it is a technical one
Most teams start with data residency: keep the data in Frankfurt or Stockholm and the job is done. That is the wrong starting point. Residency is about where bits are stored. Sovereignty adds legal jurisdiction, who operates the hardware, and who can be compelled to hand data over.
The legal backdrop explains the urgency. The US CLOUD Act of 2018 allows US authorities to compel US-based providers to disclose data they control, even when it sits on European soil, as the text of the CLOUD Act on Congress.gov sets out. Europe’s counterweight is GDPR Chapter V on international transfers, reinforced by the Schrems II ruling, in which the Court of Justice of the EU struck down the Privacy Shield framework; the full judgment in Case C-311/18 is worth reading before any architecture workshop.
Two more rules shape 2027 roadmaps. The EU Data Act, Regulation (EU) 2023/2854, applies from 12 September 2025 and includes cloud-switching and interoperability obligations, so the official EU Data Act text now belongs in your exit-planning documents. The NIS2 Directive adds supply-chain and cloud-risk duties for essential and important entities; the NIS2 Directive text is the reference for what auditors will ask about your provider chain.
There is also a certification question still in motion. ENISA’s EU Cloud Services Scheme (EUCS) introduces sovereignty levels on top of security levels, but its final adoption status has wobbled through revisions. The ENISA EUCS page is the place to check the current draft before you promise a customer a “sovereign-certified” platform.
How the three architectures actually differ
Strip away the branding and three distinct models appear.
AWS separates sovereignty into a dedicated construct: a sovereign cloud operated inside a specific jurisdiction, with local entities and local personnel in the loop. Architecturally, that means a separate control plane footprint, local identity and billing, and a narrower service catalogue than the commercial regions. If your design assumes every AWS service exists everywhere, the sovereign region will humble you.
Microsoft takes a layered approach with Cloud for Sovereignty, a policy and architecture layer on top of Azure Government and public Azure regions. It leans on Azure Policy, confidential computing, and customer-managed keys to enforce data-boundary rules. The advantage is continuity: skills, tooling, and most services carry over. The risk is that sovereignty becomes a configuration exercise rather than a physical separation, which some regulators accept and others do not.
Google Cloud offers both Google-operated and partner-operated sovereign options, with data residency, local control, and sovereign controls delivered through Assured Workloads. The partner-operated variant is the interesting one for regulated buyers, because a local operator can change the answer to “who can touch this hardware?”
| Dimension | AWS | Microsoft | Google Cloud |
|---|---|---|---|
| Sovereignty model | Dedicated sovereign cloud in-jurisdiction | Policy layer on existing regions plus government clouds | Google-operated or partner-operated options |
| Control mechanism | Separate footprint, local entities | Azure Policy, confidential computing, customer-managed keys | Assured Workloads, data residency controls |
| Service breadth in sovereign scope | Reduced versus commercial regions | Broad, since it builds on Azure | Varies by operating model |
| Best fit | Strict jurisdictional separation | Teams already deep in Microsoft tooling | Buyers wanting operator choice |
Data residency versus operator sovereignty
A useful test: ask each vendor who can technically access a running virtual machine’s memory, and under which legal order. The answers expose the real architecture.
Hardware-level isolation has become the common denominator. Confidential computing encrypts memory so that even the operator cannot read it while workloads run, using technologies such as AMD SEV-SNP, Intel TDX, and Arm CCA. The Confidential Computing Consortium publishes the specifications and threat models behind these claims, and reading them will sharpen your questions. Confidential computing does not erase jurisdiction, but it narrows the set of people who could misuse access.
The practical split looks like this:
- If the regulator demands that no foreign-national personnel can operate the stack, only a partner-operated or locally operated model clears the bar.
- If the regulator accepts foreign operation with strong technical and contractual controls, a policy-layer model is cheaper and faster.
- If the regulator has not decided yet, design for the strictest plausible outcome and keep the option open.
That third case is more common than vendors admit. Many procurement teams in 2026 are buying optionality, not a final answer.
The architecture decisions to lock in early
Sovereignty projects fail on details that seemed minor in the design phase. These are the decisions worth settling before the first workload moves.
- Identity and key custody. Decide whether encryption keys live in a local HSM under local law, and whether the hyperscaler’s global identity plane is allowed to authenticate your administrators. A global identity provider can quietly reintroduce the jurisdictional problem you just paid to remove.
- Service catalogue scope. Build against the sovereign region’s actual service list, not the commercial one. Teams routinely design around a managed service that does not exist in sovereign scope, then rebuild under deadline pressure.
- Network and peering boundaries. Confirm that traffic between your sovereign environment and the commercial cloud crosses a controlled boundary, and document it for auditors.
- Support and break-glass access. Write down who can access production during an incident, from which country, under whose instruction. This is the single most scrutinised paragraph in any sovereignty assessment.
- Exit and portability. The EU Data Act’s switching obligations make exit plans a legal requirement, not a nice-to-have. Test a restore into a second environment before you need it.
That last point connects to a broader discipline. Teams that treat sovereignty as one pillar of a wider operating model do better than teams that bolt it on. If you are running workloads in more than one hyperscaler, the habits in this guide to a multi-cloud framework for running workloads across AWS, Azure and Google map cleanly onto sovereign designs, especially around consistent policy and identity.
Where costs and skills quietly diverge
Sovereign environments cost more. That is not a secret, but the reasons matter for budgeting. Smaller regions mean less economy of scale, dedicated staffing means higher support tiers, and confidential computing carries a performance tax on some workloads. Comparing headline prices across providers is close to useless without modelling these factors, and the same is true of compute-heavy workloads: the analysis in this breakdown of AWS vs Azure vs Google Cloud GPU pricing in 2026 shows how quickly list prices stop predicting real bills.
Skills are the other hidden line item. A team fluent in Azure Policy can enforce data-boundary rules quickly. The same team moving to a dedicated sovereign footprint faces new networking, new IAM boundaries, and a thinner managed-service layer. Budget for retraining as well as migration.
Monitoring deserves early attention too. Sovereign regions often expose fewer native telemetry services, so teams end up building cross-environment observability themselves. Approaches for keeping multi-cloud metrics tracked across AWS, Azure and Google Cloud apply directly here, because a sovereign estate is effectively a second cloud with its own quirks. (Cloud computing)
Common mistakes and what actually works in practice
The same failure patterns repeat across organisations.
Mistake one: treating sovereignty as a region choice. Picking a local region and changing nothing else fails the operator-access test almost every time.
Mistake two: assuming the certification is final. Building a compliance claim on a draft scheme is risky while EUCS sovereignty levels remain unsettled. Track the drafts and keep contractual language flexible.
Mistake three: forgetting the commercial side. Sovereignty discussions often start with legal and security teams and reach finance last, after architecture is frozen. Bring cost modelling in at week one.
Mistake four: skipping the audit rehearsal. Run a mock assessment using NIS2 supply-chain questions and GDPR transfer questions before a regulator does. The gaps you find are cheap to fix early and expensive later.
What works, in practice, is a tiered design: classify workloads by sovereignty requirement, place the strictest in a dedicated or partner-operated environment, keep the rest in commercial regions, and connect the two through a documented, auditable boundary. That structure survives regulatory change better than a single all-in bet, and it keeps the door open if requirements tighten. The wider case for this approach, including who genuinely benefits, is set out in this look at who actually gains from sovereign cloud benefits.
For organisations weighing the general platform question alongside sovereignty, the broader comparison in AWS vs Azure vs Google Cloud in 2026 provides useful context on service maturity and regional coverage. And because audit outcomes depend on documentation as much as architecture, the practices in these sovereign cloud best practices that survive audit are worth adopting before the first review, not after. (NIST SP 800-145: The NIST Definition of Cloud Computing)
Conclusion
The AWS, Microsoft, and Google sovereign offerings are not three flavours of the same product. They represent three answers to the same legal question: who can be compelled to hand over your data, and who can physically touch the machine holding it. AWS leans toward jurisdictional separation, Microsoft toward policy-enforced boundaries inside familiar infrastructure, and Google toward a choice of operator. None of those answers is universally right. The teams that get this right in 2027 will be the ones that start from the legal requirement, test operator access honestly, lock in identity and key custody early, and design an exit they have actually rehearsed. Sovereignty is an architecture decision with a legal deadline attached, and the deadline does not move because the migration ran late.
FAQ
What is the difference between data residency and data sovereignty?
Data residency is about location: where data is stored and processed. Data sovereignty goes further, covering legal jurisdiction, the nationality of the operator, and who can be compelled to disclose data. A workload can be resident in one country and still not sovereign, which is why regulators increasingly ask about operator access rather than server location.
Does the US CLOUD Act really affect European cloud customers?
It can. The CLOUD Act allows US authorities to compel US-based providers to disclose data they control, even when it is stored abroad. That is a key driver behind European sovereign cloud demand. Whether it applies in a specific case depends on the provider’s structure and the data in question, so legal advice matters more than vendor marketing.
Is EUCS certification final yet?
Not reliably. The EU Cloud Services Scheme has gone through multiple drafts, and the sovereignty levels have been contested. Organisations should check the current status on ENISA’s pages before making certification claims in contracts, and should keep contractual language flexible enough to absorb changes.
Which vendor is best for strict operator-sovereignty requirements?
It depends on the requirement’s strictness. If no foreign-national personnel may operate the stack, a partner-operated or locally operated model is usually the only fit. If foreign operation is acceptable with strong technical and contractual controls, a policy-layer model is typically faster and cheaper. Test the requirement against each vendor’s actual operating model rather than the brochure.
How does confidential computing fit into a sovereign architecture?
Confidential computing encrypts memory so the operator cannot read workloads while they run. It reduces the number of people who could misuse access and strengthens the technical side of a sovereignty claim. It does not change legal jurisdiction on its own, so treat it as one layer among several, not a complete answer.
What should be in a sovereign cloud exit plan?
At minimum: a tested restore into a second environment, documented data formats and APIs, identified dependencies on provider-specific services, and a timeline that meets the EU Data Act’s switching expectations. An exit plan that has never been rehearsed is a document, not a capability.
