Cloud und Managed Services

Das Kapitel über Abhängigkeiten hat gezeigt, dass europäische Cloud-Anbieter rund 15 % ihres Heimatmarktes halten. Diese Zahl ist statistisch korrekt, strategisch aber irreführend — sie suggeriert, dass die Lücke zwischen europäischer und amerikanischer Cloud in erster Linie eine Frage von Marktanteilen und Migrationswillen ist. Das ist sie nicht. Die Lücke ist funktional und architektonisch begründet und erst in zweiter Ordnung eine Frage des Marktanteils. Ein europäischer CIO, der eine Migration zu einer europäischen Alternative im Jahr 2026 plant, ohne diese Unterschiede zu verstehen, plant im Blindflug.

Ein anderes Betriebsmodell, kein schlechteres

Der Dienstleistungskatalog amerikanischer Hyperscaler umfasst Hunderte von Produkten. AWS betreibt Anfang 2026 über 240 Dienste, Azure über 200, Google Cloud über 150. Europäische Anbieter bieten typischerweise 30–60 Dienste an. Dieser Unterschied ist nicht kosmetischer Natur. Er ist aber auch kein gleichmäßiges Defizit. Es handelt sich um eine Verlagerung von Verantwortung.

Hyperscaler bündeln Integration und Betrieb vieler Dienste in einem einzigen Kaufvertrag. Der Kunde zahlt eine Prämie und erhält ein fertiges Produkt. Die europäische Alternative — OVHcloud, Scaleway, STACKIT, Hetzner — stellt Infrastruktur bereit und setzt voraus, dass die Organisation ihre eigene Integrationskompetenz mitbringt.

Das ist kein Mangel. Es ist eine andere wirtschaftliche Verteilung, die Europas strukturellen Vorteil ausspielt: eine höhere Dichte technischer Talente pro Kopf als in den USA oder China. Der Wechsel vom kommerziell gebündelten Betrieb zum Eigenbetrieb nutzt genau diesen Vorteil. Kurzfristig bedeutet das höhere Gehaltskosten; langfristig entsteht internes Know-how, das der Organisation zugute kommt, nicht dem Anbieter.

Wo die Parität gut ist, wo die Lücke beginnt

Compute und Storage — Parität ist gut. Virtuelle Maschinen, Objektspeicher (S3-kompatibel), Blockspeicher, Netzwerk, Load Balancer, DNS, CDN — alle grundlegenden Primitive funktionieren. Unabhängige Benchmarks von Callista (Februar 2026) ergaben, dass Scaleway ein etwa 4,8-fach besseres Preis-Leistungs-Verhältnis als AWS liefert (doppelte Single-Core-Leistung zu einem Viertel des Preises, ohne Egress-Gebühren) und dass OVHcloud in einem typischen Produktionssetup (5 Kubernetes-Knoten, relationale Datenbank, Objektspeicher) weniger als die Hälfte des AWS-Preises erreicht. Die Infrastruktur selbst ist also nicht das Problem — in vielen Maßstäben ist der europäische Anbieter wettbewerbsfähiger.

Container-Orchestrierung — formal auf Augenhöhe. Managed Kubernetes ist bei allen großen europäischen Anbietern verfügbar. Scaleway Kapsule bietet sogar die Kubernetes-Control-Plane kostenlos an. Die Integrationsschicht rund um Kubernetes — Service Mesh, Secrets Management, Zertifikatsautomatisierung, IAM-Integration, Managed Operators für Datenbanken — ist bei Hyperscalern ein fertiges Produkt und bei europäischen Anbietern oft eine Do-it-yourself-Installation.

Managed Databases — hier beginnt der eigentliche Unterschied. AWS bietet RDS für PostgreSQL, MySQL, MariaDB, Oracle und SQL Server; Aurora (proprietäre cloud-native verteilte Engine), DynamoDB (NoSQL), DocumentDB, Redshift (Data Warehouse), Neptune (Graph), Timestream (Zeitreihen), ElastiCache (Redis/Memcached), OpenSearch. Azure und Google Cloud bieten vergleichbare Portfolios. OVHcloud, Scaleway und STACKIT bieten Managed PostgreSQL und MySQL; einige fügen Redis und MongoDB hinzu. Wenn eine Anwendung ein Data Warehouse analog zu Redshift oder BigQuery, eine Graphdatenbank, Zeitreihen- oder Vektordatenbank als Managed Service benötigt, müssen diese Komponenten bei europäischen Anbietern typischerweise selbst installiert und betrieben werden auf virtuellen Maschinen oder in Kubernetes.

Serverless Compute — die ausgeprägteste Lücke. AWS Lambda, Azure Functions und Google Cloud Functions definieren eine ganze Klasse von Anwendungsarchitekturen, die auf Events und feingranularer Skalierung aufbauen. Scaleway Serverless Functions + Containers existiert und ist funktional (unterstützt Python, Node.js, Go, Rust, hat einen Key-Value-Store und Messaging), aber Katalog und Ökosystem sind deutlich schmaler. OVHcloud hat ein eingeschränkteres Angebot. STACKIT bietet noch keine Serverless Functions als gleichwertiges Produkt an. Eine Organisation, die ihre Anwendung auf einem umfangreichen Serverless-Muster aufbaut, kann diese Architektur nicht einfach auf einem europäischen Anbieter replizieren — sie müsste auf ein containerisiertes oder klassisches Modell umgeschrieben werden.

KI/ML-Plattformen — eine Lücke, die sich aktiv schließt. Noch vor einem Jahr war es eindeutig zu sagen, dass AWS SageMaker, Azure ML und Google Vertex AI als End-to-End-Plattformen kein vergleichbares Managed-Produkt im europäischen Raum hatten. 2026 ändert sich das Bild rasant dank mehrerer Mistral-KI-Initiativen:

• Mistral AI Studio (gestartet November 2025) positioniert sich als direkte Alternative zu SageMaker und Vertex AI — eine LLMOps-Plattform, die den gesamten Zyklus von Prompts bis zur Produktion abdeckt: Observability, Modellbewertung, Governance in verteilten Umgebungen, Retrain- und Deployment-Pipelines.
• Mistral Forge (gestartet März 2026 auf der Nvidia GTC) geht noch weiter — es ermöglicht Unternehmen, eigene Frontier-Modelle aus proprietären Daten zu trainieren, einschließlich Pre-Training, Post-Training und Reinforcement Learning, mit Unterstützung für dichte und Mixture-of-Experts-Architekturen. Das Training kann auf der eigenen Infrastruktur des Kunden oder auf Mistrals GPUs laufen.
• Übernahme von Koyeb (Februar 2026) — einer europäischen Serverless-Hosting-Plattform — soll Mistrals eigene Inferenzinfrastruktur in Europa stärken und schließt indirekt einen Teil der oben beschriebenen Serverless-Lücke.

Hinzu kommt der Rahmenvertrag des französischen Verteidigungsministeriums mit Mistral, unterzeichnet im Dezember 2025 (ein Dreijahresvertrag, der alle Teilstreitkräfte sowie CEA, ONERA und SHOM umfasst), ausdrücklich mit dem Ziel, Abhängigkeiten von US-Anbietern zu vermeiden, die dem CLOUD Act unterliegen — die erste große Bestätigung von Mistral als souveräne KI-Lösung für den Staatssektor.

Ehrlicher Vorbehalt: Diese Produkte sind sehr neu — Studio ist seit Monaten öffentlich verfügbar, Forge steckt noch in den Kinderschuhen, und die Produktionserfahrung von Organisationen damit im Jahr 2026 bleibt begrenzt. Für Organisationen, die am Anfang ihrer KI-Einführung stehen, wird das europäische Angebot auf dieser Ebene zu einer echten Wahl; für reife KI-Deployments empfiehlt es sich, europäische Plattformen parallel zum bestehenden amerikanischen Stack zu pilotieren und ihre Reife zu beobachten.

Observability, Logging und SIEM — halbintegriertes Angebot. AWS CloudWatch, Azure Monitor und Google Cloud Operations Suite bilden integrierte Stacks für Metriken, Logs, Traces und Sicherheitsereignisse. Bei europäischen Anbietern ist das typische Muster der intelligente Einsatz von Open Source: Scaleway integriert Grafana transparent in seine Konsole; OVHcloud bietet Logs Data Platform und Metrics; STACKIT hat einen Observability Service auf Basis von Grafana/Loki/Prometheus/Tempo. Für SIEM bieten europäische Anbieter meist keine direkten Entsprechungen — Lösungen sind Open-Source-Wazuh, ELK-Stack mit Sicherheits-Plugins oder unabhängige europäische Anbieter wie Tehtris (Frankreich).

Was der Betrieb auf europäischer Cloud erfordert

Eine Migration von einem Hyperscaler zu OVH, Scaleway oder STACKIT ist nicht in erster Linie eine Frage des Workload-Transfers. Es ist eine Verlagerung von Verantwortung vom Hyperscaler-Team (das Managed Services für Sie betreibt) auf das eigene Team oder einen externen Servicepartner. Über eine reine Hyperscaler-Strategie hinaus sind folgende Kernkompetenzen erforderlich:

• Produktionsreifer Kubernetes-Betrieb (Control Plane, Upgrades, Network Policies, Secrets Management, horizontale/vertikale Skalierung, Monitoring)
• Datenbankbetrieb in Containern oder auf VMs (PostgreSQL High Availability, Backups, Point-in-Time Recovery), wo ein Managed-Äquivalent fehlt
• Integration eines Open-Source-Observability-Stacks (Prometheus + Grafana + Loki + Tempo oder ELK)
• Eigene CI/CD- und Artifact-Registry (statt integrierter Hyperscaler-Dienste) — GitLab CE, Gitea, Harbor
• Eigenes oder Drittanbieter-MLOps (MLflow, Kubeflow), wenn die Organisation KI im Produktivbetrieb einsetzt
• Eigene Netzwerk- und Anwendungssicherheit (WAF, API-Gateway — Open Source über Envoy, Kong, Traefik)
• Stärkere interne DevOps/SRE-Kompetenz — typische Schätzungen gehen von 2–4 zusätzlichen Vollzeit-Engineers für eine mittelgroße Organisation aus

Diese Umverteilung ist nicht zwangsläufig ein Nachteil. Europäische Organisationen weisen statistisch eine höhere technische Talentdichte pro Kopf auf als die USA oder China; sie verfügen über starke Hochschulsysteme und öffentliche IT-Ausbildung, die genau diese Kompetenz hervorbringen. Der Wechsel vom kommerziell verpackten Betrieb zum Eigenbetrieb nutzt genau diesen Vorteil.

Ein Hinweis zu „souveränen Clouds" auf Basis von Hyperscaler-Technologie

Partnerschaftsangebote wie Bleu (Capgemini/Orange + Microsoft), S3NS (Thales + Google) und Delos Cloud (Deutschland, T-Systems + Google) bilden eine dritte Kategorie, die weder reiner Hyperscaler noch rein europäisch ist. Sie bieten volle Katalogbreite, behalten aber die Abhängigkeit von lizenzierter amerikanischer Technologie. Es sind Lösungen, die die Bit- und Interpretationsschichten reduzieren, die Instrumentierungsabhängigkeit jedoch bestehen lassen — der Lebenszyklus der Technologie selbst, Sicherheits-Patches und die langfristige Entwicklung verbleiben in den Händen des US-Lizenzgebers. In der Praxis des Jahres 2026 ist diese Kategorie für viele regulierte Organisationen (Verteidigung, öffentliche Verwaltung, Finanzwesen unter DORA-Anforderungen) ein pragmatischer Kompromiss.

Ein warnender Hinweis zu den Grenzen europäischer Jurisdiktion

Ein kanadisches Gericht ordnete im September 2024 an, dass OVHcloud Daten, die in Frankreich, dem Vereinigten Königreich und Australien gespeichert waren, der kanadischen Polizei herausgeben soll, mit der Begründung, dass OVHclouds „virtuelle Präsenz" in Kanada das Unternehmen der kanadischen Gerichtsbarkeit unterwerfe. OVHcloud berief sich auf das französische Blockierungsstatut (loi de blocage) und verweigerte die Herausgabe der Daten. Dieser Fall zeigt, dass selbst ein europäischer Anbieter nicht vollständig immun gegen extraterritoriale Rechtsansprüche ist; der einzige Unterschied besteht darin, dass ihnen rechtliche Instrumente zur Verfügung stehen — nationale Blockierungsstatute —, die zumindest eine verfahrensrechtliche Verteidigung ermöglichen.

Strategische Implikation

Die Entscheidung „wohin migrieren" ist eine Entscheidung darüber, wo die Verantwortung für die Integration liegt. Daraus ergeben sich drei Grundsätze:

1. Wenn die Organisation bereit und in der Lage ist, in interne DevOps/SRE-Kompetenz zu investieren, ist die europäische Alternative real und oft finanziell vorteilhaft. Fehlt der Organisation diese Kapazität strukturell und ist sie nicht bereit, sie aufzubauen, wird eine vollständige Migration wirtschaftlich nicht sinnvoll sein.
2. Partielle Migration ist das wahrscheinlichste pragmatische Ergebnis. Organisationen migrieren realistischerweise die Datenschicht und Workloads, bei denen die Lücke funktional klein ist (VMs, Objektspeicher, Managed Kubernetes, Managed PostgreSQL), und lassen bei Hyperscalern die Workloads, die tiefe proprietäre Dienste nutzen. Eine solche Hybridstrategie ist mit den Zielen der Operations-Roadmap vereinbar, da DORA und der Data Act die Option des Ausstiegs verlangen, nicht die vollständige Abkehr von amerikanischen Anbietern.
3. Die europäische Wettbewerbsfähigkeit wächst schneller als die Wahrnehmung vermuten lässt, aber von einer niedrigen Basis aus. Besonders in der Kategorie KI/ML-Plattformen, wo wir noch vor einem Jahr hätten sagen müssen „kein Äquivalent zu SageMaker", hat sich die Situation 2026 geöffnet. Die offene Frage ist, ob das europäische Angebot sich in Richtung der Integration vom Hyperscaler-Typ über die volle Katalogbreite bewegen kann, oder ob es strukturell im Modell „Infrastruktur plus Kundenintegration" verbleibt — was, wie wir gesehen haben, nicht zwangsläufig ein Nachteil ist, wenn die Organisation über die entsprechende interne Kompetenz verfügt.