Alle EC2-Instances in einer Auto Scaling-Gruppe hinter einem Application Load Balancer haben aufgehört, Traffic zu bedienen, und fallen bei den HTTP-Zielgruppen-Health-Checks durch. Der Anwendungsprozess läuft nicht, und die Systemprotokolle zeigen viele Out-of-Memory-Fehler. Welche Kombination von Maßnahmen sollten Sie ergreifen, um die Ausfallsicherheit gegenüber einem möglichen Speicherleck zu verbessern und Monitoring/Alarme zu ermöglichen? (Wählen Sie zwei.)

Die Änderung der Auto Scaling-Gruppe zur automatischen Ersetzung von Instances, die Load Balancer-Health-Checks nicht bestehen, ist entscheidend. Dies stellt sicher, dass fehlerhafte Instances, die aufgrund des Speicherlecks ausfallen, automatisch beendet und durch neue, funktionierende Instances ersetzt werden, was die Verfügbarkeit der Anwendung verbessert. Das Installieren und Konfigurieren des CloudWatch-Agenten auf den EC2-Instances ermöglicht das Sammeln detaillierter Metriken zur Speicherauslastung (z.B. memusedpercent). Ein Alarm bei hoher Speichernutzung, gekoppelt mit einem SNS-Thema, warnt proaktiv vor einem drohenden Speicherleck, bevor es zu einem Ausfall kommt. Dies ermöglicht eine frühzeitige Intervention. Das Reduzieren von HealthCheckIntervalSeconds würde die Erkennung beschleunigen, aber nicht die Ursache beheben oder proaktiv warnen. Das Ändern der Health Checks auf TCP würde den Fehler nicht erkennen, da der Port möglicherweise offen ist, die Anwendung aber nicht reagiert. Die Aktivierung einer Metrik für den verfügbaren Speicherverbrauch in der CloudWatch-Konsole für die gesamte Auto Scaling-Gruppe ist nicht möglich, da CloudWatch standardmäßig keine detaillierten Speichermetriken für EC2-Instances sammelt; dafür ist der CloudWatch-Agent erforderlich.