Die meisten von uns kennen Amazon am besten für seine E-Commerce-Dienste, mit denen wir heutzutage fast alles einfach über das Internet bestellen können – von Lebensmitteln über Kleidung bis hin zu Möbeln – mit kostenlosem Versand und nur wenigen Klicks auf Amazon Prime. Genau das machte Jeff Bezos zum (bis vor kurzem) reichsten Mann der Welt und streicht weiterhin das meiste Geld ein; aber Amazon macht viel, viel mehr als nur Einzelhandel.
Und letzten Dienstag verschwand ein Teil des Internets zusammen mit Amazon.com für eine Weile, als die Server von Amazon in Nord-Virginia (die über eines der größten und auch das erste AWS-Rechenzentrum aller Zeiten verfügen) einen unerwarteten Absturz erlitten. Die Ausfallzeit dauerte ungefähr sieben Stunden, beginnend gegen 7.30 Uhr PST und mit der vollständigen Wiederherstellung des Netzwerks um 14.22 Uhr PST.
Wie sich herausstellte, war es ein sehr ungewöhnlicher Absturz, der die AWS-Überwachungssysteme betraf, was laut Amazon die eigene Fähigkeit des technischen Rettungsteams, das Problem zu verstehen und zu diagnostizieren, in den ersten Stunden erheblich verzögerte. Darüber hinaus sagt Amazon, dass “die Netzwerküberlastung unsere Service Health Dashboard-Tools daran hinderte, angemessen auf unsere Standby-Region umzuschalten.”
Amazon sagt, dass es hart daran arbeitet, die Systeme zu aktualisieren, um zu verhindern, dass das Technikteam (und folglich die AWS-Kunden) mehr im Dunkeln tappt, sollten zukünftige technische Probleme oder Ausfälle auftreten.
Abgesehen davon, dass große Teile des Internets offline gesendet wurden, betraf der Ausfall von Amazon auch große Dienste wie Netflix, Disney+, Ticketmaster und andere.
Um 7.30 Uhr PST löste eine automatisierte Aktivität zur Skalierung der Kapazität eines der im AWS-Hauptnetzwerk gehosteten AWS-Services ein unerwartetes Verhalten einer großen Anzahl von Clients im internen Netzwerk aus. Dies führte zu einem starken Anstieg der Verbindungsaktivität, der die Netzwerkgeräte zwischen dem internen Netzwerk und dem AWS-Hauptnetzwerk überforderte, was zu Verzögerungen bei der Kommunikation zwischen diesen Netzwerken führte.
Diese Verzögerungen erhöhten Latenzzeiten und Fehler bei der Kommunikation zwischen diesen Netzwerken, was zu noch mehr Verbindungsversuchen und -wiederholungen führte. Dies führte zu anhaltenden Überlastungen und Leistungsproblemen auf den Geräten, die die beiden Netzwerke miteinander verbinden.
Diese Überlastung wirkte sich sofort auf die Verfügbarkeit von Echtzeit-Überwachungsdaten für unsere internen Betriebsteams aus, was ihre Fähigkeit beeinträchtigte, die Überlastungsquelle zu finden und zu beheben.
Die Betreiber verließen sich stattdessen auf Protokolle, um zu verstehen, was passierte, und identifizierten zunächst erhöhte interne DNS-Fehler. Da das interne DNS die Grundlage für alle Dienste darstellt und dieser Datenverkehr vermutlich zur Überlastung beiträgt, konzentrierten sich die Teams darauf, den internen DNS-Datenverkehr von den überlasteten Netzwerkpfaden wegzubewegen. Um 9:28 Uhr PST schloss das Team diese Arbeit ab und die DNS-Auflösungsfehler wurden vollständig behoben. […]
Dieser Codepfad ist seit vielen Jahren in Produktion, aber die automatisierte Skalierungsaktivität löste ein zuvor unbeobachtetes Verhalten aus. Wir entwickeln eine Lösung für dieses Problem und gehen davon aus, diese Änderung in den nächsten zwei Wochen bereitzustellen. Wir haben auch zusätzliche Netzwerkkonfigurationen bereitgestellt, die potenziell betroffene Netzwerkgeräte selbst bei einem ähnlichen Überlastungsereignis schützen. Diese Korrekturen geben uns die Zuversicht, dass dieses Problem nicht erneut auftritt.