Wenn die Basis wackelt – Was die aktuellen Cloud-Ausfälle über Infrastruktur wirklich zeigen

24.11.2025 · infrastructure, cloud, ha, architecture, strategy, core2code

Mehrere große Ausfälle bei AWS, Azure und Cloudflare haben in den letzten Wochen zentrale Dienste im Internet beeinträchtigt – darunter Identitätsdienste, Storage-Systeme, globale Routingpfade und Content-Delivery-Infrastrukturen. Diese Ereignisse zeigen, wie verletzlich moderne digitale Ökosysteme sind, selbst wenn sie auf den größten Cloud-Anbietern der Welt laufen.

Doch statt nur über Störungen zu sprechen, lohnt ein Blick auf die strategischen Konsequenzen: Welche Verantwortung haben Unternehmen für ihre eigene Verfügbarkeit. Wie plant man Redundanz sinnvoll. Und warum sind Hyperscaler weder Heilsbringer noch Sündenböcke.

Hochverfügbarkeit kostet – immer

Die grundlegende Wahrheit lautet: Wer Hochverfügbarkeit will, muss dafür zahlen. Verfügbarkeit entsteht aus Redundanz, und Redundanz bedeutet eine vollständige zweite Infrastruktur. Failover-Kapazitäten verdoppeln die Kosten – egal ob in der Public Cloud oder im eigenen Rechenzentrum.

Cloud reduziert diese Kosten nicht. Sie macht sie variabler und buchhalterisch einfacher. Verantwortung substituiert sie nicht. Sie verschiebt sie.

Strategy first: RPO und RTO klären, bevor Architektur entsteht

Der wichtigste Schritt ist kein technischer, sondern ein geschäftlicher:

• Wie viel Datenverlust ist akzeptabel (RPO).
• Wie schnell muss ein Service wieder online sein (RTO).
• Welche Geschäftsprozesse hängen daran.
• Was kostet ein Ausfall pro Stunde.

Ohne Antworten auf diese Fragen führt jede Architekturentscheidung entweder zu unnötigen Kosten oder zu unnötigem Risiko.

Verfügbarkeit ist eine strategische Entscheidung. Architektur setzt sie um.

Aktuelle Ausfälle zeigen: Größe schützt nicht vor Fehlern

Die jüngsten Störungen bei den großen Anbietern sind Beispiele dafür, wie fragil globale Systeme trotz massiver Automatisierung sein können.

AWS – Ausfall am 20. Oktober 2025

Ein leerer bzw. fehlerhafter DNS-Eintrag in der Automatisierung rund um DynamoDB löste eine Kettenreaktion aus: Load Balancer, DNS-Resolution und weitere Basisdienste waren beeinträchtigt. Ein kleiner Fehler mit großer Wirkung – typisch für hochatomatisierte Umgebungen.

Azure – Störung am 29. Oktober 2025

Eine Fehlkonfiguration im globalen Routing bzw. im Azure-Front-Door/CDN-Layer führte zu einem weltweiten Ausfall, der auch Microsoft 365 betraf. Selbst mehrere Redundanzschichten halfen nicht, weil der zentrale Routingpfad selbst der Single Point of Failure war.

Cloudflare – Ausfall am 18. November 2025

Eine übergroße Konfigurationsdatei der Bot-Management-Engine führte zu Softwarefehlern, die Cloudflares Infrastruktur und damit zahlreiche Websites (u. a. X, ChatGPT) in die Knie zwangen. Je zentraler ein Anbieter ist, desto breiter streut der Impact eines Fehlers.

Diese Vorfälle zeigen: Hyperscaler skalieren nicht nur Verfügbarkeit – sie skalieren auch Fehler.

Hybridansatz: Grundlast selbst, Spitzenlast aus der Cloud

Sind RPO und RTO definiert, lassen sich Architekturen entwickeln, die zwischen Risiko und Kosten balancieren. Ein bewährtes Modell ist: Grundlast selbst betreiben, Spitzenlast flexibel aus der Cloud beziehen.

Das reduziert Abhängigkeiten, vermeidet Überprovisionierung und schafft echte Resilienz.

Ein Ansprechpartner ist bequem – aber Monokultur bleibt riskant

Viele Unternehmen genießen die Einfachheit eines einzigen Infrastrukturpartners. Ein Ticket, ein Supportprozess, keine Schuldzuweisungen.

Das funktioniert – solange der Hersteller stabil und berechenbar bleibt. Die Entwicklungen eines großen Virtualisierungsherstellers in den letzten Jahren haben jedoch gezeigt, wie schnell eine strategische Abhängigkeit zur Belastung werden kann.

Konsolidierung ist gut. Monokultur ist gefährlich. Die richtige Balance entscheidet.

Verfügbarkeit ist ein Prozess, kein Produkt

Weder Cloud-Anbieter noch interne Teams sind unfehlbar. Verfügbarkeit entsteht durch:

• klare Ziele und Anforderungen
• robuste und pragmatische Architektur
• sauberen Betrieb
• Organisationskultur
• kontinuierliche Verbesserung

Ein Tool erzeugt keine Verfügbarkeit. Eine Architektur ermöglicht sie. Ein Betrieb erhält sie.

Eigene Position – bewusst kritisch betrachtet

Auch diese Sichtweise muss kritisch hinterfragt werden:

• Eigenbetrieb der Grundlast funktioniert nur, wenn Know-how und Betriebsdisziplin vorhanden sind.
• Redundanz verdoppelt nicht zwangsläufig die Kosten. Manche Cloud-Architekturen sind effizient gestaltet.
• Multi-Cloud kann Risiko reduzieren, aber schlechte Integration erhöht es dramatisch.
• Konsolidierung ist effizient, aber Abhängigkeit kann zum Risiko werden.

Die richtige Architektur hängt immer vom Kontext ab – Business, Kultur, Team, regulatorische Anforderungen und Risikoakzeptanz.

Am Ende gilt der Grundsatz: Strategy to life – Architecture to code.

Quellen

1. AWS-Ausfall – 20. Oktober 2025 The Guardian: „Amazon reveals cause of AWS outage“ https://www.theguardian.com/technology/2025/oct/24/amazon-reveals-cause-of-aws-outage

2. Azure-Ausfall – 29. Oktober 2025 Wursta: „When Azure Went Dark: Why Last Week’s Microsoft Outage Is a Wake-Up Call for IT Leaders“ https://wursta.com/when-azure-went-dark-why-last-weeks-microsoft-outage-is-a-wake-up-call-for-it-leaders

3. Cloudflare-Ausfall – 18. November 2025 AP News: „Cloudflare outage disrupts major websites including X and ChatGPT“ https://apnews.com/article/9335e8e0da2a0027d1fbac5eb97d11ae