Un fournisseur SaaS sur site accepte plusieurs fichiers par jour via plusieurs points de terminaison SFTP publics. Les clients ont ajouté les adresses IP des points de terminaison SFTP à leurs listes d'autorisation de pare-feu sortant et ne peuvent pas modifier ces adresses IP autorisées. L'entreprise souhaite migrer vers AWS et réduire les frais opérationnels tout en conservant les adresses IP sources existantes que les clients autorisent. Quelle solution répond à ces exigences ?

La bonne réponse est d'utiliser BYOIP (Bring Your Own IP) pour importer le bloc d'adresses IP existant dans AWS, puis d'allouer des adresses IP Elastic à partir de ce pool et de les attribuer à un point de terminaison AWS Transfer for SFTP. Cela permet de conserver les adresses IP sources que les clients ont déjà autorisées dans leurs pare-feu, répondant ainsi à l'exigence clé. AWS Transfer for SFTP est un service entièrement géré qui réduit les frais opérationnels et peut stocker les fichiers directement dans Amazon S3, offrant ainsi une solution évolutive et rentable. Les autres options sont incorrectes car : L'ajout d'un sous-réseau avec des adresses IP client à un VPC n'est pas une fonctionnalité standard et ne permet pas d'utiliser les adresses IP publiques existantes pour un service externe. L'utilisation d'EC2 avec EBS augmente la charge opérationnelle. L'enregistrement d'un bloc d'adresses IP auprès de Route 53 ne permet pas de les utiliser comme adresses IP publiques pour un service SFTP directement. Un NLB avec EC2 et S3 est une option viable pour le stockage, mais ne résout pas le problème de la conservation des adresses IP sources. Un point de terminaison VPC S3 est pour l'accès interne à S3 et ne prend pas en charge SFTP directement pour les clients externes. S3 lui-même n'offre pas de fonctionnalité SFTP native.