Un'API REST monolitica per un'app mobile è in esecuzione su cinque istanze EC2 in sottoreti pubbliche ed è preceduta da un record di risposta multivalore di Route 53 che punta direttamente agli IP delle istanze. Improvvisi e ampi picchi di traffico stanno sovraccaricando l'app. Quale soluzione consentirà all'applicazione di scalare al nuovo carico variabile con il MINOR overhead operativo?

La risposta corretta è distribuire un Application Load Balancer (ALB) davanti all'API, spostare le istanze EC2 in sottoreti private, registrare le istanze come target ALB e aggiornare il record Route 53 in modo che punti all'ALB. Un ALB distribuisce il traffico in entrata tra più istanze EC2, fornendo bilanciamento del carico e scalabilità automatica. Spostare le istanze in sottoreti private migliora la sicurezza, poiché non sono direttamente accessibili da Internet. L'ALB gestisce i picchi di traffico in modo efficiente con il minimo overhead operativo, poiché è un servizio gestito da AWS. Suddividere l'API in funzioni Lambda (opzione 1) o containerizzarla con EKS (opzione 2) comporta una riscrittura significativa dell'applicazione e un maggiore overhead operativo per la migrazione e la gestione. Inserire le istanze EC2 in un gruppo Auto Scaling e aggiornare Route 53 con una funzione Lambda (opzione 3) è meno efficiente e più complesso rispetto all'utilizzo di un ALB, che gestisce automaticamente la registrazione dei target e la distribuzione del traffico.