European Sovereign Cloud: Build, Buy, or Self-Host Framework

The question arrives from the board, not the platform team: should we move to a sovereign cloud? By 2026 the phrase has hardened into a procurement category with a budget line — Gartner projects European sovereign-cloud IaaS spending will reach $12.6 billion this year, up 83% from $6.9 billion in 2025, and nearly double again to $23.1 billion in 2027. Where there is a budget line, there are vendors racing to fill it, and the market has answered the sovereignty question three incompatible ways at once. This article is the framework a buyer actually runs: not "which vendor is most sovereign," which is unanswerable, but a scoring procedure across four axes that lets you weight the trade-offs your own threat model forces. It is deliberately vendor-agnostic. The goal is a decision you can defend to an auditor and revisit in three years, not a logo on a slide.

Three answers to one question

"Sovereign cloud" is not one product; it is three archetypes that share a marketing word and almost nothing else. Before you can score anything, you have to name them precisely, because the confusion in most sovereign-cloud discussions comes from arguing across archetypes as though they were competing products in one category.

• Hyperscaler "sovereign" region — a legally and operationally separated partition of AWS, Microsoft, or Google, run by EU-resident staff under an EU entity. AWS opened its European Sovereign Cloud to general availability on 15 January 2026 with a first region in Brandenburg (eusc-de-east-1), a dedicated German parent company, and — early comparisons found — roughly a 15–17% price uplift over eu-central-1, no free tier, and no GPU instances at launch. Microsoft's Sovereign Public Cloud layers controls onto standard Azure. Google's answer, S3NS, is a Thales-majority joint venture that passed SecNumCloud 3.2 qualification in December 2025.
• EU-incorporated provider — a company whose registered head office, control, and jurisdiction are European: OVHcloud (over €1.1 billion revenue in 2025, 43 data centres), Scaleway, Deutsche Telekom's T-Systems, the Schwarz Group's StackIT, Hetzner. No foreign parent sits above the entity that operates your workloads. Several hold France's SecNumCloud qualification or the Franco-German SEAL-3 sovereignty rating.
• Self-operated infrastructure — your own Kubernetes on hardware you own, colocate, or rent as bare metal from an EU provider. You hold the control plane, the keys, and the supply chain. This is the cloud-repatriation end of the spectrum, and it is the only archetype where sovereignty is a structural property rather than a contractual one.

These three are not a ladder from worst to best. They are points on a plane of trade-offs, and a serious buyer's job is to find the point that dominates for their specific constraints. A regulated Series-B with a ten-person platform team and a fintech's compelled-disclosure exposure lands somewhere very different from a research group that needs GPU capacity in-region next quarter. The framework below is what makes that difference legible instead of tribal.

The word "sovereign" is doing too much work

The first thing to strip out is the label itself, because "sovereign" is now applied to offerings that share no common guarantee. Europe has two certification regimes pulling in different directions. France's SecNumCloud, run by ANSSI, is the strongest sovereignty signal in the EU today: it requires that data be hosted in the EU by a European provider, with explicit ownership and jurisdiction tests, and as of 2026 roughly nine providers are qualified with a dozen more under review. The EU's own scheme, EUCS, is weaker where it matters most. Its High level would originally have required EU-controlled providers; that requirement was diluted under industry pressure, so a US-parented cloud can now achieve EUCS High and remain subject to a CLOUD Act order. EUCS certifies security controls, not legal sovereignty — a distinction that disappears in most vendor brochures.

The regulators noticed. In March 2026 ANSSI and Germany's BSI published a joint declaration defining harmonised cloud-sovereignty criteria: strict data localisation, exclusive application of European law, absence of access by non-European third parties, and business continuity that does not depend on a non-EU actor. That is a usable definition — and notice that only the second archetype (EU-incorporated provider) and the third (self-operated) can satisfy the third and fourth clauses by construction. A partition owned by a foreign parent satisfies localisation and can satisfy European law contractually, but "absence of access by non-European third parties" is exactly the clause that corporate ownership cannot fully deliver. This is the gap that the Gaia-X label also cannot close: a certificate can attest a control, but it cannot revoke a jurisdiction.

The four axes that actually decide it

Decompose the decision into four properties that fail independently, so that a weakness on one does not hide behind a strength on another. Control asks who runs the control plane and holds the keys. Jurisdiction asks who can lawfully compel disclosure. Lock-in asks how expensive your exit is — the axis buyers systematically underprice. Cost asks the honest total at your scale, not the sticker on a landing page. Score each archetype on each axis, and the shape of the decision appears immediately: nobody wins all four.

Click to zoom

The matrix is not a scoreboard where the most teal cells win. It is an input to a weighted sum, and the weights are where your threat model lives. A media company with no regulated data and a hard convenience requirement might weight cost and control at 0.35 each and jurisdiction at 0.1 — and rationally land on a hyperscaler sovereign region. A defence subcontractor weights jurisdiction so heavily that any option scoring red there is eliminated before cost is even considered. The framework's value is that it forces you to state the weights explicitly, in advance, where a reviewer can challenge them — rather than back-fitting a justification to the vendor sales already wanted.

Axes 1 and 2: control and jurisdiction

Control and jurisdiction are the two axes where the archetypes separate most sharply, and they are frequently conflated. Control is a question of custody: in a hyperscaler sovereign region and in most managed EU-provider offerings, the provider operates the control plane and can, in principle, act on it. Only self-operation gives you the control plane, the private keys, and the admission policy outright — which is why the security case for an immutable, API-only node OS like Talos Linux is really a sovereignty argument: it makes the control plane's attack surface enumerable by you, not emergent under someone else's operations.

Jurisdiction is the axis that ends debates. The US CLOUD Act reaches any provider with a legal presence in the United States, and courts can compel a US parent to produce data held by a foreign subsidiary — which is precisely the corporate shape of AWS European Sovereign Cloud GmbH. This is not speculation. On 10 June 2025, Microsoft France's director of public and legal affairs told a French Senate inquiry, under oath, that he could not guarantee French citizens' data would never be transmitted to US authorities without French authorisation; asked whether a properly framed US request would oblige compliance, he answered "absolutely." No misconduct occurred and no European public-sector customer had been affected — but the testimony is evidence of structure, not behaviour. Corporate separation is a real cost and a real signal of intent. It is not a jurisdictional firewall. Only S3NS, with Thales holding the majority, breaks the US-parent pattern among the hyperscaler-adjacent options, and self-operation on an EU entity's hardware removes the foreign party from the chain entirely.

Because control and jurisdiction are the eliminating axes, score them first and as a filter, not a sum. A scorecard makes the reasoning auditable:

candidate: aws-european-sovereign-cloud
axes:
  control:       1   # provider-operated plane; EU-resident staff, not your custody
  jurisdiction:  0   # AWS European Sovereign Cloud GmbH -> US ultimate parent
  lock_in:       1   # proprietary services + egress; exit is a re-platform
  cost:          1   # ~15-17% premium over eu-central-1, no free tier
weights:             # must sum to 1.0 — this line IS the threat model
  control:       0.25
  jurisdiction:  0.40  # load-bearing: foreign compelled disclosure is in scope
  lock_in:       0.20
  cost:          0.15
# weighted = .25*1 + .40*0 + .20*1 + .15*1 = 0.60 / 3.0
# jurisdiction weighted at 0.40 and scored 0 -> eliminate before comparing cost

Axis 3: lock-in is the axis buyers underprice

Lock-in is where the sovereign-cloud decision most resembles the original cloud decision, and where buyers repeat the original mistake: they price the entrance and ignore the exit. A hyperscaler sovereign region inherits the parent's proprietary services and egress economics, so leaving is a re-platforming project measured in quarters. EU-incorporated providers tend to be more open — S3-compatible object storage, standard Kubernetes, low or zero egress fees — but a managed dependency is still a dependency. Self-operation is portable by construction: the exit is a hardware move, not a rewrite. The teams that have executed a real repatriation from hyperscaler to owned infrastructure uniformly report that the exit was constrained by architectural coupling, never by a contract clause.

The practical defence is to design the exit before you need it, whichever archetype you pick. Keep object storage on an S3-compatible layer you can move between MinIO successors. Keep the CI system replaceable. Keep application state in portable formats. Lock-in is not a property of a vendor; it is a property of how you build on them, and it is the one axis you control regardless of which archetype you buy.

Axis 4: the honest cost model

Cost is the axis most distorted by how it is presented. Hyperscaler sovereign regions charge a sovereignty premium — commonly cited at 10–30%, and measured at roughly 15–17% for AWS's European Sovereign Cloud over its standard German region — layered on top of already-premium hyperscaler pricing, with a smaller service catalogue and no free tier. EU-incorporated providers frequently invert that: an independent benchmark by Callista in February 2026 put Scaleway at roughly 4.8× the value per euro of AWS and Hetzner at over 14× the value per compute unit, before counting the egress fees they mostly do not charge. Self-operation trades opex for capex and demands platform maturity, but at scale the arithmetic is decisive.

The clearest public data point is 37signals, which cut its annual cloud bill from about $3.2 million to $1.3 million by repatriating — roughly $2 million a year, projected past $10 million over five years — after $700,000 of one-time Dell compute and a $1.5 million storage array that costs about $200,000 a year to run, all handled by a ten-person infrastructure team without new hires. Their numbers are not yours, but the shape generalises: buy-side archetypes are opex you can walk away from; the build-side archetype is capex you amortise. Scale and ops maturity decide whether amortisation beats the premium.

A. Hyperscaler sovereign region
   opex only, no capex; +15-30% sovereignty premium on premium pricing;
   egress + proprietary services raise the real bill and the exit cost.

B. EU-incorporated provider
   opex only; lowest sticker (benchmarks: ~4.8x Scaleway, ~14x Hetzner
   value vs AWS); low/zero egress; still a managed dependency.

C. Self-operated on owned / colo metal
   capex: servers once (37signals: ~$700k compute + ~$1.5M storage array)
   opex: power/colo/support (~$200k/yr) + an existing platform team
   breaks even ~12-18 months at scale, then structurally cheaper.

Rule of thumb: below real scale or platform maturity, B beats C on
total cost AND effort. Above it, C's amortisation wins and keeps winning.

Running the procedure

With the axes scored and weighted, the decision collapses into a short procedure rather than a vendor beauty contest. Start from the binding constraint, filter on the eliminating axes, then optimise the rest.

Click to zoom

• Jurisdiction is load-bearing (regulated data, foreign-disclosure exposure, defence or public-sector context): eliminate US-parent sovereign regions outright. The choice is between an EU-incorporated provider and self-operation.
• Jurisdiction is not load-bearing (no regulated data, convenience and in-region residency are the real requirements): a hyperscaler sovereign region is defensible — but treat it as a waypoint and architect the exit from day one, because the premium and the lock-in compound.
• You lack platform-ops maturity or scale: buy from an EU-incorporated, SecNumCloud-qualified provider. You get EU jurisdiction and low cost without the burden of operating the plane yourself. Keep the exit ramp.
• You have the team and the scale, and control plus cost dominate: self-operate on owned, colocated, or EU-bare-metal infrastructure. This is the only archetype where sovereignty is structural, and at scale it is also the cheapest.

Buy reversibly, build where it compounds

The framework is not a mandate to self-host everything; that is as dogmatic as defaulting to a hyperscaler. It is a mandate to make the trade-off explicit and reversible. Most organisations should run a portfolio: buy from an EU-incorporated provider for the workloads where a managed dependency is acceptable and cheap, self-operate the workloads where control and jurisdiction are non-negotiable, and treat any hyperscaler sovereign region as a transitional waypoint with a rehearsed exit. The regulatory drivers converge on this same architecture — NIS2, DORA, and the AI Act all reward the option that keeps custody and jurisdiction close.

What matters is that the boundary between buy and build is drawn on purpose, workload by workload, and revisited on a schedule. The EU-incorporated provider you buy from today may be acquired tomorrow; the sovereignty premium you pay today may be undercut next quarter; the platform maturity you lack this year you may have next year. A portfolio with rehearsed exits absorbs all three without a crisis. A single-vendor commitment with a documented-but-untested exit does not.

The long game

Sovereign cloud is a decade-scale decision dressed as a procurement cycle. The €12.6 billion flowing into European sovereign infrastructure this year will build real capacity, and the certification landscape — SecNumCloud, EUCS, the ANSSI–BSI convergence — will keep shifting under political pressure for years. Anything you decide on the basis of today's labels will be re-litigated. The durable posture is not a vendor choice; it is an architecture that treats the vendor as replaceable. Hold the control plane where you can, hold the keys always, and keep every dependency behind an interface you could re-implement. Then a sovereign-cloud strategy stops being a bet on which political weather holds and becomes what it should have been all along: a property of systems you designed to outlast the vendors that host them.

This is the same discipline that runs through digital sovereignty as a testable architecture rather than a policy slogan. The buyer who runs the four-axis procedure, states the weights, and rehearses the exit does not need the market to settle on a definition of "sovereign." They have already built the thing the word is reaching for — and they can prove it, on a Tuesday, without asking anyone's permission.