Am 7. Dezember kam es bei AWS zu diversen Schwierigkeiten. Ursache waren Probleme in der altehrwürdigen AWS-Region us-east-1, der ersten AWS-Region überhaupt. Doch was war passiert?
Einschränkungen bei wichtigen Diensten in us-east-1
In der betroffenen Region waren verschiedenste Dienste nicht in ihrer gewohnten Form nutzbar. Zeitweise war es nicht möglich, neue EC2-Instanzen zu starten, was ebenfalls Auswirkungen auf verschiedene andere Dienste hatte, die genau auf dieser Funktion beruhen. Darunter fielen laut Amazon Dienste wie RDS, Workspaces, Kubernetes-Umgebungen und andere Services. Durch die auftretenden Fehler und die daraus resultierenden Error-Meldungen der APIs wurde auch die Bereitstellung neuer Load Balancer in Mitleidenschaft gezogen. Kleiner Bonus: Die DNS-Dienste waren ebenfalls betroffen. Zwar wurden DNS-Namen ohne Probleme aufgelöst, doch war es nicht möglich, Einträge zu ändern.
Network Congestion als Ursache
Ursächlich war ein unvorhergesehenes Verhalten diverser Systeme in einem internen Netz, welches für Amazon-interne Dienste verwendet wird. Hierzu gehören beispielsweise Monitoring, internes DNS und einige weitere Dienste, insbesondere Backend-Funktionalitäten der oben genannten EC2-Dienste. Solche Dienste fallen bei den meisten unserer Kunden unter die Bereiche Management-Netze oder Global Services und sind durchaus üblich.
Ausgelöst wurde das Verhalten durch einen Skalierungsautomatismus, der eigentlich dafür sorgen soll, dass ausreichende Ressourcen zur Verfügung stehen. Doch führte dieser Automatismus zu einer starken Zunahme des Netzwerk-Traffics. Dadurch, dass auch das Monitoring über dieses Netzwerk kommuniziert, ergab sich dann ein interessanter Stolperstein bei der Fehleranalyse und -korrektur: Ein Zugriff auf das Monitoring, welches beim Troubleshooting hätte helfen können, war nicht möglich. Die Fehleranalyse musste also manuell stattfinden.
Hier hat sich ein Automatismus verselbständigt, der nicht vollständig verstanden oder getestet war. Das soll kein Vorwurf sein: In einer so großen Umgebung wie AWS ist es nahezu unmöglich, alle Auswirkungen eines Automatismus vollständig vorauszusehen. Amazon hat jetzt erst einmal den ursächlichen Automatismus abgeschaltet bis man weiß, was genau schiefgegangen ist.
Man muss, ähnlich wie beim Ausfall von Meta (ehemals Facebook) auch hier sagen: Hut ab davor, wie schnell Amazon das Problem in den Griff bekommen und sämtliche Dienste wiederhergestellt hat: innerhalb von knapp 7 Stunden. Hier scheint die immense Erfahrung durch, die Amazon beim Betrieb großer Cloud-Umgebungen hat. Nicht jedes Unternehmen erholt sich so schnell!
Fazit
Was kann man aus diesem Ereignis lernen? Ich sehe hier zwei wichtige Aspekte, die man sich vor Augen halten sollte:
- Der offensichtliche Punkt ist: Selbst beim größten Cloud-Anbieter kann mal etwas schiefgehen. Bei Amazon arbeiten auch nur Menschen, und die Automatismen und Werkzeuge werden ebenfalls von Menschen erstellt. Es hat hier viele, teilweise große Kunden erwischt, doch hielt sich der zeitliche Umfang in Grenzen.
- Der zweite Punkt, der für lokale Umgebungen eine wichtige Rolle spielt: Selbst die besten Automatismen können Fehler provozieren, mit denen niemand rechnet. Jeder Automatismus sollte sorgfältig überwacht und analysiert werden. Und eine solche Überwachung ist aufwendig. Das heißt insbesondere, dass man durch Automatisierung in der IT nicht mit weniger oder im „besten“ Fall ganz ohne Personal auskommt, sondern dass sich die Arbeit der Mitarbeiter nur verlagert.
Ein weiterer Aspekt ist der Zugriff auf das Monitoring: Der Ausfall bei AWS hat gezeigt, dass man sein Monitoring nicht nur aus der Umgebung erreichbar machen sollte, die es auch überwacht, sondern dass man ggf. über zusätzliche Zugriffskanäle nachdenken sollte.
