Sovereign EU Cloud Regions: The 9-Point Checklist a Compliance Team Should Run Before Switching
A practical 9-point checklist for compliance and platform teams choosing between a sovereign EU cloud region (AWS European Sovereign Cloud, Microsoft Cloud for Sovereignty, Google/S3NS, OVHcloud, Scaleway, StackIt, T-Systems) and a standard AWS or Azure EU region - what sovereignty actually changes, which rules force it, what it costs, and what it breaks.
A standard AWS or Azure EU region already keeps customer data at rest in Europe. A sovereign region changes who operates it, which legal entity answers a foreign legal request, whether every operator is an EU resident, who holds the keys, and whether support data, logs and telemetry leave the EU.
Run nine checks before switching: (1) operating legal entity, (2) operational access and break-glass approval, (3) key control, (4) metadata, logs, telemetry and support-ticket flows, (5) certification scope, (6) service catalogue parity, (7) exit and portability, (8) foreign-government requests, (9) total cost including a second deployment target.
GDPR does not require a sovereign region. Chapter V governs transfers, and the EU-US Data Privacy Framework adequacy decision of 10 July 2023 still stands. The real forcing functions are national and sectoral: ANSSI SecNumCloud, BSI C5, Spain's ENS, Italy's ACN qualification, France's HDS, and specific tender clauses.
The catalogue gap stalls more sovereign migrations than the price premium does. The AWS European Sovereign Cloud launched with more than 90 services and an uplift of about 15% over Frankfurt, according to an independent teardown. Inventory your managed-service dependencies first.
Sovereignty is a per-workload decision, so most teams end up with a split estate. Portable tooling that deploys into your own AWS, GCP, Azure or Scaleway account, or onto your own Kubernetes cluster, keeps one workflow across both estates.
Most teams asking us for a sovereign region do not need one, and most teams that genuinely need one are checking the wrong things. This is a checklist for compliance and platform teams deciding between a sovereign EU cloud region and a standard AWS or Azure EU region.
We talk to CTOs and compliance leads every week, and two confusions come up constantly. People treat "EU region" and "sovereign cloud" as synonyms, and they assume GDPR forces sovereignty. Neither is true, and both lead to expensive decisions. Below: what actually changes, the nine checks, how the providers compare, which rules bite, what it costs, and how to keep the decision reversible.
What actually changes when you move from a standard AWS or Azure EU region to a sovereign region?
A standard AWS eu-west-1 or Azure West Europe region already stores customer data at rest in the EU, so a sovereign region does not move your bytes. It changes who operates the region, which legal entity answers a foreign legal request, whether every operator is an EU resident, and whether support data, logs and telemetry stay inside the boundary.
I use three layers for the rest of this article:
Data sovereignty: where the bytes are stored and processed.
Operational sovereignty: who can technically touch them, from which country, under which approval workflow.
Technical sovereignty: who controls the keys, the control plane, and the source of the stack.
Standard regions already cover a lot of the first layer. AWS committed to EU data residency controls in its Digital Sovereignty Pledge (November 2022). Microsoft completed its EU Data Boundary in February 2025, covering customer data, pseudonymised personal data and professional services data such as logs and support case notes. Microsoft also publishes the documented exceptions: remote access by staff outside the boundary, security operations data, support case titles and escalations, and some service metrics. Read that page before you assume a standard region covers operational sovereignty.
The legal concern is jurisdiction, and disk location barely matters to it. The US CLOUD Act (18 U.S.C. § 2713) lets US authorities compel a provider to disclose data "regardless of whether such communication, record, or other information is located within or outside of the United States." FISA Section 702 is the other statute in play; Congress extended it twice in April 2026, to 12 June 2026 (Pub. L. 119-87), so check its current status with counsel. On the EU side, GDPR Article 48 says a foreign court order is only recognised if it rests on an international agreement. We cover the details in our FISA 702 explainer.
My blunt position: for most workloads, a standard EU region plus customer-held keys and a tight access model is legally sufficient. Sovereignty becomes mandatory when a named rule, a sector regulator or a tender clause says so. The compliance team's job is to find that clause, with its article number, before anyone signs.
Which nine things should a compliance team check before committing to a sovereign region?
Check these nine items, in this order, and paste them straight into your decision document:
Operating legal entity and ownership
Operational access and break-glass approval
Key management
Metadata, logs, telemetry and support-ticket data flows
Certification scope
Service catalogue and roadmap parity
Exit and portability
Handling of foreign-government requests
Total cost, including the second deployment target
Teams skip #4 and #6 most often, and those are the two that blow up after signature.
#4 is where data leaves the boundary. Customer data is usually well fenced. Telemetry, security logs, support tickets and professional-services notes are where the exceptions live, and Microsoft's own transfer documentation shows how long that list gets even inside a completed boundary. Demand a written data-flow map per service. Retrofitting this after migration is the hardest fix on the list.
#6 decides whether the migration ships. List every managed service your workloads depend on: Postgres, Kafka, search, object storage, GPU instances, AI endpoints, CI/CD. Mark each one as available on day one, roadmapped with a date, or absent, and treat "planned" as absent. When the AWS European Sovereign Cloud opened, tecRacer's teardown found no GPU instances, Bedrock limited to Amazon Nova models, CloudFront planned for the end of 2026, and CodeBuild and CodePipeline planned for Q1 2027.
A business case that compares compute prices and nothing else
Score each item red, amber or green. Every red item needs a named owner before the migration decision goes to a vote.
How do sovereign EU regions compare to standard AWS and Azure EU regions?
Sovereign regions buy jurisdictional and operational isolation and pay for it in service breadth, availability zones, feature lag and usually price. Standard AWS and Azure EU regions are a lawful home for most GDPR-covered workloads, and that is where most European workloads run today.
The market concentration explains why this question matters. Synergy Research Group puts Amazon, Microsoft and Google at 70% of the European cloud market in 2024, with European providers holding steady at about 15%. Demand for alternatives is rising: Gartner forecasts European sovereign cloud IaaS spending to grow from $6.9 billion in 2025 to $12.6 billion in 2026.
In the table below, the first row is the baseline you probably already have. "Not published" means I could not find the figure on a primary source.
Offering
Operating entity
Operational access
Certifications (verify per region and service)
Catalogue and AZs
Cost posture
Standard AWS or Azure EU region (baseline)
US parent's EU subsidiaries
Global support with EU residency controls; Microsoft documents remote-access exceptions
Provider-published C5, ISO 27001/27017/27018 and HDS for many services
Google services; hosted option on Google Distributed Cloud air-gapped
Quote-based
Delos Cloud
SAP-backed German entity on Microsoft technology
Built for German public sector
Not verified from a primary source
Public-sector scope
Quote-based
Your own Kubernetes on EU-operated hardware
You
You
Yours to obtain
Whatever you build and run
Lowest vendor premium, highest operational burden
Three hybrid patterns show up most in practice: partner-operated regions such as S3NS and T-Systems, disconnected or air-gapped deployments such as Google Distributed Cloud, and your own Kubernetes cluster on EU-operated hardware. The last one gives you maximum control and maximum on-call duty. For a deeper provider breakdown, see our sovereign cloud pricing comparison and the SecNumCloud comparison of Numspot, OVHcloud and Scaleway.
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure or Scaleway account - or your existing Kubernetes cluster, sovereign or on-prem. Start deploying in under 10 minutes.
Which regulations actually force a sovereign cloud region, and which ones do not?
GDPR alone does not require a sovereign cloud region, and it does not even require EU data residency. The rules that genuinely force sovereignty are national and sectoral: ANSSI SecNumCloud for sensitive French state data, BSI C5 and the Delos route for parts of the German public sector, Spain's ENS, Italy's ACN qualification, and specific tender clauses.
GDPR.Regulation (EU) 2016/679 regulates transfers in Chapter V (Articles 44 to 50) and contains no residency obligation. The EU-US Data Privacy Framework adequacy decision of 10 July 2023 remains in force. The General Court dismissed the Latombe challenge (T-553/23) on 3 September 2025, and an appeal (C-703/25 P) is pending before the Court of Justice.
DORA.Regulation (EU) 2022/2554 has applied since 17 January 2025. Article 28(3) requires a register of information, Article 28(8) requires documented exit strategies, Article 29 covers concentration risk and Article 30 sets key contractual provisions. All of that is a portability requirement. None of it names a sovereign region. More in our DORA platform guide.
NIS2.Directive (EU) 2022/2555 Article 21(2)(d) requires supply chain security for essential and important entities. It sets risk-management duties and no residency mandate.
EU Data Act.Regulation (EU) 2023/2854 has applied since 12 September 2025. Chapter VI (Articles 23 to 31) governs switching between cloud providers, and Article 29 removes switching charges entirely from 12 January 2027. That feeds directly into checklist item #7.
EUCS. The EU cloud certification scheme still has not been adopted. The Commission's Cybersecurity Act revision proposal of January 2026 acknowledges it stalled over sovereignty questions. Do not plan around EUCS yet.
Health data spaces: the EHDS Regulation (EU) 2025/327, in force since 26 March 2025 and generally applicable from 26 March 2027.
Defence and intelligence classifications, plus national public-sector procurement frameworks.
The practical rule: write down the requirement with its article or scheme reference. Without that line, you are buying sovereignty on vibes, and the premium stays on your bill long after the vibe passes.
What does a sovereign EU cloud region actually cost, in price and in engineering time?
The list-price premium is usually the smaller cost. The expensive part is running a second, less-featured deployment target: self-hosting the managed services that do not exist there, losing discount parity, and doubling your IaC, CI/CD, runbooks and on-call surface.
Smaller regions cost more per unit for structural reasons: less capacity, less amortisation, separate control planes and EU-only staffing. tecRacer measured a consistent 15% uplift over Frankfurt across EC2, S3, RDS and Lambda in the AWS European Sovereign Cloud. That is a third-party estimate from the AWS calculator, so rerun it with your own SKUs.
Discount programs need checking per offer. AWS does offer Savings Plans in the European Sovereign Cloud, priced in euros, but it is a separate partition, so do not assume commitments you hold in eu-central-1 carry over. Ask the same question about Azure reservations and Google committed-use discounts for every sovereign tier.
Managed-service substitution is headcount. Self-hosting Kafka, search, a vector database or GPU-backed inference means operators, upgrades and someone on call at 3 a.m.
Cost dimension
Standard EU region
Sovereign region
List price
Baseline
Typically higher; about 15% for AWS ESC versus Frankfurt per tecRacer
Discount programs
Full Savings Plans, reservations and committed-use discounts
Varies by offer; existing commitments may not transfer
Managed-service gaps
Rare
Missing services become self-hosted workloads with their own on-call
Operational overhead
One estate
Two IaC stacks, two pipelines, two runbook sets, two alerting setups, two evidence trails
Exit and egress
Data Act Article 29 caps switching charges, then removes them from 12 January 2027
Same rules apply, but proprietary sovereign-only services raise the real exit cost
There is a FinOps argument for bring-your-own-cloud here. When your deployment platform runs inside your own cloud accounts, the bill, the commitments and the negotiated discounts stay in your name in both estates. You keep one cost view and avoid a reseller markup.
How do you keep workloads portable between a sovereign region and a standard AWS or Azure region?
Standardise on Kubernetes, OCI images and open-protocol managed services, so a sovereign region becomes one more deployment target and your architecture stays the same. If moving a representative environment to a second region takes more than a day, your exit strategy exists only on paper.
Portability is the only hedge that survives a changing legal landscape, because adequacy decisions get challenged, statutes lapse and get renewed, and certification schemes stall. Four design rules hold up:
Keep your developer workflow's control plane independent of the cloud you deploy into, so region choice stays a configuration decision.
Prefer portable building blocks: Kubernetes, OCI images, Postgres and Redis-compatible services, S3-compatible object storage, OpenTelemetry. Flag every proprietary service with no equivalent in the sovereign region as a migration blocker.
Run the exit test every quarter. Redeploy a representative environment into a second region or a bare Kubernetes cluster and time it. DORA Article 28(8) expects evidence. Our portability drill guide walks through it.
Accept the split estate. Regulated workloads go to the sovereign or EU-only region, everything else stays in a standard region, and developers get one experience across both.
This is where Qovery fits. Qovery deploys into your own cloud account on AWS, GCP, Azure or Scaleway, or onto your own existing Kubernetes cluster, including self-managed, sovereign and on-prem clusters. Git-push deployments, preview environments per pull request, per-environment RBAC, environment auto-stop and managed cluster upgrades work the same way in both estates. A split estate does not have to mean two platforms or a dedicated DevOps hire per estate. We show the pattern in running the same Kubernetes workloads on an EU sovereign cloud and AWS.
The limits matter for this audience. Qovery does not make a region sovereign, does not issue or hold your certifications, and does not replace legal review. Certifications belong to the cloud provider and to you. Qovery keeps the deployment layer portable, so the legal decision stays reversible.
How do I set up a portable deployment target with Qovery from Claude Code or Cursor?
Install the Qovery Agent Skills once, optionally add the Qovery MCP Server for read-only inspection, then ask your agent in plain language to deploy into the target cloud account or Kubernetes cluster. The agent presents every infrastructure change for your approval.
Install the skills globally for Claude Code, Cursor, Codex, OpenCode or Gemini CLI. This installs qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview and qovery-terraform:
Add the MCP Server to Claude Code. It authenticates with OAuth and is read-only by default, so the agent can inspect what exists without changing it:
SHELL
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242
Enable write access only when you explicitly want it. This also requires enabling write access in the Qovery Console:
SHELL
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242
Then ask in plain language: "deploy this service to my Scaleway account with Qovery" or "connect my existing EU Kubernetes cluster and create a preview environment." The agent proposes each infrastructure change and waits for your approval. Setup details are in the AI agent quickstart and on the Claude Code integration page.
Frequently asked questions
What should a compliance team check before picking a sovereign EU cloud region over a standard AWS or Azure region?
Check nine items: the operating legal entity, operational and break-glass access, key management, metadata and telemetry flows, certification scope, service catalogue parity, exit and portability, handling of foreign-government requests, and total cost. Demand documentary evidence for each, such as corporate structure diagrams, data-flow maps and region-specific certificates. Telemetry flows and catalogue parity are the two most often skipped and the two most likely to cause problems after signature.
Does GDPR require a sovereign cloud region, or is a standard AWS or Azure EU region enough?
GDPR does not require a sovereign region or even EU data residency. Chapter V (Articles 44 to 50) regulates transfers to third countries, and the EU-US Data Privacy Framework adequacy decision of 10 July 2023 remains in force, with an appeal pending at the Court of Justice. For most GDPR workloads, a standard EU region with customer-held keys and strict access controls is enough. Sector rules such as SecNumCloud, HDS or a tender clause can still require more.
What is the difference between data residency, data sovereignty, operational sovereignty and technical sovereignty?
Data residency is a commitment about where data is stored, and data sovereignty extends that to where it is processed and which law governs it. Operational sovereignty covers who can technically access systems, from which country, and under which approval workflow. Technical sovereignty covers who controls the encryption keys, the control plane and the source of the software stack. Standard hyperscaler EU regions cover residency well and the other layers only partly.
Which EU sovereign cloud providers exist in 2026, and which certifications do they actually hold?
The main offers are the AWS European Sovereign Cloud, Microsoft's sovereign cloud offers and EU Data Boundary, Google Cloud via S3NS, OVHcloud, Scaleway, STACKIT, T-Systems Sovereign Cloud and Delos Cloud. Verified examples include S3NS's SecNumCloud 3.2 qualification (December 2025), OVHcloud's SecNumCloud-qualified Hosted Private Cloud, Bare Metal Pod and SNC Cloud Platform, and STACKIT's C5 Type 2 attestation. Always confirm that a certificate names your region and your services, using ANSSI's catalogue or the provider's compliance page.
How much more expensive is a sovereign EU cloud region than a standard EU region?
An independent tecRacer analysis found the AWS European Sovereign Cloud about 15% more expensive than Frankfurt across EC2, S3, RDS and Lambda at launch. Other sovereign offers are often quote-based, so you have to price them with your own workloads. The bigger cost is usually engineering time: self-hosting services missing from the sovereign catalogue and running a second deployment estate.
Does DORA or NIS2 require a sovereign cloud region?
No, neither DORA nor NIS2 requires a sovereign cloud region. DORA (Regulation (EU) 2022/2554) requires a register of information, exit strategies and concentration-risk assessment under Articles 28 to 30, which makes it a portability requirement. NIS2 (Directive (EU) 2022/2555) Article 21(2)(d) requires supply chain security. Both push you to document and test your ability to leave a provider, without naming where your workloads must run.
How do you keep workloads portable between a sovereign region and a standard AWS, GCP or Azure region?
Build on Kubernetes, OCI images and open-protocol services such as Postgres, Redis-compatible stores, S3-compatible storage and OpenTelemetry. Keep your deployment workflow independent of the cloud you deploy into, and test an exit every quarter by redeploying a representative environment elsewhere and timing it. A platform such as Qovery, which deploys into your own cloud account or Kubernetes cluster, keeps one workflow across both estates.
Morgan co-founded Qovery and leads engineering. He writes about Kubernetes architecture, DevOps best practices, and building resilient infrastructure at scale.
Next step
Ship faster on infrastructure you control.
Qovery gives your team self-service deployments on your own AWS, GCP, Azure or Scaleway account - or your existing Kubernetes cluster, sovereign or on-prem. Start deploying in under 10 minutes.
