Un sitio web se ejecuta en cuatro instancias EC2 detrás de un ALB. Cuando el ALB marca una instancia como no saludable, una alarma de CloudWatch pasa al estado ALARM y un operador añade manualmente una instancia de reemplazo. La empresa desea una solución de alta disponibilidad que reemplace automáticamente las instancias EC2 fallidas, minimizando el tiempo de inactividad durante la migración al nuevo diseño. ¿Qué secuencia de pasos debe utilizar el arquitecto de soluciones?

La opción correcta permite una migración con tiempo de inactividad mínimo. Primero, se crea un grupo de Auto Scaling y una plantilla de lanzamiento para definir cómo se crearán las nuevas instancias. Luego, se adjunta este grupo al ALB existente, lo que asegura que el tráfico continúe fluyendo a las instancias actuales. Finalmente, se añaden las instancias EC2 existentes al grupo de Auto Scaling. Esto permite que Auto Scaling gestione las instancias actuales y lance automáticamente reemplazos si alguna falla, sin interrupción del servicio. Las opciones incorrectas implican eliminar componentes clave (ALB o instancias) antes de establecer la nueva configuración, lo que causaría tiempo de inactividad. La última opción incorrecta espera que el ALB registre las instancias existentes, lo cual no es el mecanismo correcto; las instancias deben ser añadidas explícitamente al grupo de Auto Scaling.