6.5h outages due to cloud services automatic scaling chain reaction error propagations "Um 7:30 Uhr PST löste eine automatisierte Skalierung der Kapazität eines der im AWS-Hauptnetz gehosteten AWS-Services ein unerwartetes Verhalten bei einer großen Anzahl Clients im internen Netz aus. Genauer: Die Clients setzten ihre Anfragen aufgrund eines bisher unentdeckten Fehlers nicht wie sonst üblich zurück. Dies führte zu einem starken Anstieg des Netztraffic, der die Router zwischen dem internen und dem AWS-Hauptnetz überforderte und das Routing verzögerte. Die daraus resultierenden Latenzen und Fehler in der Kommunikation erhöhten ihrerseits die Zahl der wiederholten Anfragen von Systemen, die versuchten, ihre Verbindungen aufzubauen oder wiederherzustellen. Dieses sich Hochschaukeln in der Kommunikation führte zur anhaltenden Überlastung der Router.
Diese Überlastung hatte auch zur Folge, dass dem Operator-Team die Echtzeitmonitoringdaten nicht zur Verfügung standen, die es aber benötigte, um die Überlastungsquelle zu finden und zu beheben. Anhand der Logs identifizierte es zunächst eine erhöhte Fehlerzahl beim internen DNS. Da das aber die Grundlage aller Dienste darstellt und das Nichtbeantworten der DNS-Anfragen zur Überlastung beiträgt, konzentrierte sich das Team darauf, den internen DNS-Datenverkehr von den überlasteten Netzwerkpfaden wegzubewegen. Um 9:28 Uhr PST hatte es die DNS-Auflösungsfehler vollständig behoben. [..] Ein Service blockiert den nächsten Zudem kam es in der betroffenen Region bis 14:22 Uhr PST bei Kunden auch zu Anmeldefehlern auf der AWS-Konsole. Der Amazon Secure Token Service (STS) verzeichnete eine erhöhte Latenz beim Bereitstellen der Anmeldeinformationen für Drittanbieter von Identitäten über OpenID Connect (OIDC). Dies wiederum verursachte Anmeldefehler für andere AWS-Services wie Redshift, die STS zur Authentifizierung verwenden. Während sich die Latenz um 14:22 Uhr PST reduzierte, zu dem Zeitpunkt, als sich die Router beruhigten, war der STS erst um 16:28 Uhr PST vollständig wiederherstellt.
Kunden verzeichneten außerdem Verzögerungen bei der CloudWatch-Überwachung, was es ihnen erschwerte, die Auswirkungen auf ihre Anwendungen zu beurteilen. Eine kleine Menge der CloudWatch-Überwachungsdaten wurde nicht erfasst und kann in einigen Metriken fehlen. Nicht betroffen waren Zugriffe auf den Cloud-Storage-Dienst Amazon S3 und auf DynamoDB, beeinträchtigt waren allerdings Zugriffe auf AWS-S3-Buckets und DynamoDB-Tabellen über VPC-Endpunkte (Virtual Private Cloud).
Normal funktionierten die APIs des Datenverarbeitungsdienstes Lambda und Aufrufe von Lambda-Funktionen. Allerdings verzeichnete der AWS-API-Verwaltungsdienst API Gateway, der häufig zum Aufrufen von Lambda-Funktionen oder für Kundenanwendungen verwendet wird, viele Fehler, da die API-Gateway-Server nicht mit notwendigen Diensten im internen AWS-Netz kommunizieren konnten. Viele API-Gateway-Server froren dabei ein und hätten erneuert werden müssen. Der dabei verwendete automatische Wiederherstellungsprozess funktionierte aber nicht, bis die EC2-APIs wieder reibungslos funktionierten. "
