Un service de tarification tiers communique avec des instances EC2 sur le port UDP 50000. Les réponses semblent parfois mal formées. Le fournisseur souhaite capturer les données de requête et de réponse à des fins de débogage en accédant à une instance EC2 qui communique avec le service de tarification, mais l'entreprise interdit l'accès direct à la production et exige une analyse dans un compte de surveillance distinct. Quelle séquence d'actions respecte ces contraintes et capture les données ?

La bonne réponse est la troisième option. Le Traffic Mirroring d'AWS permet de copier le trafic réseau d'une interface réseau élastique (ENI) vers une cible de surveillance. En créant un filtre pour le trafic UDP et en dirigeant ce trafic vers une instance EC2 dotée d'un outil d'inspection de paquets dans un compte de surveillance distinct, on respecte la contrainte de ne pas accéder directement à la production tout en permettant une analyse détaillée des paquets. La première option est incorrecte car les journaux de flux VPC ne capturent pas le contenu des paquets, seulement les métadonnées de flux (source, destination, port, protocole, etc.), ce qui ne permet pas de déboguer les réponses mal formées. La deuxième option est incorrecte car elle propose de déployer l'outil d'inspection de paquets dans le compte de production, ce qui va à l'encontre de la contrainte de l'entreprise interdisant l'accès direct à la production. La quatrième option est incorrecte car elle implique une connexion directe à l'instance de production pour exécuter tcpdump, ce qui est explicitement interdit par la politique de l'entreprise. De plus, attacher un nouveau volume EBS et le gérer manuellement est moins efficace et sécurisé que le Traffic Mirroring.