Una empresa introdujo un requisito de seguridad para inspeccionar todo el tráfico de las instancias corporativas de AWS en su VPC en busca de violaciones de políticas y para bloquear direcciones IP específicas. Para cumplir con esto, la empresa implementó instancias EC2 que ejecutan software de proxy aprobado en subredes privadas como proxies transparentes, actualizó las tablas de ruteo de las subredes para usar las instancias de proxy como ruta predeterminada y adjuntó grupos de seguridad que cumplen con la política. A pesar de estos cambios, el tráfico de las instancias en subredes privadas no se reenvía a internet a través de los proxies. ¿Qué debe hacer un arquitecto de soluciones para solucionar esto?

La opción correcta es deshabilitar las comprobaciones de origen/destino en las instancias EC2 que ejecutan el software de proxy. Por defecto, una instancia EC2 realiza comprobaciones de origen/destino, lo que significa que debe ser el origen o el destino de cualquier tráfico que envíe o reciba. Para que una instancia actúe como un proxy transparente o un dispositivo de red (como un firewall o un NAT), debe poder enviar y recibir tráfico en nombre de otras instancias. Deshabilitar esta comprobación permite que la instancia reenvíe tráfico que no está destinado a ella. Las otras opciones son incorrectas: Agregar una regla de grupo de seguridad para permitir todo el tráfico entre instancias y asignarlo a todas las instancias no resuelve el problema de reenvío de tráfico a través del proxy. Cambiar las opciones de DHCP para el servidor DNS a las IP de las instancias proxy solo afectaría la resolución de DNS, no el enrutamiento del tráfico. Adjuntar una ENI adicional a cada instancia proxy es una práctica común para dispositivos de red con múltiples interfaces, pero no es la causa principal del fallo de reenvío en este escenario específico si las tablas de enrutamiento ya apuntan al proxy. La comprobación de origen/destino es el obstáculo principal.