Un ingeniero de redes creó lo siguiente para conectar dos VPC de producción en diferentes regiones (Prod A en eu-west-1 con 10.0.0.0/16 y Prod B en eu-central-1 con 10.1.0.0/16): 1) un transit gateway en cada región, 2) compartió y aceptó los transit gateways con las cuentas de producción, 3) creó un peering attachment entre los transit gateways, 4) adjuntó cada VPC al transit gateway de su región, 5) creó tablas de ruteo de transit gateway y adjuntos asociados, 6) añadió rutas estáticas en cada tabla de ruteo de transit gateway para enviar tráfico a la VPC remota, y 7) habilitó la propagación de rutas en las tablas de ruteo de la VPC. Las conexiones de Prod A a Prod B fallaron. ¿Qué debería hacer el ingeniero para lograr la conectividad requerida?

La conectividad falló porque, aunque las tablas de ruteo del Transit Gateway se configuraron correctamente, las tablas de ruteo de las VPC no se actualizaron para dirigir el tráfico destinado a la VPC remota hacia el Transit Gateway. Habilitar la propagación de rutas en las tablas de ruteo de la VPC solo propaga rutas de la VPC a la tabla de ruteo del Transit Gateway, no viceversa. Por lo tanto, es necesario añadir una ruta estática en cada tabla de ruteo de la VPC, apuntando al Transit Gateway de su región como objetivo para el rango de CIDR de la VPC remota (10.1.0.0/16 para Prod A y 10.0.0.0/16 para Prod B). La opción de 10.0.0.0/8 es incorrecta porque es demasiado amplia y podría causar problemas de enrutamiento con otras redes. Modificar la dirección IP del peering attachment no es relevante para este problema. Eliminar las rutas estáticas del Transit Gateway y habilitar la propagación de rutas tampoco es la solución, ya que la propagación de rutas en el Transit Gateway es para sus adjuntos locales, no para el peering entre Transit Gateways.