Una empresa financiera aloja un data lake en Amazon S3. Cada noche, varios terceros suben datos financieros a través de SFTP. Actualmente, la empresa ejecuta su propio servidor SFTP en una instancia EC2 en una subred pública; un trabajo cron en esa instancia mueve los archivos subidos al data lake. Se puede acceder al servidor SFTP en sftp.example.com a través de Amazon Route 53. ¿Cómo debería un arquitecto de soluciones mejorar la fiabilidad y la escalabilidad de esta solución SFTP?

La opción correcta es migrar el servidor SFTP a AWS Transfer for SFTP y actualizar el registro DNS. AWS Transfer Family es un servicio completamente gestionado que soporta SFTP, FTPS y FTP, proporcionando alta disponibilidad, escalabilidad y durabilidad sin necesidad de gestionar servidores. Esto mejora significativamente la fiabilidad y escalabilidad en comparación con una instancia EC2 autogestionada. Las otras opciones son incorrectas porque: Mover la instancia EC2 a un grupo de Auto Scaling y usar un ALB no es adecuado para SFTP, ya que ALB opera en la capa 7 (HTTP/HTTPS) y SFTP es un protocolo de capa 4. Migrar a un file gateway de AWS Storage Gateway no es una solución para servir SFTP directamente a terceros; está diseñado para integrar almacenamiento on-premises con S3. Colocar la instancia EC2 detrás de un NLB mejoraría la escalabilidad de red, pero aún requeriría gestionar la instancia EC2 subyacente, lo que no resuelve la gestión del servidor ni la fiabilidad inherente de un servicio gestionado.