Una empresa está migrando un sitio web que consta de un balanceador de carga, un CMS basado en Linux que requiere almacenamiento persistente compatible con NFS y una base de datos MySQL. La solución debe escalar de 2 instancias EC2 a 30 instancias para tráfico impredecible, no requerir cambios en el CMS y evitar la pérdida de datos. ¿Qué diseño cumple con estos requisitos?

La opción correcta cumple con todos los requisitos. Amazon EFS proporciona almacenamiento persistente compatible con NFS que puede ser montado por múltiples instancias EC2, lo cual es crucial para el CMS y su escalabilidad. Elastic Beanstalk con un Application Load Balancer y Auto Scaling maneja la escalabilidad de las instancias EC2 de forma automática. El uso de .ebextensions permite montar EFS sin cambios en el CMS. Amazon Aurora MySQL ofrece alta disponibilidad y escalabilidad para la base de datos. La opción de Amazon EBS Multi-Attach no es adecuada porque EBS Multi-Attach está diseñado para acceso de escritura simultáneo desde múltiples instancias en un escenario de clúster de alta disponibilidad, no para compartir un sistema de archivos como NFS, y no es compatible con el requisito de NFS. Además, un Network Load Balancer es para tráfico a nivel de red, no para HTTP/HTTPS, que es típico de un sitio web. La opción con un Network Load Balancer y un "scale-in lifecycle hook para montar el sistema de archivos EFS" es incorrecta porque el montaje de EFS debe ocurrir durante el inicio de la instancia, no durante un evento de reducción, y un NLB no es lo ideal para un sitio web. La opción con Amazon EBS Multi-Attach y Amazon ElastiCache for Redis es incorrecta porque ElastiCache es una caché en memoria, no un reemplazo para una base de datos MySQL persistente, y EBS Multi-Attach no satisface el requisito de NFS.