Todas las instancias EC2 de un grupo de Auto Scaling detrás de un Application Load Balancer han dejado de servir tráfico y están fallando las comprobaciones de estado del grupo objetivo HTTP. El proceso de la aplicación no se está ejecutando y los registros del sistema muestran muchos errores de falta de memoria. Para mejorar la resiliencia contra una posible fuga de memoria y habilitar la monitorización/alertas, ¿qué combinación de acciones debería tomar? (Elija dos.)

La primera acción correcta es modificar el grupo de Auto Scaling para reemplazar automáticamente las instancias que fallan las comprobaciones de estado del balanceador de carga. Esto asegura que las instancias con problemas (como las que no sirven tráfico debido a errores de memoria) sean terminadas y reemplazadas por instancias nuevas y saludables, restaurando la funcionalidad de la aplicación. La segunda acción correcta es instalar y configurar el agente de Amazon CloudWatch en las instancias EC2 para recopilar métricas de utilización de memoria. Esto permite monitorear el consumo de memoria a nivel de instancia, crear alarmas para detectar un uso elevado de memoria (indicando una posible fuga de memoria) y recibir notificaciones a través de SNS, lo que es crucial para la resiliencia y la detección proactiva de problemas. Reducir HealthCheckIntervalSeconds no soluciona la causa raíz del problema ni mejora la resiliencia. Cambiar a comprobaciones de estado TCP es menos efectivo para detectar problemas a nivel de aplicación que las comprobaciones HTTP. Habilitar una métrica de consumo de memoria disponible en la consola de CloudWatch para todo el grupo de Auto Scaling no es una opción válida, ya que CloudWatch no recopila métricas de memoria de forma predeterminada sin el agente.