Ein Unternehmen betreibt eine Anwendung auf EC2-Instances in einer Auto Scaling-Gruppe hinter einem Application Load Balancer (ALB). Beim Start führen die Instances User-Data-Skripte aus, um kritische Anwendungsinhalte aus einem S3-Bucket herunterzuladen. Die Instances werden gestartet, aber nach einiger Zeit mit der Meldung „An instance was taken out of service in response to an ELB system health check failure“ beendet. Auto Scaling startet und beendet Instances wiederholt in einer Schleife. Die einzige kürzliche Änderung war das Hinzufügen einer großen Menge kritischer Inhalte zum S3-Bucket. Das Unternehmen möchte die User-Data-Skripte in der Produktion nicht ändern. Was sollte ein Solutions Architect tun, damit die Produktionsumgebung erfolgreich bereitgestellt werden kann?

Die Erhöhung der Kulanzperiode für den Health Check der Auto Scaling-Gruppe ist die richtige Lösung. Die Instances werden beendet, weil sie den Health Check des ALB nicht rechtzeitig bestehen. Dies geschieht, weil die User-Data-Skripte nach dem Hinzufügen einer großen Menge kritischer Inhalte zum S3-Bucket länger zum Herunterladen benötigen. Die Kulanzperiode gibt den Instances mehr Zeit, um die Startskripte auszuführen und die Anwendung betriebsbereit zu machen, bevor der ALB mit den Health Checks beginnt. Die Erhöhung der EC2-Instance-Größe würde die Downloadzeit nicht wesentlich verkürzen und ist keine direkte Lösung für das Timeout-Problem. Das Ändern des ALB-Health-Check-Timeout-Werts würde den ALB anweisen, länger auf eine Antwort zu warten, aber die Kulanzperiode ist spezifischer für die Startphase der Instance. Das Ändern des Health-Check-Pfads würde das Problem nicht lösen, da die Anwendung noch nicht bereit ist, auf Anfragen zu antworten.