Cloud und Managed Services

Das Kapitel zu Abhängigkeiten hat gezeigt, dass europäische Cloud-Anbieter rund 15 % ihres Heimatmarktes halten. Diese Zahl ist statistisch korrekt, aber strategisch irreführend — sie suggeriert, dass der Abstand zwischen europäischer und amerikanischer Cloud in erster Linie eine Frage des Marktanteils und des Migrationswillens ist. Das stimmt nicht. Der Abstand ist zunächst funktionaler und architektonischer Natur und erst in zweiter Linie eine Frage des Marktanteils. Ein europäischer CIO, der eine Migration zu einem europäischen Anbieter im Jahr 2026 plant, ohne diese Unterschiede zu verstehen, plant blind.

Ein anderes Betriebsmodell, kein schlechteres

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

Hyperscaler bündeln die Integration und den Betrieb vieler Services in einem einzigen kommerziellen Vertrag. Der Kunde zahlt einen Aufpreis und erhält ein fertiges Produkt. Die europäische Alternative — OVHcloud, Scaleway, STACKIT, Hetzner — stellt Infrastruktur bereit und setzt voraus, dass die Organisation eigene Integrationskompetenz mitbringt.

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

Wo 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 bietet (doppelte Single-Core-Leistung zum Viertelpreis, ohne Egress-Gebühren), und dass OVHcloud in einem typischen Produktivsetup (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 das europäische Angebot 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. Doch 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 häufig 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; manche ergänzen Redis und MongoDB. Benötigt eine Anwendung ein Data Warehouse analog zu Redshift oder BigQuery, eine Graphdatenbank, Zeitreihen- oder Vektordatenbank als Managed Service, 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 basieren. Scaleway Serverless Functions + Containers existiert und ist funktionsfähig (unterstützt Python, Node.js, Go, Rust, verfügt über Key-Value-Store und Messaging), aber Katalog und Ökosystem sind deutlich schmaler. OVHcloud bietet ein eingeschränkteres Angebot. STACKIT stellt noch kein serverless Functions als gleichwertiges Produkt bereit. Eine Organisation, die ihre Anwendung auf einem breiten Serverless-Muster aufbaut, kann diese Architektur nicht einfach auf einen europäischen Anbieter übertragen — sie muss in ein containerisiertes oder traditionelles Modell umgeschrieben werden.

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

• Mistral AI Studio (gestartet Oktober 2025) positioniert sich als direkte Alternative zu SageMaker und Vertex AI — eine LLMOps-Plattform, die den vollständigen 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 erfolgen.
• Ü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 der Begründung, eine Abhängigkeit von US-Anbietern zu vermeiden, die dem CLOUD Act unterliegen — die erste bedeutende Bestätigung von Mistral als souveräne KI-Lösung für den staatlichen Sektor.

Ehrlicher Vorbehalt: Diese Produkte sind sehr neu — Studio ist seit Monaten öffentlich verfügbar, Forge steht erst am Anfang, und die Produktionserfahrungen von Organisationen damit im Jahr 2026 sind noch begrenzt. Für Organisationen, die am Anfang der KI-Einführung stehen, wird das europäische Angebot auf dieser Ebene zu einer echten Option; 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 — teilintegriertes 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 kluge 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 Äquivalente — Lösungen sind Open-Source-Wazuh, der ELK-Stack mit Security-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-Umzugs. Es ist eine Verschiebung der Verantwortung vom Hyperscaler-Team, das Managed Services für einen betreibt, zum eigenen Team oder einem externen Service-Partner. Schlüsselkompetenzen, die über eine reine Hyperscaler-Strategie hinaus erforderlich sind:

• Produktionsreifer Kubernetes-Betrieb (Control Plane, Upgrades, Netzwerkrichtlinien, 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-Services) — GitLab CE, Gitea, Harbor
• Eigenes oder Drittanbieter-MLOps (MLflow, Kubeflow), wenn die Organisation KI in der Produktion einsetzt
• Eigene Netzwerk- und Anwendungssicherheit (WAF, API Gateway — Open Source via Envoy, Kong, Traefik)
• Stärkere interne DevOps/SRE-Kompetenz — typische Schätzungen belaufen sich auf 2–4 zusätzliche Vollzeit-Ingenieure für eine mittelgroße Organisation

Diese Neuverteilung ist nicht zwangsläufig ein Nachteil. Europäische Organisationen haben statistisch eine höhere technische Talentdichte pro Kopf als die USA oder China; sie verfügen über starke Universitätssysteme und öffentliche IT-Ausbildung, die genau diese Kompetenz hervorbringen. Der Wechsel vom kommerziell gebündelten Betrieb zum internen Betrieb macht sich genau diesen Vorteil zunutze.

Eine Anmerkung zu „souveränen Clouds", die auf Hyperscaler-Technologie aufbauen

Partnerschaftsangebote wie Bleu (Capgemini/Orange + Microsoft), S3NS (Thales + Google) und Delos Cloud (Deutschland, T-Systems + Google) bilden eine dritte Kategorie, die weder rein hyperscaler- noch rein europäisch ist. Sie bieten die volle Katalogbreite, behalten aber die Abhängigkeit von lizenzierter amerikanischer Technologie bei. Sie sind Lösungen, die die Bit- und Interpretationsebene reduzieren, aber die instrumentelle Abhängigkeit 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 Warnhinweis 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 sind, der kanadischen Polizei herausgeben müsse, mit der Begründung, die „virtuelle Präsenz" von OVHcloud in Kanada unterwerfe das Unternehmen der kanadischen Jurisdiktion. OVHcloud berief sich auf das französische Blockierungsgesetz (loi de blocage) und verweigerte die Herausgabe der Daten. Dieser Fall zeigt, dass selbst ein europäischer Anbieter nicht vollständig immun gegenüber extraterritorialen Rechtsansprüchen ist; der einzige Unterschied besteht darin, dass ihnen Rechtsinstrumente zur Verfügung stehen — nationale Blockierungsgesetze —, die ihnen 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 folgen 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 häufig 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. Teilmigration ist das wahrscheinlichste pragmatische Ergebnis. Organisationen migrieren realistisch die Datenschicht und Workloads, bei denen die funktionale Lücke klein ist (VMs, Objektspeicher, Managed Kubernetes, Managed PostgreSQL), und belassen bei Hyperscalern die Workloads, die tiefe proprietäre Services nutzen. Eine solche hybride Strategie ist mit den Zielen der Operations-Roadmap vereinbar, da DORA und der Data Act die Möglichkeit 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. Insbesondere in der Kategorie KI/ML-Plattformen, wo wir noch vor einem Jahr festgestellt hätten „kein Äquivalent zu SageMaker", hat sich die Lage 2026 geöffnet. Die offene Frage ist, ob das europäische Angebot sich in Richtung der Integration vom Hyperscaler-Typ über die gesamte Katalogbreite bewegen kann, oder ob es strukturell im Modell „Infrastruktur plus Kundenintegration" verbleiben wird — was, wie wir gesehen haben, nicht zwingend ein Nachteil ist, wenn die Organisation über die entsprechende interne Kompetenz verfügt.