Ausfall bei AWS: Wenn Managementclients Produktivsysteme lahmlegen

Tausendmal geht es gut und einmal nicht: Weil eine große Zahl Clients in einem Managementnetz unerwartet die übliche Reaktion auf eine erprobte automatische Skalierung vermissen ließ, gingen bei AWS über Stunden zentrale Cloud-Dienste in die Knie – und das Monitoring gleich mit. Auch die Dienste vieler Kunden waren zeitweise nicht erreichbar.

Als Anfang Dezember etliche Services der AWS-Cloud-Site US-EAST-1 in der Region Northern Virginia ausfielen, standen Operatoren- und Supportteams vor einer schier unlösbaren Aufgabe: Überlastete Router zwischen AWS-Netz und internem Managementnetz hinderten nicht nur die AWS-Dienste an ihrer Ausführung, sondern auch das Service Health Dashboard daran, ordnungsgemäß auf die Stand-by-Region umzuschalten und die Kunden umzuleiten. Da die ebenfalls betroffenen Monitoringsysteme zudem keine validen Daten mehr lieferten, glich die Suche nach der Fehlerursache der nach der Nadel im Heuhaufen. Und während Kunden ihre Cloud-Ressourcen nicht mehr verwalten konnten und auf Feedback von AWS warteten, konnte dessen Support-Center, das sich ebenfalls auf das betroffene interne Netz stützt, an diesem 7. Dezember sieben Stunden lang weder Auskunft zu Ursache und Dauer der Ausfälle geben noch Tickets erstellen.

Wie stark die Kunden von der siebenstündigen Störung betroffen waren, hing vor allem von ihrem Standort ab: Während in den USA teils nichts mehr zu funktionieren schien, war der Rest der IT-Welt weitaus weniger betroffen. Ganz vorne auf der Liste der Vermissten: Bei Netflix und Disney+ fiel in den USA das Videostreaming aus, bei Amazon Prime stapelten sich ohne dessen interne Apps wie Flex und A to Z die Pakete und auch andere Amazon-Angebote wie das Securitysystem Ring funktionierten nicht mehr. Alles in allem ist Amazons größte Cloud-Site US-EAST-1 bedeutend genug, dass Ökonomen bei einem längeren Ausfall spürbare wirtschaftliche Konsequenzen befürchten.

Weltweit konnten sich Kunden nicht an der AWS Management Console anmelden, denn deren globale Version ist ebenfalls hier beheimatet. Erst ein Ausweichen auf eine der regionalen Varianten half. Betroffen waren unter anderem auch die Dienste EC2, Connect, DynamoDB, Glue, Athena, Timestream und Chime.

Die Erklärungen nach außen beschränkten sich auf allgemeine Notizen im AWS Service Health Dashboard zu „API Error Rates in US-EAST-1“ (siehe Abbildung 3). Details zu den Ausfällen folgten Tage später. In seinem ausführlichen Bericht entschuldigt sich AWS nicht nur für die teils erheblichen Auswirkungen, die die Ausfälle für die Kunden hatten, sondern vor allem auch für das Ausbleiben von Informationen, durch das sich viele Kunden im Regen stehen gelassen sahen.

Systeme schaukeln sich gegenseitig hoch

Vorab zur Einordnung: AWS nutzt sein internes Managementnetz für die grundlegenden Netzwerkservices einschließlich Monitoring, des internen DNS, Autorisierungsdiensten und Teilen der EC2-Steuerungsebene, während die Mehrheit der AWS-Services und alle Kundenanwendungen innerhalb des AWS-Hauptnetzes laufen. Aufgrund der hohen Bedeutung der internen Netzwerkdienste hat AWS dieses interne Netz mit mehreren geografisch isolierten Netzwerkgeräten verbunden und skaliert die Kapazität dieses Netzes weitreichend, um dessen Verfügbarkeit möglichst hoch zu halten. Diese Netzwerkgeräte übernehmen neben Routing- auch DNS-Aufgaben, damit AWS-Services mit internen Diensten kommunizieren können.