Un'azienda ha introdotto un requisito di sicurezza per ispezionare tutto il traffico proveniente dalle istanze AWS aziendali nella sua VPC alla ricerca di violazioni delle policy e per bloccare specifici indirizzi IP. Per soddisfare questo requisito, l'azienda ha distribuito istanze EC2 che eseguono software proxy approvato in sottoreti private come proxy trasparenti, ha aggiornato le tabelle di routing delle sottoreti per utilizzare le istanze proxy come route predefinita e ha allegato gruppi di sicurezza conformi alla policy. Nonostante queste modifiche, il traffico dalle istanze nelle sottoreti private non viene inoltrato a Internet tramite i proxy. Cosa dovrebbe fare un architetto di soluzioni per risolvere questo problema?

Per consentire a un'istanza EC2 di inoltrare traffico per conto di altre istanze (come un proxy o un NAT), è necessario disabilitare i controlli source/destination (sorgente/destinazione). Questi controlli impediscono a un'istanza di inviare o ricevere traffico se l'indirizzo IP sorgente o di destinazione nel pacchetto non corrisponde all'indirizzo IP primario dell'istanza. Disabilitandoli, l'istanza proxy può inoltrare pacchetti con indirizzi IP sorgente o di destinazione diversi dal proprio. Le altre opzioni non risolvono il problema principale: L'aggiunta di una regola al gruppo di sicurezza per consentire il traffico tra le istanze con lo stesso gruppo di sicurezza non abilita l'inoltro del traffico tra sottoreti diverse. La modifica delle opzioni DHCP per il server DNS indirizza solo le query DNS, non il traffico di rete generale. L'aggiunta di un'interfaccia di rete elastica (ENI) aggiuntiva non è necessaria e non risolve il problema dei controlli source/destination che bloccano l'inoltro.