Eine öffentliche Webanwendung für den Einzelhandel verwendet einen Application Load Balancer (ALB) vor EC2-Instances in mehreren AZs und ein Amazon RDS MySQL Multi-AZ-Backend. Die Health Checks der Zielgruppe verwenden HTTP und verweisen auf die Produktkatalogseite. Auto Scaling verwaltet die Web-Flotte basierend auf ALB Health Checks. Kürzlich kam es zu einem Ausfall der Anwendung; Auto Scaling ersetzte wiederholt Instances, während die Webserver-Metriken normal aussahen. Die Untersuchung ergab, dass die Datenbank stark ausgelastet war und Abfragen sehr langsam waren. Welche zwei Änderungen zusammen beheben das Problem und verbessern die Überwachung der gesamten Anwendungsverfügbarkeit und -funktionalität für zukünftiges Wachstum? (Wählen Sie zwei.)

Die Änderung des ALB-Health-Checks auf eine statische HTML-Seite und das Hinzufügen eines Route 53 Health Checks für die Produktseite ist korrekt, da der ALB-Health-Check schnell und zuverlässig die Erreichbarkeit des Webservers prüfen sollte, ohne von der Datenbankleistung abhängig zu sein. Der Route 53 Health Check bietet dann eine End-to-End-Überwachung der gesamten Anwendungsverfügbarkeit, einschließlich der Datenbank. Das Bereitstellen eines Amazon ElastiCache-Clusters ist ebenfalls korrekt, da dies die Datenbanklast erheblich reduziert, indem häufig angefragte Daten im Cache gespeichert werden, was die Leistung verbessert und die Datenbank vor Überlastung schützt. Das Erstellen von Read Replicas ist eine gute Strategie zur Lastverteilung, aber die Webanwendung müsste angepasst werden, um sie zu nutzen, und es löst nicht das Problem der Überlastung der primären Datenbank durch Schreibvorgänge oder komplexe Abfragen, die nicht auf Replicas ausgelagert werden können. Ein CloudWatch-Alarm für RDS mit automatischer Wiederherstellung ist reaktiv und behebt nicht die Ursache der Datenbanküberlastung. Ein TCP-Check für den ALB-Health-Check ist zu rudimentär, da er nicht prüft, ob der Webserver antwortet.