Un'azienda utilizza una connessione dedicata Direct Connect da 4 Gbps (LAG) per connettersi a cinque VPC in us-east-1. Ogni VPC utilizza la propria interfaccia virtuale privata (VIF) verso la rete on-premises. Gli utenti segnalano rallentamenti e l'ingegnere nota picchi di throughput che saturano il Direct Connect per circa un'ora ogni giorno lavorativo. L'azienda deve identificare quale unità aziendale causa il picco e risolvere la saturazione. Quale approccio soddisfa questi requisiti?

L'opzione corretta identifica il VIF responsabile del picco di traffico utilizzando le metriche CloudWatch VirtualInterfaceBpsEgress e VirtualInterfaceBpsIngress, che misurano il throughput in uscita e in entrata per ciascuna interfaccia virtuale. Questo permette di individuare l'unità aziendale che causa la saturazione. Successivamente, per risolvere la saturazione, si propone di effettuare il provisioning di una nuova connessione Direct Connect dedicata da 10 Gbps e spostare il traffico, che è la soluzione più efficace per aumentare la capacità e mantenere la disponibilità durante la transizione. Le opzioni errate presentano i seguenti difetti: La seconda opzione propone di aggiornare la connessione esistente a 10 Gbps. Sebbene aumenti la capacità, non permette di identificare la causa del picco e potrebbe comportare un'interruzione del servizio durante l'aggiornamento. La terza e la quarta opzione utilizzano metriche CloudWatch errate (ConnectionBpsIngress e ConnectionPpsEgress misurano il traffico complessivo della connessione, non per singolo VIF) e quindi non consentono di identificare il VIF specifico che causa il problema. Inoltre, la terza opzione suggerisce una connessione hosted da 5 Gbps, che è inferiore alla capacità desiderata e non risolve il problema a lungo termine.