Migración del tráfico de red de Transit Gateway a AWS Cloud WAN

En esta serie de artículos sobre Cloud WAN hasta ahora hemos visto los fundamentos del servicio, cuáles son sus componentes lógicos y cómo crear y configurar nuestra red global a partir de políticas.

También hemos visto cómo añadir capacidades de inspección, tanto para tráfico este-oeste como tráfico norte-sur, simplemente modificando la política para redirigir el tráfico sin tener que utilizar rutas estáticas.

La realidad de muchas organizaciones con respecto al networking no es encontrarnos con un green field donde crear una red desde cero. En entornos multirregión lo habitual es encontrar una red compuesta de varios transit gateways interconectados por peering.

Por esta razón, en este post vamos a ver una estrategia de migración desde redes multirregión complejas, basadas en transit gateway, hacia una red global única gestionada con AWS Cloud WAN.

De Transit Gateway a Cloud WAN

#

Para migrar de una red basada en Transit Gateway a una red basada en Cloud WAN, se puede plantear una estrategia en dos fases. Una primera fase en la que creamos la Core Network de Cloud WAN, definimos los segmentos y federamos Transit Gateway para que el tráfico fluya entre regiones a través de Cloud WAN en lugar de mediante peerings entre Transit Gateways. Y una segunda fase en la que cambiamos los attachments de las VPCs para conectar estas a Cloud WAN en lugar de a Transit Gateway. En esta última fase también se desprovisionan los recursos de Transit Gateway.

Para ilustrar mejor el proceso vamos a ver tres escenarios que reflejan cada momento de la migración.

1. Situación de partida: Transit Gateway en cada región conectados por peering.

2. Fase 1: Federación con Cloud WAN. Esta fase se divide en dos subfases:

   1. Fase 1a: Despliegue de Cloud WAN Core Network y federación de Transit Gateway.
   2. Fase 1b: Eliminación del peering entre Transit Gateways

3. Fase 2: Sustitución de Transit Gateway. Esta fase se divide en tres subfases:

   1. Fase 2a: Attachment de las VPCs a Cloud WAN
   2. Fase 2b: Cambio del routing de las VPCs hacia Cloud WAN
   3. Fase 2c: Eliminación de la infraestructura de Transit Gateway.

Para facilitar la comprensión del proceso de migración, se ofrece un repositorio estructurado en diferentes ramas con la configuración de Terraform para cada una de las fases. De esta manera, si lo deseas, puedes desplegar la configuración de cada fase en orden o, si lo prefieres, desplegar la rama correspondiente a la situación de partida e ir aplicando los cambios, ya sea editando el código de Terraform o directamente desde la consola de AWS.

Antes de empezar

#

Si finalmente optas por seguir el procedimiento, cosa que te recomiendo encarecidamente, hay un par de cosas que tiene que tener en consideración. La primera y más importante:

La segunda son las instrucciones para clonar e inicializar Terraform.

# Clone the repository
git clone https://codeberg.org/scambelo/aws-cloud-wan-migration-demo.git
cd aws-cloud-wan-migration-demo

# Initialize Terraform (only needed once)
git checkout phase-0-starting-situation
terraform init

Situación de partida

#

git checkout phase-0-starting-situation
terraform plan
terraform apply

Comenzamos con una red basada en Transit Gateway. Ambos Transit Gateways están unidos por un peering que establece conectividad entre las dos regiones.

Esta red está segmentada en dos capas: una capa para las VPCs de producción y otra capa para las VPCs de desarrollo. Esta separación se realiza mediante una tabla de rutas por cada capa. Adicionalmente, hay una tercera tabla de rutas que se encarga de gestionar el tráfico que llega por el peering.

Cabe destacar que en esta configuración las rutas que encaminan el tráfico por el peering son estáticas.

Suponiendo que tenemos dos instancias EC2, una en VPC A y otra en VPC C, ambas pertenecientes al segmento de producción, el tráfico desde VPC A a VPC C fluye de la siguiente manera:

1. El tráfico saliente de la VPC A llega al Transit Gateway y, según la tabla de rutas PROD 1, el siguiente salto corresponde al Transit Gateway Peering.
2. El tráfico pasa del Transit Gateway de la región primaria al de la secundaria a través del Transit Gateway Peering.
3. Por último, el tráfico sale del Transit Gateway de la región secundaria para dirigirse a la VPC C, según se indica en la tabla de rutas PEERING 2.

El tráfico de vuelta es totalmente simétrico y vuelve por el mismo camino, teniendo en cuenta que pasa por las tablas de rutas PROD 2 y PEERING 1 para llegar a su destino.

Fase 1: Federación con Cloud WAN

#

Fase 1a: Despliegue de Cloud WAN Core Network y federación de Transit Gateway

#

git checkout phase-1a-tgw-federation
terraform plan
terraform apply

El siguiente paso es desplegar Cloud WAN. Para ello, creamos una Core Network y definimos los segmentos de dev y prod en nuestra política. Además de la definición de la Core Network Policy, creamos un peering entre la Core Network y el Transit Gateway de cada región.

Por último, hay que attachar las tablas de rutas del Transit Gateway con la Core Network y además asociarlas a su segmento correspondiente. Esta configuración requiere tres componentes:

• Transit Gateway Policy Table: este componente permite a Cloud WAN propagar rutas en las tablas de rutas de Transit Gateway. Este componente es único por Transit Gateway.
• Transit Gateway Policy Table Association: es la relación de la policy table con el peering entre la Core Network y Transit Gateway. Este componente es único por Transit Gateway.
• Transit Gateway Route Table Attachment: es el attachment de la tabla de rutas de Transit Gateway propiamente dicho. Conceptualmente es muy parecido al attachment de una VPC. La asociación de cada attachment con su segmento correspondiente lo realizamos mediante tags. Este componente es único por cada tabla de rutas de Transit Gateway que queremos asociar.

Por el momento, nada ha cambiado a nivel de enrutamiento. El tráfico sigue fluyendo de la misma manera que en la fase anterior, pero ya hemos sentado las bases para el siguiente paso de esta fase.

Fase 1b: Eliminación del peering entre Transit Gateways

#

git checkout phase-1b-remove-peering
terraform plan
terraform apply

En la segunda parte de esta fase eliminamos el peering entre los Transit Gateways de cada región y las tablas de rutas asociadas. También eliminamos las rutas estáticas de las tablas de rutas del Transit Gateway. Estas tablas de rutas son actualizadas dinámicamente por las Transit Gateway Policy Tables que creamos en el paso anterior.

Con estos cambios en la infraestructura y el enrutamiento, el tráfico entre regiones ahora se encamina a través de Cloud WAN.

1. Siguiendo con el ejemplo anterior, el tráfico sigue saliendo de la VPC A hacia la tabla de rutas PROD 1 en el Transit Gateway.
2. Del Transit Gateway sigue su camino hasta Cloud WAN.
3. En Cloud WAN, como la tabla de rutas de Transit Gateway PROD 1 está asociada al segmento de prod, se aplica el enrutamiento de la tabla de rutas interna de la Core Network correspondiente a ese segmento y región que encamina el tráfico hacia la región de destino.
4. En la región de destino, la tabla de rutas interna redirige el tráfico hacia la tabla de rutas PROD 2 de Transit Gateway.
5. Por último, Transit Gateway redirige el tráfico hacia su destino final en VPC C.

El tráfico de retorno en este caso es totalmente simétrico, siguiendo el camino inverso hacia el origen.

En este punto de la fase 1 ya tenemos una solución de interconexión entre regiones totalmente funcional, por lo que podríamos terminar la migración en este punto. Sin embargo, todavía mantenemos infraestructura de Transit Gateway que nos puede suponer un coste adicional.

En la siguiente fase veremos cómo completar la migración para no tener esta dependencia con Transit Gateway.

Fase 2: Sustitución de Transit Gateway

#

Fase 2a: Attachment de las VPCs a Cloud WAN

#

git checkout phase-2a-vpc-attachment
terraform plan
terraform apply

En el primer paso de esta segunda fase attachamos las VPCs directamente a Cloud WAN mientras mantenemos los actuales attachments con el Transit Gateway todavía. Cada VPC se asocia a su segmento correspondiente gracias a las tags, lo que nos permite no tener que tocar la política de Cloud WAN. De hecho, durante toda esta migración la Core Network Policy no se toca.

Los nuevos attachments a Cloud WAN modifican dinámicamente las rutas internas de este y ahora, en lugar de redirigir el tráfico saliente a las tablas de rutas de Transit Gateway, lo redirige a las VPCs directamente. Veamos cómo queda el flujo:

1. El tráfico sigue saliendo de la VPC A hacia la tabla de rutas PROD 1 en el Transit Gateway.
2. Del Transit Gateway sigue su camino hasta Cloud WAN.
3. En Cloud WAN se aplica el enrutamiento de la tabla de rutas interna de la Core Network correspondiente al segmento y región del attachment de la VPC A y se encamina el tráfico hacia la región de destino.
4. En la región de destino, la tabla de rutas interna redirige el tráfico hacia su destino final en VPC C.

El tráfico de vuelta sigue un camino análogo. En este punto tenemos una asimetría del flujo, ya que el tráfico de ida sigue saliendo por el Transit Gateway pero el de vuelta entra a la VPC desde Cloud WAN. Pero eso va a cambiar en el siguiente paso.

Fase 2b: Cambio del routing de las VPCs hacia Cloud WAN

#

git checkout phase-2b-routing-change
terraform plan
terraform apply

Ahora, en este paso, una vez que tenemos las VPCs conectadas a Cloud WAN, lo que hacemos es cambiar el enrutamiento en las propias VPCs para que su ruta por defecto (0.0.0.0/0) pase a apuntar a Cloud WAN en lugar de a Transit Gateway.

Con este cambio, el flujo queda de la siguiente manera:

1. El tráfico sale de la VPC A hacia Cloud WAN directamente.
2. En Cloud WAN se aplica el enrutamiento de la tabla de rutas interna de la Core Network correspondiente al segmento y región del attachment de la VPC A y se encamina el tráfico hacia la región de destino.
3. En la región de destino, la tabla de rutas interna redirige el tráfico hacia su destino final en VPC C.

Por tanto, ahora el tráfico de vuelta sigue el camino inverso y volvemos a recuperar la simetría de tráfico. En este punto ya casi hemos completado la migración, ya que todo el tráfico entre VPCs se realiza a través de Cloud WAN. Solo nos queda una cosa por hacer.

Fase 2c: Eliminación de la infraestructura de Transit Gateway

#

git checkout phase-2c-tgw-cleanup
terraform plan
terraform apply

Por último, solo nos queda hacer limpieza de los recursos restantes de Transit Gateway que ya no son necesarios. En este último paso no hay cambios en el flujo que ya quedó definido en el paso anterior y solamente hacemos limpieza de la infraestructura que ya no es necesaria, quedando la arquitectura resultante tal y como se ve en el diagrama de esta sección.

Conclusión

#

En este artículo hemos explorado una estrategia completa de migración desde una arquitectura de red basada en Transit Gateway hacia una solución moderna con AWS Cloud WAN. La migración se estructura en dos fases principales: la primera centrada en la federación con Cloud WAN manteniendo la infraestructura existente, y la segunda enfocada en la sustitución completa de Transit Gateway. Esta aproximación gradual permite realizar la transición de manera controlada y sin interrupciones, minimizando el riesgo operacional.

Durante el proceso hemos visto cómo Cloud WAN introduce conceptos como el enrutamiento dinámico basado en políticas y la propagación automática de rutas, eliminando la necesidad de gestionar rutas estáticas manualmente. La federación de Transit Gateway permite mantener la segmentación de red existente mientras se aprovechan las capacidades de Core Network. El resultado final es una arquitectura donde el tráfico interregional fluye de manera más directa y la gestión de la conectividad se centraliza en una única política de red.

Y aquí finaliza esta serie monográfica en tres entregas sobre Cloud WAN.

¿Te gustó este artículo? ¡Suscríbete a la newsletter y sé el primero en enterarte cuando se publique uno nuevo!

Referencias

#

• AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns
• Peerings in AWS Cloud WAN
• Transit gateway route table attachments in AWS Cloud WAN
• Transit gateway policy tables in Amazon VPC Transit Gateways