Cuando comencé mi carrera en el mundo cloud, el networking era relativamente sencillo. Tenías una única cuenta con una VPC, y lo único de lo que debías preocuparte era de definir correctamente tus subredes públicas y privadas. Como mucho, podías configurar una conexión de VPC peering con otra VPC o quizás una VPN site-to-site para conectar con recursos on-premises.
Hoy en día, sin embargo, en entornos empresariales más complejos, la situación es muy diferente. Se trata de configuraciones multi-cuenta con decenas de VPCs, enlaces de Direct Connect al entorno on-premise, y a veces una VPN site-to-site como respaldo.
En estos entornos multi-cuenta, AWS Transit Gateway nos permite la interconexión de todos estos tipos de componentes para formar redes regionales. Y aunque Transit Gateway permite interconectar redes regionales mediante conexiones de peering para crear una red global, la complejidad y la cantidad de esfuerzo requerido para su mantenimiento adecuado siguen siendo significativos.
AWS Cloud WAN #
Para ayudar a reducir esta complejidad, podemos apoyarnos en AWS Cloud WAN, un servicio de red que nos permite interconectar VPCs, Direct Connect Gateways, VPNs Site-to-Site e incluso appliances Cloud SDWAN.
AWS Cloud WAN es un servicio gestionado. Esto significa que solo tenemos que preocuparnos por lo que queremos configurar (el diseño de nuestra red), y dejamos los detalles de configuración a AWS.
La configuración de AWS Cloud WAN está basada en políticas, lo que nos permite definir la configuración de nuestra red de forma declarativa, facilitando así su versionado y su aplicación en workflows CI/CD.
Componentes de Infraestructura #
Desde el punto de vista de la infraestructura, AWS Cloud WAN es un servicio relativamente simple. Veamos cuáles son sus componentes.
-
Global Network: Constructo lógico de alto nivel que sirve como contenedor para la Cloud WAN Core Network.
-
Core Network: Representa la red global gestionada por AWS. En esta red se crean los elementos que conforman la infraestructura de AWS Cloud WAN, como los Core Network Edges o los diferentes attachments.
-
Attachments: Elementos que se conectan a la Core Network, como VPCs, VPNs, Transit Gateways o Direct Connect Gateways.
-
Core Network Edge: El componente más importante a nivel de infraestructura. Un Core Network Edge es esencialmente un router que se conecta a una región específica; todos los attachments en esa región se conectan a ese Core Network Edge. Es similar a un Transit Gateway en funcionamiento interno y características, pero los Core Network Edges son gestionados por AWS, y su configuración se define mediante una política asociada a la Core Network.
Componentes Lógicos #
Cloud WAN tiene dos grandes fortalezas:
-
Es un servicio global que permite conectar múltiples regiones sin necesidad de configuraciones complejas.
-
La configuración del servicio se realiza mediante políticas.
La Core Network Policy es el elemento central de configuración donde ralmente definimos la arquitectura de nuestra Core Network. Veamos los principales componentes lógicos que podemos configurar usando una política.
-
Segmentos de red: Un segmento es un dominio de enrutamiento dedicado. Esto significa que, por defecto, todos los attachments dentro de un segmento pueden comunicarse entre sí, mientras que no hay visibilidad entre diferentes segmentos. Este comportamiento puede modificarse en el documento de la política, por ejemplo, restringiendo la comunicación entre attachments dentro del mismo segmento o compartiendo las rutas de un segmento con otro para permitir la visibilidad entre segmentos.
-
Segment actions: Esta es una sección de configuración dentro de la Core Network Policy. Las segment actions definen el comportamiento de un segmento. Estas acciones pueden incluir compartir las rutas de un segmento, configurar rutas estáticas y redirigir el tráfico para fines de inspección.
-
Attachment policies: En mi opinión, esta es una de las mejores características de AWS Cloud WAN. Las attachment policies nos permiten asignar un determinado attachment a su segmento correspondiente en función de etiquetas (tags). Aunque la sintaxis de configuración puede ser compleja, es extremadamente poderosa. Recomiendo visitar la documentación sobre attachment policies para más detalles.
Por último, aunque hablamos de los Core Network Edges como un componente de infraestructura, su definición forma parte de la configuración de la Core Network Policy.
- Core Network Configuration: Esta sección define los parámetros fundamentales para la Core Network. Aquí se especifica el rango ASN (Autonomous System Number) a utilizar, los rangos CIDR para las conexiones VPN y, lo más importante, los Core Network Edges que la Core Network desplegará.
Configuración de muestra #
Para ilustrar mejor todos estos conceptos, aquí tienes una Core Network Policy básica de ejemplo.
{
"version": "2021.12",
"core-network-configuration": {
"asn-ranges": [
"64512-64555"
],
"edge-locations": [
{
"asn": 64512,
"location": "eu-west-1"
},
{
"asn": 64513,
"location": "us-east-1"
}
],
"vpn-ecmp-support": false
},
"segments": [
{
"description": "Segment for demo VPCs",
"isolate-attachments": false,
"name": "demo",
"require-attachment-acceptance": false
}
],
"attachment-policies": [
{
"action": {
"association-method": "tag",
"tag-value-of-key": "segment"
},
"conditions": [
{
"key": "segment",
"type": "tag-exists"
}
],
"rule-number": 100
}
]
}
En esta política, definimos nuestra Core Network, que desplegará dos Core Network Edges en Irlanda (eu-west-1) y N. Virginia (us-east-1). También definimos un Network Segment llamado demo.
La última parte de la política define cómo se asociarán los attachments con los segments. Esta es una configuración muy interesante, así que profundicemos un poco más:
- La sección
conditionsespecifica que el attachment debe incluir una etiqueta con una clave llamadasegment. - La sección
actionestablece que el attachment debe asociarse con el segmento cuyo nombre coincida con el valor de la etiquetasegmenten el attachment.
De esta manera, si tenemos un attachment con una etiqueta "segment": "demo", se asociará con el segmento demo. Sin embargo, si el attachment carece de la etiqueta o tiene un valor diferente, no se asociará, a menos que haya un segmento con el mismo nombre que el valor de la etiqueta.
Demo #
Toda la teoría sobre AWS Cloud WAN está bien, pero la mejor manera de comprender los conceptos es a través de la experiencia práctica. Así que vamos a ello con una demostración.
El código de Terraform para desplegar la arquitectura de la demo se puede encontrar aquí:
Ahora, vamos a sumergirnos en la demo.
El objetivo de esta demo es mostrar cómo una instancia ubicada en una VPC en la región de Irlanda (eu-west-1) puede comunicarse con otra instancia ubicada en una VPC en la región de Norte de Virginia (us-east-1) a través de AWS Cloud WAN.
Como se ilustra en el diagrama, el camino que sigue el tráfico es el siguiente:
-
Desde la instancia de EC2 de origen, el tráfico sale de la VPC y entra en la Red Central de AWS Cloud WAN a través del Core Network Edge en la región de Irlanda (
eu-west-1). -
En este punto, el tráfico viaja desde el Core Network Edge de Irlanda (
eu-west-1) hasta el Core Network Edge de Norte de Virginia (us-east-1) a través de la red interna de AWS. -
El tráfico que sale del Core Network Edge en Norte de Virginia (
us-east-1) entra en el VPC asociado para llegar a la instancia de destino EC2.
Ahora que el objetivo está claro, comencemos a desplegar la infraestructura. Para ello, simplemente inicializamos y aplicamos el código de Terraform:
terraform init
terraform apply
Una vez desplegado, podemos probar si la instancia B, ubicada en us-east-1, puede ser alcanzada desde la instancia A, ubicada en eu-west-1, y viceversa.
-
Conéctate a la instancia A a través de SSM Session Manager. Una vez allí, ejecuta un
pinga la instancia B.sh-5.2$ uname -a Linux ip-192-168-1-20.eu-west-1.compute.internal 6.1.132-147.221.amzn2023.aarch64 #1 SMP Tue Apr 8 13:14:35 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux sh-5.2$ ping -c 10 192.168.1.169 PING 192.168.1.169 (192.168.1.169) 56(84) bytes of data. 64 bytes from 192.168.1.169: icmp_seq=1 ttl=125 time=69.7 ms 64 bytes from 192.168.1.169: icmp_seq=2 ttl=125 time=68.1 ms 64 bytes from 192.168.1.169: icmp_seq=3 ttl=125 time=68.2 ms 64 bytes from 192.168.1.169: icmp_seq=4 ttl=125 time=68.1 ms 64 bytes from 192.168.1.169: icmp_seq=5 ttl=125 time=68.2 ms 64 bytes from 192.168.1.169: icmp_seq=6 ttl=125 time=68.2 ms 64 bytes from 192.168.1.169: icmp_seq=7 ttl=125 time=68.1 ms 64 bytes from 192.168.1.169: icmp_seq=8 ttl=125 time=68.2 ms 64 bytes from 192.168.1.169: icmp_seq=9 ttl=125 time=68.2 ms 64 bytes from 192.168.1.169: icmp_seq=10 ttl=125 time=68.1 ms --- 192.168.1.169 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9012ms rtt min/avg/max/mdev = 68.104/68.297/69.653/0.452 msComo podemos ver, la instancia B es alcanzada desde la instancia A sin ningún problema. Vale la pena mencionar cómo los tiempos de
pingnos indican que el tráfico está fluyendo entre las regioneseu-west-1yus-east-1. -
Ahora, conéctate a la instancia B mediante SSM Session Manager. Una vez dentro, ejecuta
pinghacia la instancia A.sh-5.2$ uname -a Linux ip-192-168-1-169.ec2.internal 6.1.132-147.221.amzn2023.aarch64 #1 SMP Tue Apr 8 13:14:35 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux sh-5.2$ ping -c 10 192.168.1.20 PING 192.168.1.20 (192.168.1.20) 56(84) bytes of data. 64 bytes from 192.168.1.20: icmp_seq=1 ttl=125 time=69.2 ms 64 bytes from 192.168.1.20: icmp_seq=2 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=3 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=4 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=5 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=6 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=7 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=8 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=9 ttl=125 time=68.1 ms 64 bytes from 192.168.1.20: icmp_seq=10 ttl=125 time=68.2 ms --- 192.168.1.20 ping statistics --- 10 packets transmitted, 10 received, 0% packet loss, time 9005ms rtt min/avg/max/mdev = 68.074/68.217/69.203/0.330 msLos resultados son muy similares.
Como hemos visto, con AWS Cloud WAN, la conectividad entre diferentes regiones se vuelve casi trivial, sin necesidad de gestionar rutas manualmente ni realizar configuraciones complejas.
Si el lector lo desea, puede utilizar el código Terraform proporcionado para modificar la política y agregar nuevos segmentos y attachments a la Core Network para observar cómo se comporta.
Recuerda destruir los recursos de Terraform cuando hayas terminado de usarlos.
terraform destroy
Conclusión #
En este artículo hemos visto qué es AWS Cloud WAN y cuáles son sus principales componentes. También exploramos cómo configurar AWS Cloud WAN utilizando una política. Por último, hicimos una demo para ver en acción una arquitectura sencilla de AWS Cloud WAN.
Este artículo es el primero de una serie sobre AWS Cloud WAN. Si te ha parecido interesante, suscríbete a la newsletter y sé el primero en enterarte cuando se publique el siguiente.
Subscribir