AWS Cloud WAN: la guía para redes multi-región 2026

En pocas palabras: Se diseña centralizando toda la configuración en una única política de red principal (core network policy) en formato JSON versionado, que define segmentos, rutas e inspección para todas las regiones, reemplazando el peering manual de Transit Gateways regionales y sus tablas de rutas independientes.

AWS Cloud WAN es el servicio de red administrada de Amazon que reemplaza la maraña de Transit Gateways regionales peereados a mano. La guía técnica publicada en dev.to el 24 de septiembre de 2026 describe una red en producción con varios cientos de cuentas y VPCs en cuatro regiones, gobernada por una sola política JSON versionada.

AWS Cloud WAN es un servicio administrado de Amazon Web Services que conecta VPCs, VPNs, conexiones Direct Connect y Transit Gateways existentes en una red global operada por AWS, con un edge en cada región elegida. Toda la configuración (segmentos, rutas, inspección) vive en un único documento llamado política de red principal, en vez de repartirse en tablas de rutas regionales independientes, según explica la documentación técnica de AWS.

¿Qué problema de las redes con Transit Gateway viene a resolver AWS Cloud WAN?

Transit Gateway es un recurso regional. Si operás en cuatro regiones, corrés cuatro Transit Gateways, los conectás mediante peering en malla y te pasás una parte creciente de la semana asegurándote de que las route tables de las cuatro cuenten la misma historia. Funciona, sí, pero se pone un poco más frágil cada trimestre, según describe la guía publicada en dev.to.

Dos problemas dominan esa arquitectura a escala. El primero: ningún documento único dice “test puede llegar a shared services y nada más”. Esa intención vive repartida en route tables de cuatro regiones, y la única forma de comprobarla es leerlas todas. El segundo: la inspección es de doble salto. Un flujo entre VPCs de distintas regiones pasa por un firewall al salir de la región de origen y por otro al entrar en la de destino. Los firewalls stateful necesitan ver ambas direcciones de un flujo, y con Transit Gateways regionales independientes la única manera de garantizar simetría es inspeccionar en los dos extremos.

¿Y qué pasa cuando se suma una quinta región? Exacto, se duplica el problema otra vez. Cloud WAN saca esos dos dolores de encima, y esa es la razón real para migrar, no una “novedad” de catálogo de AWS.

Aspecto	Transit Gateway	AWS Cloud WAN
Alcance	Regional, uno por región	Global, un edge por región dentro de una sola red
Conexión entre regiones	Peering manual entre Transit Gateways	AWS empareja/conecta automáticamente todos los edges
Configuración	Route tables por región	Una política JSON versionada (core network policy)
Inspección entre regiones	Doble salto (firewall en cada extremo)	Un solo salto vía network function groups
Alta a VPC nueva	Attachment manual y propagación por tabla	Self-service por tag, ubicación automática por política

¿Cómo se estructura una red global en AWS Cloud WAN?

Una red global en AWS Cloud WAN se organiza en una global network que contiene una core network administrada por AWS, con un edge en cada región elegida y todos esos edges peereados automáticamente sobre el backbone de Amazon. Nunca creás una conexión de peering entre regiones a mano ni mantenés rutas inter-región: eso lo hace AWS.

Si Transit Gateway es un router que vos configurás, Cloud WAN es una WAN que describís. La comparación no es mía, la hace la propia guía de dev.to, y me parece la forma más clara de entender el cambio de modelo. Más contexto en comparamos el rendimiento frente a MicroVMs de AWS.

Cuando una VPC se conecta en Sídney, por ejemplo, su CIDR aparece solo en los edges de Virginia y Oregon dentro del segmento que le corresponde, sin que nadie toque una ruta a mano. El comportamiento por defecto es afinidad regional: el tráfico se queda en su región de origen salvo que el destino o la política diga lo contrario, así que los caminos son predecibles y cruzás el backbone solo cuando lo decidís de forma explícita (para inspección o egress centralizado, por ejemplo).

Cada edge necesita su propio número de ASN reservado en la política. Elegí un rango privado, mantenelo fuera de cualquier cosa con la que peereés y no lo cambies después. Parece un detalle chico, pero es de los que rompen migraciones enteras si se pisan con otro rango en uso.

¿Qué son los segmentos y cómo se organiza la intención de enrutamiento?

Un segmento en Cloud WAN es un dominio de enrutamiento que existe en todos los edges a la vez: dos attachments en el mismo segmento se alcanzan entre regiones sin configuración adicional, y attachments de segmentos distintos no se alcanzan salvo que la política comparta rutas entre ellos de forma explícita.

Ponele que armás la red de una empresa mediana. La guía de dev.to describe un modelo de cuatro grupos que funciona bien en producción: entornos (test, staging y producción, cada uno aislado), shared services (un hub al que cada entorno puede llegar, pero que nunca es transitivo entre entornos), externo (uno por entorno, aislado, para VPNs y partners) e inter-nube (uno por entorno, ruteado siempre vía inspección). Para más detalles técnicos, mirá alternativas de almacenamiento sin costo de egreso.

Segmento	Puede alcanzar	Aislado	Inspeccionado
Test	Test y shared services, todas las regiones	Sí	Solo egress
Staging	Staging y shared services, todas las regiones	Sí	Solo egress
Producción	Producción y shared services, todas las regiones	Sí	Solo egress
Shared services	Cada segmento de entorno, todas las regiones	No	Solo egress
Externo (por entorno)	Su propio entorno, vía inspección	Sí	Todo el flujo
Inter-nube (por entorno)	Su propio entorno, vía inspección	Sí	Todo el flujo

Tres reglas sostienen ese modelo. Shared services es un hub, no un puente: test no llega a producción pasando por ahí, y la política comparte rutas en una sola dirección, hacia el hub. Externo e inter-nube se separan por entorno, así un endpoint VPN de test nunca se convierte en camino hacia producción. Y la aislación de segmento se usa para cualquier cosa de terceros, de modo que cada VPN de partner queda como una isla que solo llega a lo que vos ruteaste hacia ella.

Escrita así, la alcanzabilidad de toda la red cabe en una tabla, y esa tabla es literalmente lo que codifica la política. Entre 12 y 15 segmentos cubren la mayoría de las empresas. Si te encontrás creando un segmento por equipo, no estás diseñando: estás reconstruyendo route tables viejas con otro nombre.

¿Cómo se conectan cientos de VPCs sin que el equipo de red se vuelva una cola de tickets?

Con cientos de cuentas, dar de alta una VPC tiene que ser self-service, porque si no tu equipo de red termina siendo una cola de tickets eterna. El patrón que describe la fuente resuelve esto con tags y una política que decide sola.

• Compartí la core network por AWS RAM: un solo share hacia la unidad organizacional entera, no cuenta por cuenta.
• El dueño de la VPC crea el attachment: desde su propia cuenta, con el módulo de Terraform o la plataforma interna que ya usa.
• El attachment lleva un tag con el nombre del segmento: es lo único que el dueño controla.
• La política ubica el attachment: matchea el tag y lo pone en el segmento correcto, sin que ningún humano elija.
• Desactivá la aceptación manual en segmentos internos: si el mismo equipo administra la core network y las cuentas, un paso de aprobación manual solo agrega fricción, no seguridad. Mantenela activa en segmentos externos, donde del otro lado puede haber un tercero.
• Activá appliance mode solo en attachments hacia VPCs de inspección: fija ambas direcciones de un flujo en la misma zona de disponibilidad, algo que los firewalls stateful necesitan. En VPCs de carga de trabajo normal no hace falta, y activarlo ahí solo te suma un salto cruzado entre AZ.

Subís el tag, la política lo lee, el attachment aparece en el segmento correcto, el CIDR se propaga solo a todos los edges y nadie del equipo de red tocó una route table. Ese es el punto de todo el diseño. Cubrimos ese tema en detalle en problemas comunes al configurar la trust policy.

¿Cómo logra AWS Cloud WAN la inspección de tráfico de un solo salto entre regiones?

AWS Cloud WAN inspecciona el tráfico entre regiones una sola vez por flujo porque la core network ve el flujo completo de punta a punta y puede mandar ambas direcciones por el mismo firewall, aunque origen y destino estén en regiones distintas. Eso se resuelve con los network function groups, según detalla la documentación oficial de FAQs de AWS Cloud WAN.

Metés tus VPCs de inspección en un grupo y en la política definís qué flujos segmento a segmento tienen que pasar vía ese grupo (una regla send-via, para inspección este-oeste) o hacia ese grupo (send-to, típicamente una ruta default, para egress centralizado). El egress merece su propia mención porque sorprende a bastante gente: cada segmento, shared services incluido, recibe una regla send-to hacia el grupo de inspección, que es el único que tiene NAT gateway e internet gateway. Nada más en la red tiene salida propia. Una VPC de workload con su propio NAT gateway es directamente un agujero en el diseño. ¿Quién decide qué firewall regional atiende un flujo cruzado? La política. Podés preferir la región más cercana al origen, fijar un orden de prioridad explícito o forzar un override por edge, lo que te permite rutear el tráfico de una región chica por el firewall de una vecina hasta que se justifique un firewall propio.

Un detalle que conviene no pasar por alto: la fuente recomienda un grupo de inspección por entorno, uno para producción, otro para entornos bajos y otro para egress. Compartir el firewall entre producción y test ahorra plata, sí, pero difumina justo el límite que te tomaste el trabajo de construir con los segmentos.

¿Se puede migrar de Transit Gateway a Cloud WAN sin interrumpir el servicio?

Sí, se puede migrar de Transit Gateway a Cloud WAN sin cortar el servicio, porque los dos coexisten de forma nativa. Construís la core network al lado de los Transit Gateways existentes y peereás cada Transit Gateway regional con su edge local de Cloud WAN.

Los prefijos de los Transit Gateways se propagan hacia Cloud WAN apenas se establece ese peering, así que la red nueva ya conoce las rutas viejas desde el primer día. A partir de ahí, la migración es VPC por VPC y no un big bang: vas moviendo attachments al ritmo que te convenga, sin ventana de corte total ni fin de semana largo de pánico. Ya lo cubrimos antes en guía para armar una arquitectura de producción.

Errores comunes al diseñar una red en AWS Cloud WAN

• Crear un segmento por equipo o por proyecto: termina siendo la misma maraña de route tables de antes, con otro nombre. La guía de dev.to recomienda quedarse en 12-15 segmentos organizados por entorno, no por organigrama.
• Dejar que una VPC tenga su propio NAT gateway: rompe el modelo de egress centralizado y abre un agujero que ningún firewall va a ver. Todo el tráfico de salida tiene que drenar hacia la VPC de inspección de su región.
• Activar appliance mode en todos los attachments: suma un salto cruzado entre zonas de disponibilidad sin ninguna ganancia en workloads normales. Solo tiene sentido en attachments hacia VPCs de inspección.
• Compartir un mismo grupo de inspección entre producción y entornos bajos: ahorra costo de firewall pero borra el límite de seguridad que separaba ambos mundos. Cada entorno crítico necesita su propio grupo.
• Dejar la aceptación manual activa en segmentos internos: si el mismo equipo controla la core network y las cuentas que se conectan, ese paso solo agrega demora sin sumar seguridad real, porque la ubicación ya la decide la política.

Preguntas Frecuentes

¿Qué es AWS Cloud WAN y en qué se diferencia de Transit Gateway?

AWS Cloud WAN es un servicio administrado que unifica en una sola red global lo que antes se armaba peereando Transit Gateways regionales a mano. La diferencia central es que Cloud WAN describe toda la red (segmentos, rutas, inspección) en un único documento de política versionado, mientras que Transit Gateway obliga a mantener route tables consistentes en cada región por separado.

¿Cómo funcionan los segmentos en AWS Cloud WAN?

Un segmento es un dominio de enrutamiento que existe en todos los edges de la red al mismo tiempo, así que dos attachments del mismo segmento se alcanzan entre regiones sin configuración extra. Attachments de segmentos distintos quedan aislados salvo que la política comparta rutas entre ellos de forma explícita, como pasa con el segmento de shared services hacia cada entorno.

¿Cómo se hace la inspección de tráfico entre regiones en Cloud WAN sin duplicar firewalls?

Se hace con network function groups y reglas send-via, que le dicen a la política qué flujos entre segmentos tienen que pasar por un grupo de VPCs de inspección. Como la core network ve el flujo completo de punta a punta, manda ambas direcciones por el mismo firewall aunque origen y destino estén en regiones distintas, así se evita el doble salto típico de Transit Gateway.

¿Se puede migrar de Transit Gateway a Cloud WAN sin interrumpir el servicio?

Sí, porque Cloud WAN y Transit Gateway coexisten mediante peering nativo entre cada Transit Gateway regional y su edge local. Los prefijos existentes se propagan automáticamente hacia la nueva red, lo que permite migrar VPC por VPC en lugar de hacer un corte total de una sola vez.

¿Cuántos segmentos necesita una red empresarial en Cloud WAN?

Entre 12 y 15 segmentos cubren la mayoría de los diseños empresariales, según la guía de arquitectura publicada en dev.to sobre una red en producción con varios cientos de cuentas AWS. Si el número crece mucho más que eso, suele ser señal de que se está creando un segmento por equipo en vez de por función de red.

Conclusión

AWS Cloud WAN cambia la pregunta de “¿cómo configuro esta ruta en esta región?” a “¿qué segmento describe esta intención?”. Eso importa para cualquier equipo que ya sufrió el mantenimiento de route tables en varias regiones, o que tuvo que explicar por qué un firewall inspecciona dos veces el mismo paquete.

Si tu operación no llega a manejar cientos de cuentas AWS en simultáneo, probablemente Transit Gateway solo o incluso una arquitectura más chica te alcance sin necesidad de sumar esta complejidad. Para infraestructura y hosting de proyectos locales que no requieren esta escala multi-región, con un proveedor sólido como donweb.com resolvés la parte de servidores y dominios sin meterte en diseño de core network policies. Ahora bien, si ya estás en el punto de pelear con route tables en cuatro regiones y firewalls que inspeccionan doble, la migración gradual que permite Cloud WAN (peering nativo, sin big bang) es el camino que describe la propia guía de AWS, y vale la pena evaluarlo con el equipo de red antes de que el problema crezca otra vuelta más.

Fuentes

• Architecting an Enterprise Network on AWS Cloud WAN – guía técnica de diseño en producción
• AWS WAN en la nube – Documento técnico oficial sobre infraestructura multi-VPC
• Blog oficial de AWS en español sobre Cloud WAN y redes empresariales
• FAQs oficiales de AWS Cloud WAN