Europe’s cloud market hit an inflection point in January 2026. Amazon Web Services flipped the switch on its European Sovereign Cloud, a physically and legally separate partition of AWS built entirely inside the EU. Microsoft and Google had already been building their own answers for years, but none of the three hyperscalers agreed on what “sovereign” should actually mean. The result is three fundamentally different products wearing the same marketing label, and enterprise buyers in regulated industries are struggling to tell them apart.
This comparison breaks down AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty (paired with the EU Data Boundary), and Google Cloud Sovereign Controls (delivered through partners like S3NS and T-Systems) across legal structure, compliance certifications, pricing, regional footprint, and real deployment examples. If you’re evaluating a sovereign cloud migration for 2026, this is the data you need before signing a contract.
Why Sovereign Cloud Suddenly Matters in 2026
Sovereign cloud stopped being a niche compliance checkbox somewhere around mid-2025. Germany’s BSI made its C5 (Cloud Computing Compliance Criteria Catalogue) certification mandatory for healthcare organizations and parts of public administration starting in July 2025, and the C5:2025 update added new requirements covering container management, software supply chain risk, and post-quantum cryptography readiness. That single regulatory shift pushed sovereign cloud from “nice to have” to “contract requirement” for a large slice of the European public sector and regulated industries.
Layer on top of that the ongoing debate around the EU Cloud and AI Development Act and the Digital Omnibus simplification package, both of which touch how European entities can rely on non-EU cloud infrastructure for sensitive workloads, and you get a market where every major hyperscaler has scrambled to publish a sovereignty roadmap. The catch: AWS, Microsoft, and Google chose three structurally different paths to get there, and understanding those differences matters more than any marketing slide.
A European Cloud Services Certification Scheme (EUCS) intended to standardize sovereignty requirements across the entire EU has been in draft for more than four years without formal adoption, which is exactly why national frameworks like Germany’s C5, France’s SecNumCloud, and Spain’s ENS have become the de facto standards enterprises actually get evaluated against. That fragmentation is the backdrop for everything in this comparison.
What “Sovereign Cloud” Actually Means (and Why the Three Providers Disagree)
Before comparing specifics, it helps to separate the three competing definitions of sovereign cloud circulating in 2026:
- Structural separation — a physically and legally distinct cloud, operated by EU-resident staff, under an EU-incorporated parent entity, immune from foreign legal reach. This is AWS’s model.
- Policy and configuration layer — a framework of guardrails, data-residency commitments, and landing zones applied on top of the existing global cloud fabric. This is Microsoft’s model.
- Partner-operated environment — a national telecom or defense contractor licenses the cloud’s technology stack and runs it independently under local law. This is Google’s model via S3NS in France and T-Systems in Germany.
None of these approaches is objectively “more sovereign” in isolation. Each trades off service breadth, operational complexity, and legal assurance differently, and the right answer depends heavily on what your regulator or industry actually requires.
AWS European Sovereign Cloud: The Independent Partition
AWS first floated the idea in October 2023 and committed to investing €7.8 billion by 2040 to build it, targeting a launch in Germany’s Brandenburg state by the end of 2025. AWS hit that internal deadline closely, announcing general availability of the AWS European Sovereign Cloud on January 15, 2026, describing it as “a new, independent cloud for Europe, entirely located within the EU, and physically and logically separate from other AWS Regions.”
What makes AWS’s approach distinct is the legal wrapper around it. The sovereign cloud runs under a dedicated entity, AWS European Sovereign Cloud GmbH, governed independently with its own Security Operations Center. AWS committed that only EU-resident personnel physically located in the EU control day-to-day operations, including data center access, technical support, and customer service, and the company says it is gradually transitioning the operating team to be staffed exclusively by EU citizens located in the EU. During the transition period, AWS is running a blended team of EU residents and EU citizens rather than flipping a single switch.
The first region sits in Brandenburg, Germany, with AWS already signaling expansion through sovereign Local Zones in Belgium, the Netherlands, and Portugal. AWS describes the offering as a “fully-featured cloud offering the expansive service portfolio and capabilities that customers use across AWS today,” though its own launch blog on initial available services makes clear that not every AWS service shipped on day one — core compute, storage, networking, and security services were prioritized, with more specialized managed services following on a rolling basis through 2026.
Microsoft Cloud for Sovereignty and the EU Data Boundary
Microsoft took the opposite architectural bet. Rather than build a separate cloud, it layered sovereignty controls on top of the Azure regions it already operates across Europe. The company began phasing in the EU Data Boundary on January 1, 2023, for EU and EFTA customers, and announced completion of Phase 3 in February 2025, which extended the residency commitment to cover support-related and Microsoft-generated data, not just customer content.
By June 2025, Microsoft had consolidated its various sovereignty efforts under a single umbrella brand, Microsoft Sovereign Cloud, spanning public cloud, private deployments, and partner-operated environments. Independent sovereignty analyses circulating in the industry describe Microsoft Cloud for Sovereignty as generally available but explicitly not a separate cloud product — it’s a framework of sovereign landing zones, policy controls, and configuration guidance built entirely on standard Azure, Microsoft 365, Dynamics 365, and Power Platform infrastructure.
The EU Data Boundary itself spans all 27 EU member states plus Liechtenstein, Iceland, Norway, and Switzerland, backed by data centers in countries including Austria, Belgium, Denmark, Finland, France, Germany, Greece, Ireland, Italy, the Netherlands, Norway, Poland, Spain, and Sweden. Customers commonly deploy sovereignty-sensitive workloads to specific regions like West Europe (Netherlands), North Europe (Ireland), France Central (Paris), Germany West Central (Frankfurt), and Sweden Central. Because this model reuses existing infrastructure rather than standing up a parallel cloud, Microsoft’s pitch is operational continuity: customers get sovereignty guardrails without re-architecting for a separate platform, and Microsoft markets EU Data Boundary commitments as included in standard product terms at no additional cost.
Google Cloud Sovereign Controls, S3NS, and T-Systems
Google’s approach leans hardest into the partner-operated model. Rather than run a sovereign entity itself, Google Cloud Sovereign Controls licenses the underlying technology to independent, locally controlled operators who run the actual infrastructure under their own national jurisdiction.
In France, that operator is S3NS, a subsidiary controlled by Thales and governed under French law. S3NS began offering “Local Controls” in 2023 as an intermediate sovereignty step, then moved to its flagship product, PREMI3NS Trusted Cloud, built on Google Cloud Dedicated infrastructure. On December 19, 2025, S3NS announced that PREMI3NS received SecNumCloud 3.2 qualification from ANSSI, France’s cybersecurity agency — widely regarded as the strictest trusted-cloud label in Europe, short of classified defense systems. Thales itself became the platform’s first strategic customer, and a joint SAP-S3NS announcement in April 2026 confirmed SAP RISE private cloud edition would run on PREMI3NS for critical workloads by the second half of 2026. Roughly 30 early-adopter customers tested PREMI3NS before its general availability.
In Germany, the equivalent operator is T-Systems, the Deutsche Telekom subsidiary running “Sovereign Cloud powered by Google Cloud” out of German data centers. T-Systems structures the offering in graduated tiers — a baseline “Sovereign Controls” variant already available, with “Supervised” and “Hosted” variants promising deeper sovereignty planned for later rollout. Google also opened a Sovereign Cloud Hub in Munich in November 2025, paired with a Security and Privacy Engineering Hub, signaling a longer-term European engineering commitment beyond the partner arrangements.
Full Specs Comparison: AWS vs Microsoft vs Google Sovereign Cloud
The table below lines up the three offerings across the dimensions that actually determine procurement decisions.
| Dimension | AWS European Sovereign Cloud | Microsoft Cloud for Sovereignty | Google Cloud Sovereign Controls (S3NS / T-Systems) |
|---|---|---|---|
| Model | Separate, independently governed cloud partition | Policy/configuration framework on standard Azure | Partner-operated environment on licensed Google tech |
| GA date | January 15, 2026 | Framework GA; EU Data Boundary Phase 3 complete Feb 2025 | PREMI3NS (France) GA Dec 19, 2025; T-Systems variant already live |
| Legal entity | AWS European Sovereign Cloud GmbH (EU-incorporated) | Microsoft Corporation (existing global entity) | S3NS (Thales-controlled, French law); T-Systems (Deutsche Telekom, German law) |
| Operating staff | Transitioning to EU-resident, EU-citizen-only operations | Microsoft’s existing global operations team | Local staff under S3NS/T-Systems, independent of Google |
| Physical separation from global cloud | Yes — physically and logically separate | No — same infrastructure, added guardrails | Yes — separate operator, licensed Google stack |
| First region / hub | Brandenburg, Germany | Existing EU regions (Netherlands, Ireland, France, Germany, Sweden, and more) | France (S3NS); Germany (T-Systems); Munich Sovereign Cloud Hub |
| Planned expansion | Sovereign Local Zones in Belgium, Netherlands, Portugal | Broader rollout across existing EU Data Boundary regions | “Supervised” and “Hosted” T-Systems tiers pending |
| Top compliance certification | EU local-law governance; C5 (shared AWS baseline) | GDPR, EU Cloud Code of Conduct, national ENS/LOPD alignment | SecNumCloud 3.2 (PREMI3NS), Cloud de Confiance label |
| Service parity at launch | Core services first; specialized services rolling out through 2026 | Near-full parity — same Azure service catalog | Curated subset; PREMI3NS has the broadest catalog among SecNumCloud-qualified clouds |
| Pricing structure | Standard AWS pricing plus European Sovereign Cloud addendum | Standard Azure/365 SKUs; sovereignty add-on at no extra list cost | Custom/enterprise pricing set by S3NS and T-Systems |
| Named 2025–2026 customer | Partner solutions launching on platform (unnamed early customers) | Broad EU/EFTA enterprise and public-sector base | Thales (first strategic customer); SAP RISE on PREMI3NS (H2 2026) |
| Best-fit sovereignty tier | Maximum legal/operational separation | Minimal disruption, broad service breadth | Strictest national trusted-cloud label (France) |
Compliance Certifications: GDPR, C5, SecNumCloud, and ENS
Every major hyperscaler holds baseline certifications like GDPR-aligned processing terms and Germany’s BSI C5, which AWS, Microsoft, Google, SAP, STACKIT, OVHcloud, and IONOS all carry as of 2025–2026. C5 became a practical floor rather than a differentiator once it turned mandatory for German healthcare and public-sector workloads in July 2025, and the C5:2025 revision folded in new controls for container security, software supply chains, and post-quantum cryptography preparedness.
Where the three providers actually diverge is in national trusted-cloud labels that go beyond the EU-wide baseline. France’s SecNumCloud, administered by ANSSI, sits at the top of that ladder, and as of December 2025 only S3NS’s PREMI3NS has secured SecNumCloud 3.2 qualification among the three hyperscaler-linked offerings compared here, explicitly marketed as providing immunity from non-European extraterritorial legal reach. Spain’s ENS (Esquema Nacional de Seguridad) and its LOPD data-protection framework are referenced specifically in Microsoft’s EU Data Boundary documentation for customers operating out of Spanish regions. AWS, meanwhile, leans on its EU governance structure and trust-service-provider status rather than claiming a distinct national sovereignty certification for its European Sovereign Cloud specifically.
An EU-wide replacement for this patchwork, the European Cloud Services Certification Scheme (EUCS), has been stuck in draft for more than four years, which is precisely why enterprises evaluating sovereign cloud in 2026 still need to check country-specific certifications rather than assuming a single “EU sovereign” stamp covers every jurisdiction they operate in.
Pricing Breakdown: What Sovereign Cloud Actually Costs
None of the three providers publishes a fully itemized sovereign-cloud price list the way they do for standard compute and storage, but the structural differences below shape how the total cost of ownership plays out.
| Provider | Base pricing model | Sovereignty premium | Notable cost driver |
|---|---|---|---|
| AWS European Sovereign Cloud | Standard AWS regional pricing | Governed by a separate European Sovereign Cloud contractual addendum; no published surcharge, but capacity is newer and regionally constrained | Fewer available services at launch can force higher-cost workarounds for gaps |
| Microsoft Cloud for Sovereignty | Standard Azure / Microsoft 365 / Dynamics 365 SKUs | Marketed as included at no additional list cost for EU Data Boundary residency | Implementation and sovereign landing zone consulting can add material services cost |
| Google Cloud via S3NS (PREMI3NS) | Custom/enterprise pricing set by S3NS, independent of Google’s public list | Priced as a distinct trusted-cloud product, typically at a premium over standard Google Cloud | SecNumCloud-qualified capacity is scarcer, and demand from regulated French sectors is rising fast |
| Google Cloud via T-Systems | Custom pricing set by T-Systems per sovereignty tier | Tiered pricing across “Sovereign Controls,” “Supervised,” and “Hosted” variants | Higher sovereignty tiers (not yet fully available) are expected to command a larger premium |
The practical takeaway for budget planning: Microsoft’s model is the cheapest to adopt in raw list-price terms because it reuses infrastructure you may already be paying for, while AWS and the Google-partner offerings both involve either newer, capacity-constrained regions or a distinct commercial relationship with a third-party operator, both of which tend to push effective costs higher until the market matures.
Independent Assessments and Analyst Commentary
Sovereignty analyses circulating among European cloud advisors in late 2025 and early 2026 converge on a similar framing, even without a single standardized benchmark to rank the three offerings numerically. Microsoft Cloud for Sovereignty is consistently described as a pragmatic, lower-friction approach precisely because it does not require re-platforming onto new infrastructure — the tradeoff is that it does not create the kind of physically and legally separate boundary that a “hard sovereignty” buyer in defense or intelligence-adjacent sectors might require.
AWS’s European Sovereign Cloud and S3NS’s PREMI3NS both get flagged as the two offerings closest to that harder sovereignty bar: AWS through its EU-only governance and staffing commitments, and S3NS through its SecNumCloud 3.2 qualification and Thales-controlled legal structure explicitly designed to resist non-European extraterritorial legal reach. Where the two diverge is scope — AWS’s model applies EU-wide across its full service catalog as it expands, while SecNumCloud 3.2 qualification is specific to France and to the curated service set that ANSSI has actually certified.
A recurring theme in these assessments is that C5 and similar national frameworks should be treated as the current minimum bar for regulated workloads until the EU formally adopts EUCS, rather than waiting for a single pan-European standard that may still be years away.
Real-World Deployments and Case Studies
Concrete, named customer deployments are still thin across all three offerings, which is typical for products that only reached broad general availability between late 2025 and early 2026. The examples that are public show where each model is finding early traction:
- Thales on PREMI3NS — Thales itself became the first strategic customer on S3NS’s SecNumCloud 3.2-qualified PREMI3NS platform, a natural fit given Thales controls S3NS.
- SAP RISE on PREMI3NS — SAP and S3NS jointly announced in April 2026 that SAP’s RISE private cloud edition will run critical workloads on PREMI3NS by the second half of 2026, targeting French and EU-regulated enterprise customers.
- Early-adopter cohort on PREMI3NS — roughly 30 organizations tested the platform in a structured early-access program before its December 2025 SecNumCloud qualification and public GA.
- AWS partner solutions — AWS has publicly listed a range of partner solutions set to launch on the European Sovereign Cloud, though individual enterprise customer names had not been disclosed as of this writing.
- Broad EU/EFTA enterprise base on Microsoft’s EU Data Boundary — because the EU Data Boundary applies automatically to in-scope Microsoft 365, Dynamics 365, and Azure workloads for EU/EFTA tenants, its “customer base” is effectively every existing European Microsoft enterprise customer rather than a distinct opt-in cohort.
- T-Systems Sovereign Cloud clients — T-Systems markets its Google-powered sovereign tiers primarily to German public-sector and regulated-industry clients, consistent with Deutsche Telekom’s existing government relationships, though the company has not published a detailed named-customer list for the Google-powered tiers specifically.
Technical Limitations You Need to Know Before Migrating
Marketing pages for all three offerings emphasize “full cloud functionality,” but the fine print tells a more nuanced story.
AWS says its European Sovereign Cloud offers the same expansive service portfolio customers use across standard AWS, but its own security blog on initial available services makes clear the launch set was deliberately scoped to core compute, storage, networking, and security services first, with newer or more specialized managed services following through 2026. If your workload depends on a recently launched AWS service, check availability in the sovereign partition before you commit.
Microsoft’s framework largely inherits the full Azure and Microsoft 365 service catalog since it runs on the same infrastructure, but the specific set of services formally in scope for EU Data Boundary guarantees is narrower than “everything Microsoft sells.” Certain support tooling, telemetry pipelines, and global-only services may still involve data flows that require additional configuration to fully align with sovereignty requirements.
Google’s partner-operated model has the most explicit tiering of limitations. S3NS’s earlier “Local Controls” offering was always positioned as an intermediate step that does not target SecNumCloud certification, distinct from the fully qualified PREMI3NS. T-Systems similarly structures its Google-powered sovereign cloud into “Sovereign Controls,” “Supervised,” and “Hosted” variants, with only the baseline tier broadly available and the higher-assurance tiers still rolling out. In every partner-operated case, you get a curated subset of the full Google Cloud managed-service catalog, not the entire platform.
Common Migration Mistakes That Delay Sovereign Cloud Projects
Every sovereign cloud rollout tracked in industry commentary through 2025 and into 2026 runs into a similar set of avoidable delays. The first is treating “sovereign” as a single checkbox rather than a spectrum. Teams that assume any EU region automatically satisfies a SecNumCloud or C5 requirement discover late in procurement that residency alone does not equal the legal separation their regulator actually demands, forcing a second, more expensive migration once the gap surfaces.
The second common mistake is underestimating dependency sprawl. A workload that looks self-contained often pulls in a managed database, a queueing service, an identity provider, and a handful of AI or analytics APIs, and each of those has to be separately verified against the target sovereign environment’s service catalog. Because AWS European Sovereign Cloud, Microsoft’s EU Data Boundary scope, and the S3NS/T-Systems tiers all launched or expanded within the past 12 to 18 months, service parity gaps are still common enough that a dependency audit needs to happen before, not during, migration.
The third mistake is skipping the identity and support-data layer. Microsoft’s own EU Data Boundary rollout took more than two years to reach Phase 3, specifically because extending residency guarantees to support tickets, telemetry, and Microsoft-generated operational data proved more complex than moving customer content. Any team assuming “storage is in the EU, so we’re done” is very likely missing a residency gap somewhere in the support or observability stack, regardless of which provider they choose.
Sovereign Cloud vs a Broader Multi-Cloud Strategy
A question that comes up constantly in procurement discussions is whether adopting a sovereign cloud offering means abandoning a multi-cloud strategy altogether. In practice, the two are not mutually exclusive, and most enterprises evaluating AWS, Microsoft, and Google’s sovereign products in 2026 are not trying to pick a single winner for their entire infrastructure footprint.
The more common pattern looks like this: a company keeps its primary workloads on whichever standard cloud region already fits its cost and service requirements, then layers in a sovereign environment specifically for the subset of data and applications that trigger a hard regulatory requirement. A German public-sector client, for example, might run its general SaaS infrastructure on standard Azure or AWS while routing citizen data subject to C5 requirements into AWS European Sovereign Cloud or a T-Systems Google-powered tier. A French defense contractor might do the same with S3NS’s PREMI3NS reserved for classified-adjacent workloads while everything else stays on standard Google Cloud.
This segmented approach avoids two expensive failure modes: over-provisioning sovereign capacity for workloads that never needed it, and under-provisioning it for the handful of workloads where a compliance failure would actually be catastrophic. The tradeoff is added architectural complexity — data classification, network segmentation, and identity federation all need to account for which workloads live where, and audit trails need to prove the segmentation actually holds under review. Teams that skip that governance layer tend to be the ones that end up quietly running regulated data on the wrong side of the boundary without realizing it until an audit catches it.
Migration Guide: Moving Workloads to a Sovereign Cloud
Sovereign cloud migration is less about lift-and-shift tooling and more about mapping regulatory requirements to the right architectural model before you touch infrastructure. Here’s a practical sequence:
- Identify your actual regulatory trigger. Determine whether your requirement comes from GDPR data-residency obligations, a national framework like C5, ENS, or SecNumCloud, or a sector-specific mandate (defense, healthcare, critical infrastructure). This determines which of the three models even qualifies.
- Map workloads to sensitivity tiers. Not every workload needs the strictest sovereignty tier. Segment applications into “must be fully sovereign,” “needs EU residency only,” and “no special requirement” before planning any migration.
- Check service availability in the target sovereign environment. Cross-reference your architecture’s dependencies (managed databases, AI services, specific compute instance types) against what’s actually live in AWS European Sovereign Cloud, Azure’s EU Data Boundary scope, or your chosen S3NS/T-Systems tier — gaps here are the most common migration blocker.
- Validate the legal and operational structure with your compliance team. Confirm whether your regulator requires physical/legal separation (favoring AWS or S3NS) or whether a policy-and-residency framework on existing infrastructure is sufficient (favoring Microsoft).
- Plan for data residency at the identity and support layer, not just storage. Microsoft’s phased EU Data Boundary rollout took until February 2025 to fully cover support-related data — a reminder that sovereignty commitments often extend beyond where your primary data lives.
- Pilot with a non-critical workload first. Given how recently all three offerings reached broad GA (late 2025 through early 2026), run a pilot migration before committing production, regulated workloads.
- Negotiate contractual sovereignty terms explicitly. Review AWS’s European Sovereign Cloud addendum, Microsoft’s EU Data Boundary trust documentation, or your S3NS/T-Systems contract to confirm the legal guarantees match what your compliance team actually needs on paper, not just in marketing copy.
A basic CLI check across all three platforms can confirm which region or sovereign boundary a resource is actually deployed in, which is worth automating into your compliance reporting from day one:
# AWS - confirm region for a resource in the sovereign partition
aws ec2 describe-instances --region eu-central-2
--query "Reservations[].Instances[].{ID:InstanceId,Region:Placement.AvailabilityZone}"
# Azure - confirm data residency region under the EU Data Boundary
az resource show --ids /subscriptions/<sub-id>/resourceGroups/<rg>
--query "location"
# Google Cloud (via a sovereign partner project) - confirm resource location
gcloud compute instances list --project=<s3ns-or-tsystems-project>
--format="table(name,zone)"5 Use Cases and Which Sovereign Cloud Fits Best
Because the three models solve sovereignty differently, the right pick depends heavily on the specific use case:
- Defense and national security-adjacent workloads: S3NS’s PREMI3NS, given its SecNumCloud 3.2 qualification and Thales-controlled structure explicitly built for immunity from non-European extraterritorial law. Best fit for French entities specifically; other member states will need to check their own national equivalent.
- Regulated healthcare and public administration in Germany: AWS European Sovereign Cloud or T-Systems’ Google-powered sovereign tiers, both aligned with Germany’s mandatory C5 requirements and offering in-country operational control.
- Enterprises already deep in the Microsoft 365 / Dynamics ecosystem: Microsoft Cloud for Sovereignty and the EU Data Boundary, since it avoids re-platforming and extends residency guarantees across the tools already in daily use.
- Multinational EU operations needing consistent data residency without a hard cutover: Microsoft’s framework again, because its policy-layer model scales across all EU/EFTA regions Microsoft already operates rather than requiring migration to a single new partition.
- Startups and mid-market SaaS companies selling into regulated EU sectors: A hybrid approach is common here — core infrastructure on standard cloud regions with specific regulated workloads carved out to AWS European Sovereign Cloud or a Google sovereign partner tier, minimizing cost while still satisfying customer procurement requirements.
Pros and Cons of Each Sovereign Cloud Model
AWS European Sovereign Cloud
- ✅ Physically and legally separate cloud with dedicated EU governance
- ✅ Clear €7.8 billion, 15-year investment commitment signals long-term regional buildout
- ✅ Familiar AWS APIs and tooling reduce the learning curve for existing AWS customers
- ❌ Newer platform (GA January 2026) with narrower service parity at launch
- ❌ Single initial region (Brandenburg) limits geographic redundancy until expansion completes
Microsoft Cloud for Sovereignty
- ✅ Broadest immediate service parity since it runs on existing Azure infrastructure
- ✅ No re-platforming required for current Microsoft 365 / Azure customers
- ✅ EU Data Boundary residency included at no additional list cost
- ❌ Not a physically separate cloud — softer sovereignty boundary for buyers requiring hard legal separation
- ❌ Lacks a distinct national trusted-cloud certification like SecNumCloud
Google Cloud Sovereign Controls (S3NS / T-Systems)
- ✅ PREMI3NS holds SecNumCloud 3.2, the strictest trusted-cloud label available in France
- ✅ Operator independence (Thales, Deutsche Telekom) provides strong legal separation from Google
- ❌ Curated, narrower service catalog compared to standard Google Cloud
- ❌ Pricing and availability fragmented by country and operator, with no single unified Google sovereign product
- ❌ Higher-assurance tiers (T-Systems “Supervised” and “Hosted”) are still rolling out, not yet broadly available
The Verdict: Which Sovereign Cloud Should You Choose in 2026
There isn’t a single winner here, and any vendor claiming otherwise is oversimplifying a genuinely fragmented market. If your compliance requirement demands the strictest legal separation available today, S3NS’s PREMI3NS is the most credentialed option on paper thanks to its SecNumCloud 3.2 qualification, but it’s currently scoped to France. If you need EU-wide coverage with the least operational disruption and you’re already running on Microsoft’s stack, Cloud for Sovereignty and the EU Data Boundary get you there fastest and at the lowest incremental cost. If you want a fully independent cloud partition with a long-term regional investment behind it and you’re comfortable with a newer platform still filling out its service catalog, AWS European Sovereign Cloud is the most ambitious structural bet of the three.
The practical reality for most multinational enterprises in 2026 is a hybrid strategy: keep the bulk of workloads on standard cloud regions for cost and service breadth, and carve out the specific regulated subset — often less than a quarter of total infrastructure — onto whichever sovereign offering matches the strictest requirement in your most regulated market. For a broader look at how the three hyperscalers stack up on market share and pricing outside the sovereignty conversation, that comparison covers the baseline numbers this article builds on. Expect this comparison to keep shifting through 2026 and 2027 as EUCS adoption debates continue and each provider races to close service-parity gaps against its own standard cloud.
Teams weighing physical separation should also study how the same three providers approach hybrid and distributed cloud deployments, since the governance patterns overlap heavily with sovereign cloud design. And once a sovereign environment is live, the next step is usually locking down account structure with a proper landing zone, plus a hard look at secrets management and continuous compliance monitoring to keep the sovereignty guarantees from drifting once real workloads land.
Frequently Asked Questions
What is the difference between sovereign cloud and a regular cloud region?
A regular cloud region only guarantees where your data is physically stored. Sovereign cloud adds legal and operational guarantees on top of that — such as EU-only staff, an EU-incorporated operating entity, or independent operator control — designed to limit the reach of foreign laws and government access requests over your infrastructure and data.
Is AWS European Sovereign Cloud fully available now?
Yes, AWS announced general availability on January 15, 2026, with its first region in Brandenburg, Germany. However, AWS’s own documentation on initial available services confirms the launch scope prioritized core compute, storage, networking, and security services, with additional services rolling out through 2026.
Does Microsoft have a separate sovereign cloud like AWS?
No. Microsoft Cloud for Sovereignty is a framework of policy controls, sovereign landing zones, and residency guarantees (the EU Data Boundary) applied to its existing Azure, Microsoft 365, Dynamics 365, and Power Platform infrastructure, rather than a physically separate cloud environment.
What is SecNumCloud and why does it matter for Google Cloud customers?
SecNumCloud is a French cybersecurity qualification administered by ANSSI, widely regarded as the strictest trusted-cloud standard in Europe outside of classified defense systems. S3NS’s PREMI3NS, built on Google Cloud Dedicated infrastructure, received SecNumCloud 3.2 qualification in December 2025, making it the highest-assurance Google-linked sovereign offering currently available.
Which sovereign cloud is cheapest?
Microsoft’s model tends to be the least expensive to adopt in list-price terms because it runs on infrastructure many enterprises already use, with EU Data Boundary residency included at no additional cost. AWS and the Google-partner offerings (S3NS, T-Systems) both involve either newer capacity-constrained regions or a separate commercial relationship with a third-party operator, which typically raises effective costs.
Can I use more than one sovereign cloud provider at the same time?
Yes, and many multinational enterprises do. A common pattern is running standard workloads on regular cloud regions while routing specific regulated data sets — defense contracts in France, healthcare data in Germany — to whichever sovereign offering matches that jurisdiction’s strictest requirement, rather than standardizing on a single sovereign provider globally.
Will the EU eventually require a single sovereign cloud standard?
That’s the intent behind the European Cloud Services Certification Scheme (EUCS), but it has remained in draft for more than four years without formal EU-wide adoption as of 2026. Until it’s adopted, national frameworks like Germany’s C5, France’s SecNumCloud, and Spain’s ENS remain the practical standards enterprises are evaluated against.
Does using a sovereign cloud guarantee full compliance with GDPR?
No. Sovereign cloud offerings support GDPR compliance by strengthening data residency and reducing exposure to foreign legal access, but GDPR compliance also depends on how you configure access controls, data processing agreements, and consent management within whichever cloud you choose. A sovereign cloud is an enabler, not a substitute for a proper compliance program.
How long does a typical sovereign cloud migration take?
There is no fixed industry-wide timeline, and it varies heavily by workload complexity and how many dependencies need to be re-mapped to the sovereign environment’s service catalog. As a reference point, Microsoft’s own EU Data Boundary rollout ran in phases from January 2023 through February 2025 to fully cover customer, support, and operational data. Enterprise workload migrations are typically scoped in months rather than weeks once dependency mapping, compliance sign-off, and a pilot phase are factored in.