Un'applicazione legacy è stata migrata ad AWS e viene eseguita su tre istanze EC2 (una in ciascuna delle tre AZ) in sottoreti private. Queste istanze sono target per un Application Load Balancer (ALB) in tre sottoreti pubbliche. L'applicazione deve chiamare sistemi on-premises che accettano traffico solo da un singolo indirizzo IP aziendale. Il team di sicurezza ha portato solo quell'IP nel cloud e ha allocato un Elastic IP per esso. La soluzione deve consentire all'applicazione di raggiungere i sistemi on-premises e gestire automaticamente i guasti. Quale design soddisfa questi requisiti?

L'opzione corretta utilizza un singolo NAT Gateway con un Elastic IP, che è l'unico modo per presentare un singolo IP aziendale ai sistemi on-premises. La soluzione include un meccanismo di failover automatico tramite CloudWatch e Lambda per ricreare il NAT Gateway in caso di guasto e riassegnare l'Elastic IP, garantendo alta disponibilità. L'opzione che propone tre NAT Gateway non è valida perché l'Elastic IP può essere associato a un solo NAT Gateway alla volta. L'opzione che suggerisce di sostituire l'ALB con un NLB e assegnare l'Elastic IP all'NLB non è applicabile, poiché l'NLB è per il traffico in entrata verso le istanze, non per il traffico in uscita dalle istanze verso on-premises. L'opzione di assegnare l'Elastic IP all'ALB è errata perché l'ALB non gestisce il traffico in uscita dalle istanze verso on-premises e non è il componente adatto per presentare un singolo IP statico per tale scopo.