Cloud and managed services

The dependencies chapter showed that European cloud providers hold around 15 % of their home market. That number is statistically accurate but strategically misleading — it implies the gap between European and American cloud is primarily a question of market share and migration will. It is not. The gap is functional and architectural first, and only in second order one of market share. A European CIO planning a 2026 migration to a European alternative without understanding these differences is planning blind.

A different operating model, not a worse one

The catalogue of services from American hyperscalers runs to hundreds of products. AWS in early 2026 operates over 240 services, Azure over 200, Google Cloud over 150. European providers typically offer 30–60 services. This difference is not cosmetic. But it also is not a uniform deficit. It is a redistribution of responsibility.

Hyperscalers bundle integration and operation of many services into a single commercial contract. The customer pays a premium and receives a finished product. The European alternative — OVHcloud, Scaleway, STACKIT, Hetzner — offers infrastructure and assumes the organisation will bring its own integration competence.

This is not a defect. It is a different economic distribution that plays to Europe's structural advantage: a higher density of technical talent per capita than the U.S. or China. Moving from commercially bundled operations to your own operation leverages exactly this advantage. Short-term, it means higher salary costs; long-term, it produces internal know-how shared with the organisation, not the vendor.

Where parity is good, where the gap begins

Compute and storage — parity is good. Virtual machines, object storage (S3-compatible), block storage, networking, load balancers, DNS, CDN — all the basic primitives function. Independent benchmarking by Callista (February 2026) found that Scaleway delivers approximately 4.8× better price-performance than AWS (twice the single-core performance at a quarter of the price, with no egress fees), and that OVHcloud, in a typical production setup (5 Kubernetes nodes, relational database, object storage), achieves under half AWS's price. Infrastructure itself is therefore not the problem — by many measures the European is more competitive.

Container orchestration — formally at parity. Managed Kubernetes is available from all major European providers. Scaleway Kapsule even offers the Kubernetes control plane free of charge. But the integration layer around Kubernetes — service mesh, secrets management, certificate automation, IAM integration, managed operators for databases — is a finished product at hyperscalers and often a do-it-yourself install at European providers.

Managed databases — here the real difference begins. AWS offers RDS for PostgreSQL, MySQL, MariaDB, Oracle, and SQL Server; Aurora (proprietary cloud-native distributed engine), DynamoDB (NoSQL), DocumentDB, Redshift (data warehouse), Neptune (graph), Timestream (time-series), ElastiCache (Redis/Memcached), OpenSearch. Azure and Google Cloud offer comparable portfolios. OVHcloud, Scaleway, and STACKIT offer managed PostgreSQL and MySQL; some add Redis and MongoDB. If your application needs a data warehouse analogous to Redshift or BigQuery, a graph database, time-series, or vector database as a managed service, at European providers you typically install and operate these components yourself on virtual machines or in Kubernetes.

Serverless compute — the most pronounced gap. AWS Lambda, Azure Functions, and Google Cloud Functions define an entire class of application architectures built on events and fine-grained scaling. Scaleway Serverless Functions + Containers exists and is functional (supports Python, Node.js, Go, Rust, has a key-value store and messaging), but the catalogue and ecosystem are much narrower. OVHcloud has a more limited offering. STACKIT does not yet offer serverless functions as a peer product. An organisation building its application on a wide serverless pattern cannot simply replicate that architecture on a European provider — it will need to be rewritten into a containerised or traditional model.

AI/ML platforms — a gap that is actively closing. A year ago it was straightforward to say that AWS SageMaker, Azure ML, and Google Vertex AI as end-to-end platforms had no equivalent managed product in the European space. In 2026 the picture is changing rapidly thanks to several Mistral AI initiatives:

• Mistral AI Studio (launched November 2025) positions itself as a direct alternative to SageMaker and Vertex AI — an LLMOps platform covering the full cycle from prompts to production: observability, model evaluation, governance across distributed environments, retrain and deployment pipelines.
• Mistral Forge (launched March 2026 at Nvidia GTC) goes further still — it allows enterprises to train their own frontier-grade models from proprietary data, including pre-training, post-training, and reinforcement learning, with support for both dense and Mixture-of-Experts architectures. Training can run on the customer's own infrastructure or on Mistral's GPUs.
• Acquisition of Koyeb (February 2026) — a European serverless hosting platform — is intended to strengthen Mistral's own inference infrastructure in Europe and indirectly closes part of the serverless gap described above.

To this is added the French Ministry of the Armed Forces' framework agreement with Mistral, signed in December 2025 (a three-year contract covering all branches plus CEA, ONERA, and SHOM), explicitly motivated by avoiding dependency on U.S. providers subject to the CLOUD Act — the first major validation of Mistral as a sovereign AI solution for the state sector.

Honest caveat: these products are very new — Studio has been publicly available for months, Forge is only just starting, and organisations' production experience with them in 2026 remains limited. For organisations early in AI adoption, the European offering becomes a real choice at this layer; for mature AI deployments, it makes sense to pilot European platforms in parallel with the existing American stack and watch their maturity.

Observability, logging, and SIEM — semi-integrated offering. AWS CloudWatch, Azure Monitor, and Google Cloud Operations Suite form integrated stacks for metrics, logs, traces, and security events. At European providers the typical pattern is smart use of open source: Scaleway transparently integrates Grafana into its console; OVHcloud offers Logs Data Platform and Metrics; STACKIT has Observability Service on a Grafana/Loki/Prometheus/Tempo stack. For SIEM, European providers mostly do not offer direct equivalents — solutions are open-source Wazuh, ELK stack with security plugins, or independent European vendors such as Tehtris (France).

What it takes to operate on European cloud

Migration from a hyperscaler to OVH, Scaleway, or STACKIT is not primarily a question of moving workloads. It is a shift of responsibility from the hyperscaler team (which operates managed services for you) to your own team or an external service partner. Key competencies required beyond a pure hyperscaler strategy:

• Production-grade Kubernetes operations (control plane, upgrades, network policies, secrets management, horizontal/vertical scaling, monitoring)
• Database operation in containers or on VMs (PostgreSQL high-availability, backups, point-in-time recovery) where a managed equivalent is missing
• Integration of an open-source observability stack (Prometheus + Grafana + Loki + Tempo, or ELK)
• Own CI/CD and artifact registry (instead of integrated hyperscaler services) — GitLab CE, Gitea, Harbor
• Own or third-party MLOps (MLflow, Kubeflow) if the organisation uses AI in production
• Own network and application security (WAF, API gateway — open source via Envoy, Kong, Traefik)
• Stronger internal DevOps/SRE competence — typical estimates are an additional 2–4 full-time engineers for a mid-size organisation

This redistribution is not necessarily a disadvantage. European organisations have statistically higher technical-talent density per capita than the U.S. or China; they have strong university systems and public IT education that produce exactly this kind of competence. Moving from commercially packaged operations to in-house operation leverages exactly this advantage.

A note on "sovereign clouds" built on hyperscaler technology

Partnership offerings such as Bleu (Capgemini/Orange + Microsoft), S3NS (Thales + Google), and Delos Cloud (Germany, T-Systems + Google) form a third category that is neither pure hyperscaler nor pure European. They provide full catalogue breadth, but they retain dependence on licensed American technology. They are solutions that reduce the bit and interpretation layers but leave the instrumentation dependency in place — the lifecycle of the technology itself, security patches, and long-term development remain in the hands of the U.S. licensor. In 2026 practice, this category is, for many regulated organisations (defence, public administration, finance under DORA requirements), a pragmatic compromise.

A cautionary note on the limits of European jurisdiction

A Canadian court in September 2024 ordered OVHcloud to produce data stored in France, the UK, and Australia to Canadian police, on the reasoning that OVHcloud's "virtual presence" in Canada subjected the company to Canadian jurisdiction. OVHcloud invoked the French blocking statute (loi de blocage) and refused to hand over the data. This case demonstrates that even a European provider is not entirely immune to extraterritorial legal claims; the only difference is that they have legal instruments available — national blocking statutes — that give them at least a procedural defence.

Strategic implication

The decision "where to migrate" is a decision about where the responsibility for integration sits. Three principles follow:

1. If your organisation is willing and able to invest in internal DevOps/SRE competence, the European alternative is real and often financially advantageous. If the organisation structurally lacks this capacity and is not willing to build it, full migration will not be economically sensible.
2. Partial migration is the most likely pragmatic outcome. Organisations realistically migrate the data layer and workloads where the gap is functionally small (VMs, object storage, managed Kubernetes, managed PostgreSQL), and leave at hyperscalers the workloads that exploit deep proprietary services. Such a hybrid strategy is compatible with the goals of the operations roadmap, because DORA and the Data Act require the option of exit, not the wholesale abandonment of American providers.
3. European competitiveness is growing faster than perception suggests, but from a low base. Particularly in the AI/ML platforms category, where a year ago we would have stated "no equivalent to SageMaker", the situation in 2026 has opened. The open question is whether the European offering can move toward the integration of the hyperscaler type across the full catalogue breadth, or whether it will structurally remain in the "infrastructure plus customer integration" model — which, as we have seen, is not necessarily a disadvantage if the organisation has the corresponding internal competence.