Automatisierung von Chaos-Engineering-Failover-Tests in AWS-CI/CD-Pipelines

Ein detailliertes technisches Tutorial, veröffentlicht am 2. November 2026, demonstriert, wie automatisierte Zuverlässigkeitstests direkt in Continuous-Integration- und Deployment-Workflows eingebettet werden können. Der Leitfaden, verfasst von Gbenga Ogbonyenitan für die DEV Community, führt Ingenieure Schritt für Schritt durch die Nutzung des AWS Fault Injection Service (FIS), um Container-Tasks gezielt zu stoppen und sicherzustellen, dass das System innerhalb akzeptabler Zeitlimits wiederhergestellt wird.

Was passiert ist

Der Artikel bietet eine schrittweise Implementierung eines Chaos-Engineering-Musters, bei dem eine Pipeline einen Dienst bereitstellt, absichtlich eine seiner laufenden Komponenten zerstört und anschließend validiert, ob die Infrastruktur sich selbst heilt. Das Setup nutzt Amazon ECS (Elastic Container Service) mit Fargate, einen Application Load Balancer sowie AWS CodePipeline. Die Kerninnovation besteht darin, eine „FailoverTest“-Phase hinzuzufügen, die nach dem Deployment ausgeführt wird und sicherstellt, dass jedes Release durch einen Nachweis der Resilienz begleitet wird.

Der Prozess umfasst zwei Hauptphasen: den Aufbau der zugrunde liegenden Dienstinfrastruktur und die Konfiguration des Injektionsmechanismus. Zunächst richtet der Ingenieur Sicherheitsgruppen, Zielgruppen und den Lastverteiler ein, um den Datenverkehr zu handhaben. Anschließend konfiguriert er FIS so, dass es bestimmte ECS-Tasks anvisiert. Das Tutorial betont, dass es nicht nur darum geht, Dinge kaputtzumachen, sondern die Wiederherstellungszeit gegen einen vordefinierten Schwellenwert, beispielsweise 300 Sekunden, zu messen. Wenn der Dienst innerhalb dieses Zeitfensters nicht in einen gesunden Zustand zurückkehrt, schlägt die Pipeline fehl, wodurch verhindert wird, dass potenziell instabile Konfigurationen als erfolgreich eingestuft werden.

Der Autor merkt an, dass die Demo zwar einen einfachen nginx-Webserver verwendet, das Muster jedoch für reale Anwendungen konzipiert ist. Durch die Automatisierung dieses Tests wechseln Teams davon, anzunehmen, dass ihr Hochverfügbarkeitsdesign funktioniert, dazu, dies bei jedem einzelnen Release nachzuweisen. Der Leitfaden enthält sowohl einen manuellen Ansatz über die Konsole zum Lernen als auch einen CloudFormation-basierten Ansatz für produktionsreife Infrastruktur als Code.

Wichtige Details

• Die Pipeline besteht aus drei Phasen: Source, Deploy und FailoverTest, wobei die letzte Phase das Chaos-Experiment ausführt.
• Der AWS Fault Injection Service ist so konfiguriert, dass er genau einen Task in einem ECS-Dienst mit zwei Tasks stoppt, um während des Tests eine teilweise Verfügbarkeit sicherzustellen.
• Ein benutzerdefiniertes Skript, das in AWS CodeBuild läuft, prüft Vorbedingungen, startet das FIS-Experiment, wartet auf dessen Abschluss und validiert die Wiederherstellungsmetriken.
• Die Validierung der Wiederherstellung erfordert, dass sowohl die Anzahl der laufenden ECS-Tasks als auch die Anzahl der gesunden Ziele im Lastverteiler dem gewünschten Zustand entsprechen.
• Das Experiment nutzt einen CloudWatch-Alarm als Stoppbedingung zur Überwachung gesunder Hosts, obwohl die primäre Sicherheitskontrolle darin besteht, den Fehler auf einen Task zu begrenzen.
• Aufräumskripte werden bereitgestellt, um Ressourcen zu behandeln, die nicht von CloudFormation-Stacks verwaltet werden, wie etwa Protokollgruppen und Revisionen von Task-Definitionen.

Hintergrund

Chaos Engineering ist die Disziplin, Experimente an einem System durchzuführen, um Vertrauen in seine Fähigkeit zu gewinnen, turbulenten Bedingungen in der Produktion standzuhalten. Traditionell könnte dies manuelle „Game Days“ oder separate Testumgebungen beinhalten. Die Integration in CI/CD bringt diese Tests näher an die Codeänderungen heran und fängt Regressionen in der Resilienzlogik frühzeitig ab. Der AWS Fault Injection Service ist ein verwalteter Dienst, der hilft, diese Experimente sicher durchzuführen, indem er Umfänge, Aktionen und Stoppbedingungen definiert.

In diesem Kontext bezieht sich „Failover“ auf den automatischen Ersatz eines fehlgeschlagenen Container-Tasks durch den ECS-Scheduler. Wenn ein Task stoppt, erkennt der Dienst die Diskrepanz zwischen der gewünschten Anzahl und der laufenden Anzahl, startet einen neuen Task und registriert ihn beim Lastverteiler. Der Test überprüft, ob dieser gesamte Zyklus ohne menschliches Eingreifen und innerhalb eines Zeitrahmens abgeschlossen wird, der den Service Level Objectives entspricht.

Warum es wichtig ist

Für Teams, die Self-Hosted-Software oder interne Plattformen verwalten, wird Zuverlässigkeit oft vorausgesetzt, statt getestet. Designdokumente mögen behaupten, dass ein Dienst hochverfügbar ist, aber Konfigurationsdrift, Berechtigungsfehler oder Netzwerkrichtlinien können Failover-Mechanismen stillschweigend brechen. Durch die Automatisierung dieses Tests wandeln Ingenieure abstrakte Designbehauptungen in konkrete Bestehen/Nicht-Bestehen-Prüfungen um. Dies reduziert das Risiko, Wiederherstellungsfehler während tatsächlicher Ausfälle zu entdecken, wenn die Einsätze am höchsten sind.

Darüber hinaus unterstreicht dieser Ansatz die Bedeutung von Recovery Time Objectives. Es reicht nicht aus, dass ein Dienst irgendwann wieder online kommt; er muss dies schnell genug tun, um die Nutzererwartungen zu erfüllen. Die Pipeline erzwingt ein strenges Timeout, was Teams zwingt, ihre Health-Check-Intervalle, Container-Startzeiten und Abmeldeverzögerungen des Lastverteilers zu optimieren. Dies verschiebt das Reliability Engineering von einer reaktiven Post-Mortem-Aktivität zu einer proaktiven Entwicklungsanforderung.

Die Implementierung erfordert jedoch ein sorgfältiges Berechtigungsmanagement. Das Tutorial beschreibt mehrere häufige Fallstricke, wie fehlende IAM-Berechtigungen für die Erstellung dienstverknüpfter Rollen oder falsche ARNs für Zielgruppen. Diese Details unterstreichen, dass Chaos Engineering neue operative Komplexitäten einführt, die neben standardmäßigen Bereitstellungsaufgaben verwaltet werden müssen.

Was Sie tun können

• Überprüfen Sie Ihre aktuellen CI/CD-Pipelines, um festzustellen, wo Resilienztests als Phase nach dem Deployment hinzugefügt werden könnten.
• Beginnen Sie mit einer Nicht-Produktionsumgebung, um die FIS-Integration zu testen, und stellen Sie sicher, dass Sie die Fehlermodi verstehen, bevor Sie Live-Datenverkehr berühren.
• Definieren Sie klare Recovery Time Objectives für Ihre kritischen Dienste und verwenden Sie diese als Timeout-Schwellenwert in Ihren automatisierten Tests.
• Prüfen Sie Ihre IAM-Rollen, um sicherzustellen, dass Ihre Build-Agenten über die minimal erforderlichen Berechtigungen verfügen, um FIS-Experimente zu starten und den ECS-Status abzufragen.
• Implementieren Sie Vorprüfungen in Ihren Testskripten, um sicherzustellen, dass das System gesund ist, bevor Fehler injiziert werden, um falsch-positive Ergebnisse aufgrund bestehender Probleme zu vermeiden.
• Dokumentieren Sie das erwartete Verhalten Ihrer Dienste während teilweiser Ausfälle und nutzen Sie diese Tests, um diese Erwartungen kontinuierlich zu validieren.