Der AWS‑Ausfall zu Beginn der Woche hat einmal mehr gezeigt, wie stark viele Dienste an wenigen großen Hyperscalern hängen. Stundenlang waren Kollaborationstools wie Slack, Signal oder Zoom nur eingeschränkt nutzbar – ein vermeintlicher Weckruf für alle, die ihre Cloud‑Strategie bislang auf wenige zentrale Anbieter gestützt haben. Wir wollen nun einen genaueren Blick auf die aktuelle Situation werfen.
Ein kritischer Blick auf EU Cloud Souveränität
Aufgrund der politischen Situation in den USA ist das Thema der europäischen Cloud Souveränität ein stets wiederkehrender Gast. Spätestens seit dem Ausfall von AWS diese Woche ist das Thema in aller Munde und es gibt an dieser Stelle viele undifferenzierte Aussagen. Ein Lager wettert gegen Hyperscaler, ein anderes Lager ist für mehr Nutzung europäischer Cloud-Anbieter, ein weiteres Lager wettert gegen Cloud-Technologien allgemein und andere wiederum wünschen sich wieder den Betrieb im eigenen Keller.
Versuchen wir nun eine Einordnung vorzunehmen anhand des aktuellen Ausfalls von AWS als Beispiel:
Bei AWS ist diese Woche nicht nur ein einzelner Service ausgefallen, sondern es hat direkt die ganze Region US-EAST-1 in die Knie gezwungen. In dieser Region befinden sich zentrale Services wie z.B. der Datenbank Service DynamoDB, welcher wiederum für andere interne Services kritisch ist und somit hat sich eine Art Internet-GAU ergeben und viele öffentliche Dienste wurden aufgrund ihrer Abhängigkeit zu AWS unnutzbar. Der Ausfall und die Nachwehen hielten für ca. 10-12h an, bevor es wieder in den Normalbetrieb ging.
Anti-Hyperscaler
Nehmen wir nun die kritischen Stimmen der Anti-Hyperscaler, lässt sich die Behauptung, dass die Abhängigkeit vieler Unternehmen zu Hyperscalern ein Risiko darstellt, leicht untermauern. Sei es nun, dass man mit eigener Software oder durch Ausfälle von Drittanbietern in die Handlungsunfähigkeit gebracht wird, die Behauptung steht erstmal stabil im Raum. Bei genauerer Betrachtung offenbart sich allerdings eine Nachlässigkeit, nämlich dass viele Unternehmen eine Single-Cloud-Strategie fahren und somit ihre Workloads bei nur einem Cloud-Anbieter provisionieren. Geschieht ein zentraler Ausfall wie bei AWS, ist man entsprechend nicht gewappnet, egal ob Hyperscaler oder anderer Anbieter.
Pro EU Cloud
Kombinieren wir nun diesen Ausfall mit den Stimmen der EU Cloud Befürworter, könnte man schnell zum Schluss kommen, dass man seine Workloads bei einem europäischen Cloud-Anbieter wie OVH oder OpenTelekomCloud provisionieren sollte. In diesem Fall wird die Abhängigkeit zu den amerikanischen Hyperscalern auf 0 reduziert, wechselt aber lediglich den Partner in der Abhängigkeitsbeziehung. Auch hier lässt sich ein Beispiel finden, dass dies nicht die heilsbringende Lösung ist, wie der Brand des Rechenzentrums des europäischen Anbieters OVH in Straßburg zeigt. Auch hier kam es zu Datenverlust und erheblichen Ausfällen.
Böse Cloud-Technologien
Gehen wir noch eine Stufe weiter, könnte man Cloud-Technologien und ihre schier unendlichen Abstraktionsschichten generell verteufeln. Einen Funken Wahrheit gibt es bei dieser Aussage, denn der Wald an Komplexität und anbieterabhängigen Abstraktionen scheint immer weiter zu wachsen, doch ihnen zugrunde liegen die eigentlichen Benefits:
Kubernetes & Containerplattformen dienen zur Entkopplung von Provider‑Details und ermöglichen einen standardisierten Betrieb
Infrastructure as Code (Terraform, Pulumi) für reproduzierbare Infrastrukturen, soweit diese nicht anbieterabhängig sind
GitOps für reproduzierbare Workloads, schnelle Rollbacks und konsistente Deployments
Container als standardisierte Artefakte um Anwendungen zu deployen
Diese Benefits sind nicht unerheblich und ermöglichen es vielen Unternehmen erst Software standardisiert, automatisiert und skalierbar zu deployen, ohne die notwendigen Kenntnisse für die gesamte Infrastruktur zu benötigen. Genau dieser Punkt erlaubt es sich deutlich schneller in einem globalen Markt zu bewegen und sich auf die wesentlichen Kernkompetenzen zu konzentrieren, denn nicht jedes Unternehmen ist gleichzeitig auch ein Technologieunternehmen mit eigener IT oder SREs. Es ist für die meisten Unternehmen schlicht nicht wirtschaftlich sich mit individueller Softwareentwicklung und angrenzenden Themen zu befassen.
Lieber alles im eigenen Keller
Hier setzt auch die Argumentation des vierten Lagers an, denn nur wer seine Software selber baut und betreibt, ist gänzlich unabhängig. Diesem Punkt kann ich grundsätzlich uneingeschränkt zustimmen, allerdings bröckelt diese Argumentation mit den gleichen Gründen wie im vorigen Absatz. Viele Unternehmen haben schlicht nicht die Größe, die finanzielle Stärke und/oder das Know-How sich mit diesen Themen zu befassen. Der Betrieb eigener Netzwerke, Server, Speicherplatz, etc. sind alles andere als trivial und lassen sich nicht sicher und effizient ohne echtes Know-How betreiben. Somit ergibt sich in gewisser Weise eine Abhängigkeit vom existierenden Angebot diverser Anbieter.
Hätte nun irgendein Lager was an der Situation mit AWS ändern können? Die Antwort ist ein klassisches: Kommt drauf an.
Mit Sicherheit wäre ein Multi-Region oder ein Multi-Cloud-Setup für erhöhte Redundanz sinnvoll und richtig gewesen, allerdings bezahlt man dafür auch einen hohen Preis. Noch teurer und komplexer wäre der Betrieb eigener sicherer Infrastrukturen. Zumal sich auch hier Abhängigkeiten zu externen Dienstleistern einschleichen können, die wiederum auf einen öffentlichen Anbieter (z.B. Storage bei AWS) setzen, der ausfallen kann.
Und was nun?
Grundsätzlich kann man sagen: Hyperscaler sind in der Regel deutlich zuverlässiger als ein komplett eigener Infrastruktur‑Betrieb. Große Cloud‑Anbieter investieren intensiv in redundante Rechenzentren, Automatisierung, Sicherheitskompetenz und weltweite Standorte und verfügen über einen massiven Wissensvorsprung — Skaleneffekte, die sich viele Unternehmen allein wirtschaftlich kaum leisten können. Deshalb ist die Nutzung von Hyperscalern für viele Anwendungen nicht nur technisch sinnvoll, sondern oft auch die günstigste und stabilste Lösung. Gleichwohl sind auch europäische Cloud‑Anbieter nicht komplett frei von Ausfällen, wie etwa der Brand des OVH‑Rechenzentrums in Straßburg gezeigt hat, weshalb Diversifikation und eine ernsthafte Risikoabwägung weiterhin wichtig bleiben.
Das Problem ist also kein Entweder‑Oder, sondern ein Abwägen von Nutzen und Risiko: Die Verfügbarkeit und Effizienz der Hyperscaler stehen einer betriebswirtschaftlichen und strategischen Abhängigkeit gegenüber. Diese Abhängigkeit sollte man bei der Umsetzung von IT-Vorhaben kritisch betrachten und wird somit Teil der Entscheidungsgrundlage.
Risiko‑Kosten gegenüberstellen: Was kostet zusätzliche Redundanz (zweiter Provider, On‑Premise‑Fallback) vs. potentieller Schaden?
Total Cost of Ownership (TCO): Berücksichtigen Sie nicht nur Infrastrukturkosten, sondern auch Betriebspersonalkosten, Komplexitätsaufwand und Migrationskosten.
Unser Ansatz bei viadee: pragmatisch und individuell
Bei viadee arbeiten wir im Forschungsbereich Cloud-Plattformen & -Architekturen daran, technische Exzellenz mit pragmatischer Vernunft zu verbinden. Wir verteufeln Hyperscaler nicht, ihre Stabilität und Effizienz sind oft unbestritten , aber wir beraten so, dass Abhängigkeiten sichtbar, bewertbar und steuerbar werden. In konkreten Projekten setzen wir deshalb gezielt auf Diversifikation: Je nach Anwendungsfall setzen wir auf Hyperscaler, europäische Anbieter wie OVH/OpenTelekomCloud oder einen Mixed-Cloud Ansatz, je nach Abhängigkeit an die technischen, fachlichen wie auch organisatorischen Anforderungen.
Trade‑offs nicht verschweigen
Mehr Resilienz bedeutet oft höhere Komplexität und Kosten. Ein rein technischer Ansatz ist für die Betrachtung nicht ausreichend , die richtige Balance zwischen Stabilität, Kosten und organisatorischem Aufwand ist entscheidend. Deshalb empfehlen wir eine pragmatische, stufenweise Vorgehensweise, die sich an konkretem Geschäftswert orientiert.
Fazit
Hyperscaler bieten oft bessere Stabilität und Wirtschaftlichkeit als der alleinige Eigenbetrieb , aber mit dieser Effizienz kommt strategische Abhängigkeit. Die Lösung ist kein Entweder‑Oder, sondern ein wohlüberlegtes Abwägen: technische Diversifikation, klare kaufmännische Bewertung der Risiken und pragmatische hybride Architekturen. So minimieren Sie die Wahrscheinlichkeit eines kritischen Ausfalls und begrenzen gleichzeitig die Auswirkungen, sollte es doch passieren.
Wir unterstützen Sie gerne dabei, Ihre Cloud‑Risiken quantitativ zu bewerten, wirtschaftlich einzuordnen und praktikable Maßnahmen zur Erhöhung der digitalen Souveränität umzusetzen.
