7 best sovereign cloud options for EU public sector software vendors in 2026

The sovereignty question in EU public tenders has moved from "where is the data stored" to "who can legally be compelled to hand it over", and the three hyperscaler answers to that second question are structurally different in a way most comparisons get wrong. European-headquartered providers now hold about 15% of their own cloud market while AWS, Microsoft and Google together hold 70% (Synergy Research Group, H1 2025), and that imbalance is exactly why procurement teams keep writing sovereignty clauses that a software vendor then has to satisfy. Gartner expects European sovereign cloud IaaS spending to jump from $6.9 billion in 2025 to $12.6 billion in 2026 (via The Register, Feb 2026), so this is not a niche clause you can wait out.

Here is the ranked answer, with the three distinctions stated up front so you can act on them before reading the rest:

• AWS European Sovereign Cloud is a physically and logically separate partition, run by an EU-headquartered legal entity staffed by EU residents, with its own root of trust, support and billing.
• Google Cloud Sovereign Controls are configurable controls (Assured Workloads, Access Transparency, Access Approval, External Key Manager) applied to standard Google Cloud regions, with partner-operated (S3NS, T-Systems) and air-gapped (Google Distributed Cloud) tiers above.
• Microsoft Cloud for Sovereignty is a governance, policy and transparency layer over existing commercial Azure regions plus the EU Data Boundary, with Delos Cloud and Bleu as the higher partner-operated tier.

Match the option to the tier your tender actually names, verify the certification against the real list before you bid, and remember that the expensive problem is rarely picking one cloud. It is running the same product in three because three customers each demanded a different one.

What does "sovereign cloud" actually mean in an EU public sector tender?

In EU public tenders, "sovereign cloud" means one of three stackable things, and most procurement documents specify only one of them explicitly. That is why vendors routinely over-buy or under-buy.

• Data sovereignty is where data is stored and processed. A residency clause ("all data at rest and in processing must remain within the EU/EEA") is cleared by any EU region from any provider.
• Operational sovereignty is who can technically access the data, from which country, and under whose approval. An "EU-personnel-only support" clause rules out follow-the-sun support desks outside the EU.
• Legal or jurisdictional sovereignty is whether a non-EU jurisdiction can compel disclosure. A "CLOUD Act / FISA 702 insulation" clause is the hardest to satisfy and the one escalating fastest.

This hits a software vendor differently from an enterprise buying for itself. Your government customer is the data controller under GDPR Article 28, you are the processor, so your architecture has to satisfy their data processing agreement and their tender, not your own risk appetite. You inherit their clause whether or not it matches how you would run things.

The frameworks that keep appearing in RFPs, and what each one tests in one line: GDPR Art. 28 and Chapter V (Art. 44-49) govern the processor relationship and international transfers; the EU Cloud Code of Conduct is a GDPR-compliance attestation for cloud services; Germany's BSI C5 tests operational security controls with an auditor's attestation; France's SecNumCloud (ANSSI) tests security plus protection from non-EU law; Spain's ENS and Italy's ACN qualification set national public-sector tiers; and NIS2 and DORA add resilience obligations for adjacent regulated sectors.

The clause most tenders are waiting on is EUCS, the EU Cybersecurity Certification Scheme for Cloud Services. As of 2026 it is still a draft candidate scheme, not adopted as an implementing act, and the controversial "immunity from non-EU law" sovereignty requirements were removed in the ENISA draft of March 2024 and remain politically contested (cep, April 2025). Do not write a bid assuming EUCS exists as binding law yet.

The reason operational sovereignty keeps climbing in RFPs is Schrems II (CJEU Case C-311/18, 16 July 2020), which invalidated Privacy Shield. The successor EU-US Data Privacy Framework was adopted on 10 July 2023 and is still in force in 2026: the annulment action Latombe v Commission (T-553/23) was dismissed by the EU General Court on 3 September 2025, upholding it. The Framework surviving does not stop buyers from writing stricter sovereignty clauses than GDPR adequacy requires, and many do.

Say the quiet part plainly: sovereignty does not make your application compliant, portable, or cheap to run in three places. It constrains where and by whom your workload runs. Everything else is still your job.

Definitions you can lift

• Data sovereignty: data is stored and processed within a defined jurisdiction (for example, the EU/EEA).
• Operational sovereignty: only authorised personnel, in a defined jurisdiction and under defined approval, can technically access the system.
• Legal / jurisdictional sovereignty: no foreign legal order can compel the operator to disclose or hand over the data.
• Air-gapped: the environment runs with no connection to the public internet or the provider's global cloud.

How did we rank the sovereign cloud options?

We ranked each option on six criteria that decide whether a software vendor can both win an EU public sector tender and then actually deliver on it.

1. Sovereignty tier reached: residency only, EU-operated personnel, a separate or partner-operated EU legal entity, or fully air-gapped.
2. Certifications held today (SecNumCloud, BSI C5 Type 1 or Type 2, ENS, EU Cloud CoC, ISO 27001/27017/27018) versus certifications announced or targeted. We label targeted as targeted, with a date.
3. Service parity inside the boundary: how much of the standard catalogue (managed Kubernetes, managed Postgres, object storage, AI/ML) exists inside the sovereign boundary.
4. Kubernetes story: whether there is a managed control plane, what it costs per cluster per hour, and who performs version upgrades and add-on lifecycle.
5. Multi-jurisdiction effort: whether you can run the same product in two or three sovereign environments without forking your deployment pipeline.
6. Commercial model: whether you keep your own cloud account, your own committed-spend discounts and your own billing relationship, which matters when a public buyer insists on contracting the infrastructure directly.

The exclusion rule: we left out options with no EU public sector reference customer and no published certification roadmap, and we excluded resellers that do not operate their own control plane.

Which sovereign cloud should an EU public sector software vendor choose in 2026?

Choose AWS European Sovereign Cloud for operational sovereignty on a hyperscaler stack, Google Cloud Sovereign Controls when you need standard Google services with configurable guardrails, Microsoft Cloud for Sovereignty when the buyer already runs Microsoft 365 and Entra ID, OVHcloud or Scaleway when the clause says SecNumCloud or no-US-parent, STACKIT, IONOS or Open Telekom Cloud for the German public sector, and Google Distributed Cloud air-gapped when the environment must be disconnected.

Map the clause to the shortlist before you shortlist the vendor:

Decision shortcut: if the clause names a nationality or SecNumCloud, go European or partner-operated; if it demands EU-only operations on a hyperscaler stack, go AWS European Sovereign Cloud; if the buyer lives in Microsoft 365, go Azure sovereign and shorten the security review.

Is AWS European Sovereign Cloud the right choice for EU public sector workloads?

AWS European Sovereign Cloud is the strongest hyperscaler answer when a tender demands operational sovereignty, because it is a physically and logically separate partition operated by an EU-headquartered legal entity with EU-resident personnel, its own root of trust, its own support organisation and its own billing. It is the wrong choice if you need day-one parity with the full commercial catalogue or a SecNumCloud-qualified host.

Precisely what it is: a new cloud partition (aws-eusc), not a region inside the commercial partition, that reached general availability on 14 January 2026 with its first region in Brandenburg, Germany. AWS has committed EUR 7.8 billion to it. It is run by AWS European Sovereign Cloud GmbH under German law, with EU-resident managing directors, a dedicated European security operations centre, and an independent European root certificate authority, so it can keep operating even if connectivity to the rest of AWS is cut.

The honest caveats: the service catalogue at launch is narrower than the commercial EU regions and is still broadening, your existing commercial-region accounts and Savings Plans do not extend into it, it is a separate IAM realm, and cross-partition data transfer is not an internal network hop. Vendors who need SecNumCloud for a French tender today, or whose product depends on a service not yet in the partition, should not pick it.

Inside the partition, Amazon EKS gives you a managed control plane at $0.10 per cluster per hour on standard support ($0.60 per cluster per hour once a version moves to extended support), but node pools, version upgrades, add-on lifecycle, IAM, networking and observability still land on your team. The managed control plane is the easy 20% of running Kubernetes in production.

On the CLOUD Act, be fair to both sides. AWS commits in its design-approach whitepaper to review each government request individually, redirect the requester to the customer, notify the customer, and "use all legally valid efforts to challenge any request that conflicts with the law of the European Union." Critics counter that because the ultimate parent is Amazon.com, Inc., a US court could in theory compel disclosure of data in the group's "possession, custody, or control", and that no court has ruled a hyperscaler's EU-subsidiary data categorically beyond reach (analysis). A separate EU entity with EU-resident staff raises the bar materially; whether it removes extraterritorial reach entirely is still argued.

What do Google Cloud Sovereign Controls actually give you, and when are they enough?

Google Cloud sells sovereignty as a configurable spectrum rather than one separate cloud, which makes it the most flexible pick when you need standard Google services with guardrails bolted on, and the weakest pick when the clause names the operator's nationality. The spectrum runs from EU data residency, to Assured Workloads for the EU, to Sovereign Controls, to partner-operated clouds, to Google Distributed Cloud air-gapped at the top.

Each tier enforces something different. Residency pins data at rest to Europe. Sovereign Controls for the EU add Access Transparency and Access Approval (you see and consent to admin access), Cloud External Key Manager (keys held outside Google's infrastructure), and support routed to EU personnel located in the EU. The partner tier puts a local operator between you and Google. The air-gapped tier removes the internet entirely.

S3NS, the Thales-majority joint venture with Google Cloud in France, had its PREMI3NS offering qualified SecNumCloud 3.2 by ANSSI on 17 December 2025, covering IaaS, PaaS and CaaS. In Germany, T-Systems operates a Sovereign Cloud powered by Google Cloud as data trustee, scoped to the europe-west3 region with customer-managed encryption keys and roughly 60 supported Google Cloud products.

The genuine strength: GKE is the most mature managed Kubernetes, and Autopilot removes node management entirely by billing only for the CPU, memory and storage your Pods request. That matters a lot when you have no dedicated DevOps engineer. GKE charges $0.10 per cluster per hour, with one free zonal or Autopilot cluster and $74.40 of monthly credit per billing account.

The honest caveats: sovereignty here is configured per folder and project, so a misconfiguration is your liability, not Google's. Assured Workloads restricts the usable service list, and any service not on the supported-products list "is unsupported and has not met all regional, regulatory, or sovereign controls required." A buyer whose tender requires an operator with no US parent is not cleared by configurable controls alone. Then only a partner-operated or European provider qualifies.

When do Azure sovereign regions and Microsoft Cloud for Sovereignty win the tender?

Azure sovereign offerings win when the government buyer already runs Microsoft 365 and Entra ID, because identity, productivity and your application then land inside one compliance story and one security review. Be precise about what it is: Microsoft Cloud for Sovereignty is a governance, policy and transparency layer over existing commercial Azure regions plus the EU Data Boundary, not a separate partition like AWS European Sovereign Cloud.

What Microsoft actually ships: the EU Data Boundary, whose final phase completed on 26 February 2025 by bringing professional services data and technical support data into EU/EFTA storage, covering Azure, Microsoft 365, Dynamics 365 and Power Platform; plus Sovereign Public Cloud with sovereign landing zones, a policy baseline and transparency logs; plus Azure confidential computing; plus partner-operated clouds.

The higher partner-operated tier is where real isolation sits. Delos Cloud is operated by an SAP subsidiary for German public administration, aligned with BSI C5 and IT-Grundschutz requirements. Bleu, a 50/50 joint venture of Orange and Capgemini running the Microsoft stack in France, is in the SecNumCloud qualification process and now targets qualification for the end of 2026. Do not describe Bleu as qualified yet; ANSSI lists it as in process.

The practical tender advantage is real: your app sitting next to the customer's existing Entra tenant removes an integration objection from the RFP and shortens the security review, and in a sector where the European Commission itself ran on Microsoft 365 that incumbency is common.

The caveat, stated bluntly: Microsoft Cloud for Sovereignty does not create a separate legal partition. Microsoft's own docs describe the Sovereign Public Cloud as "using existing Microsoft hyperscale cloud regions." This is the single most misunderstood point in this comparison, and most published comparisons get it wrong. Partner-operated clouds buy you the separation, but they trade release cadence and service parity for it: new Azure services reach Delos and Bleu well after the commercial regions, not alongside them.

On AKS, the control plane is managed at $0.10 per cluster per hour on the Standard tier (the Free tier has no financially backed SLA), but version upgrades, node pools and add-on sprawl stay with your team.

Should you pick a European provider like OVHcloud, Scaleway, STACKIT or IONOS instead?

If the tender requires SecNumCloud, a German operator under BSI C5, or simply "no provider with a US parent company", a European provider is the only option that clears the clause, and OVHcloud, Scaleway, STACKIT and IONOS all now run credible managed Kubernetes with free or near-free control planes.

• OVHcloud is a French company listed on Euronext Paris. Its Bare Metal Pod offering is SecNumCloud 3.2 qualified as of March 2025, its Managed Kubernetes Service runs a free control plane, and it offers managed Postgres, S3-compatible storage and serverless AI endpoints.
• Scaleway, part of France's Iliad Group, runs Kubernetes Kapsule with a free control plane, managed PostgreSQL, S3-compatible storage, H100 GPU instances and an EU-hosted generative AI API. Its SecNumCloud qualification is in process, not yet granted. Scaleway is also supported natively by Qovery.
• STACKIT (Schwarz Group, Germany) holds a BSI C5 Type 2 attestation from August 2024 and runs STACKIT Kubernetes Engine at roughly EUR 0.10 per cluster per hour. IONOS Cloud (IONOS Group SE, listed in Frankfurt) holds a BSI C5 Type 1 attestation and offers Managed Kubernetes with a free control plane. The Type 2 versus Type 1 difference matters: Type 2 tests that the controls actually operated over a period, not just that they were designed.
• Open Telekom Cloud (T-Systems, Deutsche Telekom; now rebranding to T Cloud Public) holds BSI C5 Type 2 and is a standard option across German federal and Länder procurement, available through the GovTech Deutschland framework, with Cloud Container Engine for Kubernetes, managed databases and S3-compatible storage. It does not hold SecNumCloud; it is built for German, not French, clauses.
• 3DS Outscale (Dassault Systèmes) was the first operator qualified SecNumCloud 3.2, in December 2023, and runs OUTSCALE Kubernetes Service. Cloud Temple holds the broadest SecNumCloud 3.2 portfolio of the smaller French operators, spanning IaaS, PaaS, object storage and bare metal. Both appear in French public bids and are worth naming.

The honest caveats: narrower managed-service catalogues, fewer regions and availability zones, weaker AI/ML services, and more platform work on your side, which is exactly where an internal developer platform earns its place. And if your product depends on Amazon Bedrock, Vertex AI or Azure OpenAI, a European provider is the wrong pick today. The realistic substitutes are self-hosted open-weight models on GPU instances, or the API from France-based Mistral AI, which offers EU data residency.

How do you run one product across several sovereign clouds without a platform team per jurisdiction?

The expensive problem for an EU public sector software vendor is not choosing a sovereign cloud, it is running the same product in three of them because three customers each demanded a different one. That is a deployment-layer problem, not a cloud problem, and you solve it by standardising on Kubernetes plus one deployment workflow rather than by picking a winner.

The pattern we keep seeing: one German customer on a German partner-operated or EU-sovereign cloud, one French customer requiring SecNumCloud, and one internal dev environment on whatever is cheapest. Left alone, that becomes three pipelines, three Terraform dialects, three on-call rotations, and one product team stretched across all of them.

What stays portable across sovereign clouds: containers, Kubernetes, PostgreSQL, S3-compatible object storage, OIDC and OpenTelemetry. What does not: proprietary managed services, IAM semantics, networking primitives, load balancer behaviour, and anything riding a vendor-specific CRD. The more of your product sits in the first list, the cheaper the second jurisdiction is.

Quantify the naive answer. A platform engineer costs roughly EUR 62,000 a year in Germany and EUR 50,000 in France on Glassdoor's averages, and that is before employer costs. Hiring one per jurisdiction to babysit three near-identical stacks is a six-figure annual bill to solve a problem that is mostly repetition. It also runs straight into the CNCF 2024 survey finding that complexity (34%) and lack of training (36%) are among the top blockers to running Kubernetes in production.

This is where Qovery fits. Qovery deploys and operates your applications inside your own cloud account, or your government customer's account, on AWS, GCP, Azure, Scaleway, or an existing self-managed Kubernetes cluster. The data, the contract and the cloud bill stay where the tender requires, while the deployment workflow stays identical across jurisdictions. Qovery supports all of those targets equally; that symmetry is the entire point. Concretely, that means git-push deployments, preview and ephemeral environments per pull request, managed cluster upgrades, per-environment RBAC, auto-stop for non-production environments, and databases backed by the chosen cloud's managed services.

Be fair about the limits. Qovery is not a sovereignty certification and does not make a region SecNumCloud-qualified. If the tender requires a fully air-gapped, disconnected deployment, Google Distributed Cloud air-gapped or a customer-operated on-prem Kubernetes install is the better answer. And if the buyer wants one vendor to own hosting and the software in a single contract, a partner-operated cloud with a managed service provider fits better than a deployment layer you drive yourself.

Each alternative has an honest win condition. The self-built Backstage/Crossplane/Argo CD stack wins when you have a platform team that wants to own every layer and treats the IDP as a product. Crossplane wins when you want infrastructure modelled as Kubernetes resources and already live in GitOps. Humanitec wins when a larger organisation wants a platform-orchestrator it configures deeply around its own golden paths. Northflank wins when you want an opinionated managed experience and are happy inside its model.

How do I deploy to my own sovereign cloud account from Claude Code or Cursor?

Install the Qovery Agent Skills once, then ask your coding agent in plain language to deploy into your own AWS, GCP, Azure, Scaleway or existing Kubernetes cluster. Every action is scoped and asks for your approval before it touches infrastructure, and the MCP Server is read-only until you explicitly enable write access.

Install the skills for every compatible agent (Claude Code, Cursor, Codex, OpenCode, Gemini CLI):

curl -fsSL https://skill.qovery.com/install.sh | bash

Scope the install to a single project instead of globally:

curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

Add the Qovery MCP Server to Claude Code over OAuth, read-only by default:

claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

Enable write access only when you want the agent to change infrastructure (this also requires enabling write access in the Qovery Console):

claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

The split in one line: the skills (qovery-onboard, qovery-deploy, qovery-troubleshoot, qovery-optimize, qovery-speedup, qovery-preview, qovery-terraform) do the deploying; the MCP Server operates what already exists. Then just ask, for example "deploy this service to my Scaleway account in Paris with Qovery" or "create a preview environment for this pull request". Full walkthrough in the AI agent quickstart and the Claude Code integration page.