Zwei konfigurationsbedingte Ausfälle im Abstand eines Jahres: CloudFront und 1.1.1.1
Am vergangenen Donnerstag, dem 16. Juli, begann AWS CloudFront für jede Distribution mit VPC Origins 5xx-Fehler zurückzugeben – und tat das von 07:45 bis 11:18 UTC: drei Stunden und dreiunddreißig Minuten. AWS nannte als Ursache „eine interne Beschränkung in der Flotte, die die Verbindungen zu privaten VPC-Ursprüngen verwaltet“, wodurch diese Flotte ihre aktualisierte Netzkonfiguration nicht laden konnte. 1 Distributionen mit anderen Ursprungstypen blieben unberührt, doch CloudFront sitzt vor einem so großen Teil des Internets, dass eine einzige ausfallende Funktion Dienste wie Canvas, Blackboard, Hugging Face und Ubiquiti lahmlegte oder beeinträchtigte. 2
Zwei Tage zuvor, am 14. Juli, verging weitgehend unkommentiert der erste Jahrestag eines Ausfalls derselben Bauart. 2025 war Cloudflares öffentlicher DNS-Resolver 1.1.1.1 62 Minuten lang dunkel. Ein Dienst der Data Localization Suite war Anfang Juni in einer Vorproduktionsumgebung versehentlich mit den 1.1.1.1-Präfixen verknüpft worden; der Fehler ruhte, bis eine zweite Änderung einen Offline-Teststandort hinzufügte und eine globale Konfigurationsaktualisierung auslöste, die diese Präfixe in sämtlichen Rechenzentren von Cloudflare gleichzeitig zurückzog. Entgegen den damaligen Spekulationen war es kein BGP-Hijack. Cloudflares Aufarbeitung sagt ausdrücklich, dass die eigene Automatisierung die Routen zurückgezogen hat. 3
Keine Glasfaser wurde durchtrennt. Kein Rechenzentrum brannte. In beiden Fällen waren die Maschinen in Ordnung, und die Anweisungen waren falsch.
Die Steuerungsebene ist heute der zerbrechliche Teil
Wir haben dieses Jahr viel über physische Ausfälle geschrieben: die Ereignisse bei AWS im Nahen Osten im März, den Glasfaserschnitt bei Zayo, der am 22. Juni die halbe Anwendungswelt beeinträchtigte, Seekabel überhaupt. Die sind leicht zu verstehen und auf sonderbare Weise tröstlich. Ein Kabel ist ein Ding, und Dinge kann man doppelt auslegen.
Die Verteilung von Konfiguration ist schwieriger – aus strukturellen Gründen, nicht aus Gründen der Kompetenz.
Sie ist von Natur aus global. Der ganze Wert einer verteilten Konfigurationsebene liegt darin, dass eine Änderung schnell überall ankommt – genau die Eigenschaft, die eine schlechte Änderung schnell überall ankommen lässt.
Sie ist zugleich der Wiederherstellungsweg. Ist Ihr Konfigurationssystem krank, ist der Mechanismus, mit dem Sie normalerweise reparieren würden, genau der kaputte. Physische Redundanz hilft hier nicht: Sie haben reichlich funktionierende Server, die alle gehorsam das Falsche tun.
Und sie hat keine natürliche Grenze für den Wirkungsradius. Regionen und Availability Zones begrenzen physische Ausfälle. Eine Flotte innerhalb von CloudFront konnte eine Konfiguration nicht laden – und die Fehler waren weltweit. Ein Konfigurations-Push hält sich an diese Grenzen nur, wenn jemand ihn so gebaut hat, und gestaffelte Ausrollung ist genau die Disziplin, die unter Lieferdruck still erodiert.
DNS ist dieselbe Geschichte eine Schicht höher. Eine zurückgezogene Route ist eine Konfigurationsaussage. Der Resolver war gesund; er war nicht mehr erreichbar, weil dem Netz gesagt wurde, er sei nicht da.
Fünf Gewohnheiten, die es zu übernehmen lohnt
Das Unbequeme daran: Das sind zwei der betrieblich versiertesten Organisationen im Internet. Wenn verteilte Konfiguration diese beiden beißt, ist der Ansible-Lauf eines gewöhnlichen Teams am Freitag um 17 Uhr nicht irgendwie sicherer.
Rollen Sie alles gestaffelt aus, Konfiguration eingeschlossen. Erreicht eine Änderung 100 % Ihrer Flotte auf einmal, ist Ihr Wirkungsradius global – egal, wie viele Regionen Sie betreiben.
Halten Sie einen Wiederherstellungsweg bereit, der die Konfigurationsebene nicht benutzt: Konsolenzugriff, einen statischen Rückfall, eine von Hand editierbare Datei – irgendetwas, das funktioniert, wenn die Automatisierung es nicht tut.
Kaufen Sie Ihr autoritatives DNS nicht bei dem Anbieter, hinter dem Sie Ihren Ursprungsserver verstecken. Hat dieser Anbieter einen schlechten Tag, nimmt er Ihnen in einem Zug das Problem und die Möglichkeit, es zu umgehen.
Richten Sie einen zweiten rekursiven Resolver ein, öffentlich wie intern. Der Juli 2025 ist das Argument dafür: Ein Resolver kann völlig gesund und trotzdem unerreichbar sein, ein zweiter kostet nichts – und wenn die Auflösung scheitert, ist alles andere, was Sie gebaut haben, gleichgültig.
Und kennen Sie Ihre Rollback-Zeit, gemessen statt geschätzt. „Wir können zurückrollen“ ist kein Plan, bevor jemand die Zeit gestoppt hat.
Ein Weg hinein, wenn die Automatisierung versagt
Wir sind ein kleiner ISP und werden nicht so tun, als wäre unsere Konfigurationsebene ausgefeilter als die von Cloudflare. Sie ist kleiner, was die Abwägungen verschiebt statt sie zu entscheiden – und gelegentlich zu unseren Gunsten ausfällt: weniger bewegliche Teile, weniger Stellen, an denen ein globaler Push global schiefgehen kann.
Was wir Kundinnen und Kunden geben, ist das, worauf es bei einem Vorfall dieser Bauart ankommt: ein Weg hinein, der nicht davon abhängt, dass unsere Automatisierung gesund ist.
Jeder VPS und VDS in unserem aktuellen Katalog hat im Kundenbereich Konsolenzugriff über noVNC, unabhängig vom Netzwerk des Gastes. Wenn die Netzkonfiguration falsch ist, die Firewall Sie ausgesperrt hat oder die Maschine den Start nicht zu Ende bringt, bekommen Sie einen Bildschirm und eine Tastatur. Kein SSH nötig, kein Ticket, keine Zugangsdaten an irgendwen.
Vollständiges KVM mit Root-Zugriff heißt, Sie können die Maschine selbst wiederherstellen, ohne darauf zu warten, dass ein Anbieter eine Korrektur in ein Control Panel schiebt, an dem Sie nicht vorbeikommen. Und das Looking Glass lässt Sie unser Routing selbst prüfen – aus Tirana, Skopje, Amsterdam und Dublin –, statt einer Statusseite glauben zu müssen.
Dazu der stehende Rat, den wir wiederholen, weil er sich immer wieder bewährt: Stellen Sie einen VPS für 5 €/Monat irgendwohin, wo er keine Steuerungsebene mit Ihrem Hauptsystem teilt. Nicht in eine andere Region desselben Anbieters, sondern zu einem anderen Anbieter in einem anderen Land. An beiden dieser Tage wäre das die Maschine gewesen, die Ihren Nutzern noch hätte sagen können, was los ist.
Der Trend, den man im Auge behalten sollte
Die meisten Ausfallmeldungen dieses Jahres waren physisch: die Störung bei AWS im Nahen Osten im März, der Glasfaserschnitt bei Zayo im Juni. Die vom vergangenen Donnerstag war es nicht – und die, deren Jahrestag sie beinahe teilte, ebenso wenig. Die Branche hat zwanzig Jahre darauf verwendet, Hardwareausfälle zu überstehen, und vergleichsweise wenig Mühe darauf, die eigenen Anweisungen zu überstehen.
Das Fehlerbild eines gut konstruierten verteilten Systems ist zunehmend nicht, dass es kaputtgeht. Es ist, dass es einwandfrei funktioniert, überall, mit der falschen Eingabe.