Une entreprise utilise une connexion dédiée Direct Connect de 4 Gbit/s (LAG) pour se connecter à cinq VPC dans us-east-1. Chaque VPC utilise sa propre interface virtuelle privée (VIF) vers le réseau sur site. Les utilisateurs signalent des ralentissements et l'ingénieur remarque des pics de débit qui saturent le Direct Connect pendant environ une heure chaque jour ouvrable. L'entreprise doit identifier quelle unité commerciale est à l'origine du pic et résoudre la saturation. Quelle approche répond à ces exigences?

L'option correcte permet d'abord d'identifier la source du pic de trafic en examinant les métriques CloudWatch VirtualInterfaceBpsEgress et VirtualInterfaceBpsIngress pour chaque VIF, ce qui est essentiel pour déterminer quelle unité commerciale est responsable. Ensuite, elle propose une solution évolutive en provisionnant une nouvelle connexion Direct Connect dédiée de 10 Gbit/s. Cela permet de résoudre la saturation actuelle et d'offrir une capacité suffisante pour l'avenir, tout en évitant une interruption de service car le trafic peut être transféré progressivement. Les options incorrectes échouent pour plusieurs raisons : Mettre à niveau la connexion existante à 10 Gbit/s (option 2) peut entraîner une interruption de service pendant la mise à niveau. Utiliser ConnectionBpsIngress et ConnectionPpsEgress (options 3 et 4) n'est pas granulaire au niveau de la VIF, ce qui ne permet pas d'identifier l'unité commerciale spécifique. Passer à une connexion hébergée de 5 Gbit/s (option 3) est une dégradation de la capacité (de 4 Gbit/s LAG à 5 Gbit/s hébergé, ce qui n'est pas une amélioration significative et peut être moins fiable qu'une connexion dédiée) et ne résoudra probablement pas le problème de saturation.