Una empresa actualmente sirve archivos a través de un servidor SFTP accesible por internet que se ejecuta en una única instancia EC2 con una Elastic IP adjunta. Los clientes se conectan utilizando esa Elastic IP y SSH. El grupo de seguridad de la instancia EC2 permite el acceso desde todas las direcciones IP de los clientes. El arquitecto de soluciones debe mejorar la disponibilidad, reducir la complejidad de la gestión de la infraestructura y minimizar las interrupciones para los clientes, sin cambiar la forma en que los clientes se conectan. ¿Qué solución cumple con estas restricciones?

La opción correcta mejora la disponibilidad y reduce la complejidad al migrar el servidor SFTP a AWS Transfer Family, un servicio totalmente gestionado. Al usar un endpoint alojado en VPC con acceso a internet y asociar la Elastic IP existente, los clientes pueden seguir conectándose sin cambios. El uso de S3 como almacenamiento backend proporciona durabilidad y escalabilidad. Sincronizar los archivos existentes asegura la continuidad del servicio. La primera opción es incorrecta porque un endpoint de acceso público de Transfer Family no permite asociar una Elastic IP existente directamente, ni aplicar un grupo de seguridad específico para clientes, lo que no mantiene la forma de conexión ni la seguridad actual. La tercera opción es incorrecta porque usar Fargate con EFS y un NLB introduce una mayor complejidad de gestión que Transfer Family, y la sincronización de archivos con S3 no es el almacenamiento principal en esta configuración. La cuarta opción es incorrecta porque los volúmenes EBS de conexión múltiple no están diseñados para ser el almacenamiento principal de un servidor SFTP escalable y no ofrecen la misma durabilidad y simplicidad que S3 con Transfer Family. Además, un grupo de Auto Scaling con EBS de conexión múltiple es una solución más compleja y menos gestionada que Transfer Family.