Un'applicazione web è in esecuzione su istanze EC2 in sottoreti private in tre zone di disponibilità, dietro un ALB. SSL/TLS è terminato sull'ALB utilizzando certificati ACM. Durante i test con una singola istanza, tutto ha funzionato, ma dopo il deployment in produzione gli utenti possono effettuare il login, ma ogni nuova richiesta web riavvia il flusso di login. Cosa dovrebbe fare l'ingegnere di rete per risolvere il problema?

L'applicazione web richiede la persistenza della sessione per mantenere lo stato dell'utente dopo il login. L'ALB distribuisce le richieste in modo uniforme tra le istanze EC2. Se la stickiness non è abilitata, le richieste successive dello stesso utente potrebbero essere inviate a un'istanza diversa, che non riconosce la sessione, forzando un nuovo login. Abilitare l'attributo di stickiness nel gruppo di destinazione dell'ALB, utilizzando un cookie basato sull'applicazione e impostando una durata adeguata, assicura che le richieste di un utente vengano sempre indirizzate alla stessa istanza EC2, mantenendo la sessione attiva. Le altre opzioni sono errate perché: Modificare la configurazione del listener dell'ALB per abilitare la stickiness a livello di gruppo non è l'approccio corretto; la stickiness si configura a livello di gruppo di destinazione. Sostituire l'ALB con un NLB non è necessario e un NLB opera a un livello inferiore (livello 4), non supportando la stickiness basata su cookie dell'applicazione. Rimuovere l'ALB e usare Route 53 con una policy di failover non risolve il problema della persistenza della sessione e introduce complessità non necessarie, oltre a spostare la terminazione SSL/TLS sulle istanze EC2, che è meno efficiente.