Un'azienda sta migrando un'applicazione su un nuovo account AWS in una singola Regione. L'applicazione viene eseguita su istanze EC2 in sottoreti private distribuite su più Zone di Disponibilità. Gli utenti si connettono tramite HTTPS dai browser. Il traffico in entrata deve essere bilanciato tra le AZ e le istanze, e tutte le connessioni dalla stessa sessione client devono andare alla stessa istanza EC2. L'azienda richiede anche la crittografia end-to-end utilizzando il certificato SSL dell'applicazione. Quale design soddisfa questi requisiti?

La risposta corretta è la prima perché un Network Load Balancer (NLB) opera a livello 4 (TCP) e può inoltrare il traffico direttamente alle istanze EC2. Impostando il protocollo su TCP e la porta su 443 sia per il listener che per il gruppo target, il NLB inoltra il traffico HTTPS non decifrato alle istanze. L'affinità di sessione (sticky sessions) garantisce che le connessioni dalla stessa sessione client vadano alla stessa istanza EC2, come richiesto. La crittografia end-to-end è mantenuta distribuendo i certificati SSL direttamente sulle istanze EC2, dove avviene la terminazione SSL. Le altre opzioni sono errate perché: La seconda opzione propone un Application Load Balancer (ALB) con un listener HTTPS, ma il gruppo target è impostato su HTTP e porta 80, il che significherebbe che l'ALB decifra il traffico e lo invia non crittografato alle istanze, violando il requisito di crittografia end-to-end. La terza opzione utilizza un NLB con protocollo TLS per il listener e il gruppo target, il che implicherebbe che il NLB gestisce la terminazione TLS, ma il requisito è che la crittografia end-to-end sia gestita dall'applicazione stessa (sulle istanze EC2). La quarta opzione propone un ALB con un listener HTTP su porta 443, il che è una configurazione non standard per il traffico HTTPS e non garantirebbe la crittografia end-to-end.