Un'applicazione web viene spostata da un ambiente on-premise ad AWS. L'API di terze parti che chiama consente a ciascun client di inserire nella whitelist un solo blocco CIDR pubblico. L'applicazione web verrà eseguita su istanze EC2 in sottoreti private dietro un ALB in sottoreti pubbliche. I gateway NAT forniscono accesso a Internet per le istanze private. In che modo l'architetto dovrebbe garantire che l'API di terze parti continui ad accettare chiamate dall'applicazione migrata utilizzando lo stesso blocco IP client?

L'opzione corretta garantisce che tutto il traffico in uscita dalle istanze EC2 private verso Internet (inclusa l'API di terze parti) origini da un blocco CIDR pubblico specifico e controllato. Registrando un blocco IP di proprietà del cliente (BYOIP) con AWS e assegnando EIP da quel blocco ai Gateway NAT, si presenta un singolo blocco CIDR all'API di terze parti per la whitelist, soddisfacendo il requisito. Le altre opzioni sono errate perché: Associare un blocco IP al VPC e abilitare l'indirizzamento pubblico sulle sottoreti pubbliche non controlla il blocco IP sorgente per il traffico in uscita dalle istanze private, che passerebbe comunque attraverso i Gateway NAT con IP AWS predefiniti. Assegnare EIP statici all'ALB non influisce sull'IP sorgente del traffico in uscita dalle istanze private, poiché l'ALB gestisce il traffico in entrata. AWS Global Accelerator non è necessario per questo requisito specifico di IP sorgente e non garantisce che il traffico in uscita dalle istanze private utilizzi il blocco IP BYOIP per la whitelist dell'API.