Een bedrijf heeft een beveiligingsvereiste geïntroduceerd om al het verkeer van bedrijfs-AWS-instances in zijn VPC te inspecteren op beleidsschendingen en om specifieke IP-adressen te blokkeren. Om hieraan te voldoen, heeft het bedrijf EC2-instances met goedgekeurde proxyserversoftware in private subnets geïmplementeerd als transparante proxies, de routetabellen van de subnets bijgewerkt om de proxy-instances als standaardroute te gebruiken, en security groups gekoppeld die voldoen aan het beleid. Ondanks deze wijzigingen wordt verkeer van instances in private subnets niet via de proxies naar het internet doorgestuurd. Wat moet een solutions architect doen om dit te verhelpen?

De correcte optie is om source/destination checks uit te schakelen op de EC2-instances die de proxyserversoftware uitvoeren. Dit is essentieel omdat een proxy-instance verkeer doorstuurt dat niet voor zichzelf bestemd is. Standaard blokkeert AWS dit gedrag om spoofing te voorkomen. Door de source/destination check uit te schakelen, kan de proxy-instance fungeren als een router of gateway en verkeer namens andere instances verwerken. De andere opties zijn incorrect: Het toevoegen van een security group-regel om al het verkeer tussen instances toe te staan en deze aan elke instance toe te wijzen, lost het probleem van het doorsturen van verkeer niet op; het regelt alleen de netwerktoegang. Het wijzigen van de DHCP options set om de DNS-serveropties in te stellen op de IP-adressen van de proxy EC2-instances is onjuist. DNS-servers vertalen hostnamen naar IP-adressen, ze routeren geen verkeer. Het koppelen van een extra ENI aan elke proxy EC2-instance is niet nodig en lost het onderliggende routingprobleem niet op. De routing wordt beheerd via de routetabellen en de source/destination check.