Multi-Cloud VPN: conectando AWS, Azure y Yandex Cloud a través de Transit Gateway y Virtual WAN

Introducción: por qué tu negocio necesita Multi-Cloud VPN y por qué es ahora

Integrar varias nubes en una red segura, unificada y predecible ya no es una rareza de ingenieros, sino una necesidad operativa. En 2026, las empresas están pasando masivamente de estrategias de monoclaud a entornos multi-nube: dividen riesgos, optimizan costos, cumplen con requisitos de localización de datos y aceleran el lanzamiento de productos. La pregunta es: ¿cómo enlazar AWS, Azure y Yandex Cloud para que funcione estable, escale sin complicaciones y pase auditorías de seguridad?

Esta guía es tu acompañante práctico. Veremos conceptos básicos y avanzados, mostraremos arquitecturas funcionales basadas en AWS Transit Gateway y Azure Virtual WAN, integraremos Yandex Cloud y sitios on-prem adicionales, y finalizaremos con monitorización, automatización y economía. Recibirás instrucciones paso a paso, listas de verificación, plantillas de diseño, recomendaciones para alta disponibilidad, soluciones para redes superpuestas y casos de referencia.

Fundamentos: conceptos clave para Multi-Cloud VPN

Bloques constructores esenciales

• VPC/VNet/Redes en Yandex Cloud: redes privadas aisladas con enrutamiento a nivel de hipervisor. Planificar el espacio de direcciones CIDR es la base de la resiliencia. Se recomienda asignar bloques no superpuestos por dominios (prod, no-prod, shared) y regiones.
• IPsec VPN (IKEv2): estándar industrial de cifrado en capa 3. Usado en conexiones Site-to-Site entre nubes y con on-prem. Soporta conjuntos de cifrado con PFS (Perfect Forward Secrecy) y aceleración por hardware (AES-GCM).
• BGP: protocolo dinámico de enrutamiento sobre túneles protegidos. Permite anunciar y retirar prefijos automáticamente, formar ECMP multipath y controlar prioridad de tráfico (AS-Path prepending, MED, comunidades).
• Hub-and-Spoke: topología base donde el hub maneja enrutamiento, segmentación e inspección de servicios (FW, IDS/IPS), y los spokes son VPC/VNet aplicativas.
• AWS Transit Gateway (TGW): backbone regional L3 para agregar VPC, VPN y Direct Connect. Administra tablas de rutas y propagación de prefijos entre attachments.
• Azure Virtual WAN (vWAN): red global de Microsoft para simplificar la conexión de sucursales, VPN, ExpressRoute y VNet. Frecuentemente usado como hub multi-nube por su amplia cobertura geográfica.
• Yandex Cloud VPN: gateways IPsec gestionados con soporte para enrutamiento dinámico (BGP) y alta disponibilidad mediante múltiples túneles/zona. Para alto ancho de banda — Cloud Interconnect o routers virtuales.

Modelo de seguridad y segmentación

• Segmentación en L3: definición de zonas de confianza (prod, dev, servicios compartidos, partners). Control del enrutamiento entre zonas mediante tablas TGW/vWAN separadas y políticas de firewall.
• Control de L4-L7: firewalls en la nube (Azure Firewall en Secure Hub, AWS Network Firewall o NGFW de terceros). Inspección de tráfico, desencriptación TLS (donde sea permitido), IDS/IPS, seguridad DNS.
• Principios Zero Trust: acceso mínimo necesario, autorización explícita de servicios, tiempos cortos de lease, validación constante de estado de túneles y rutas.

Parámetros que afectan la estabilidad

• MTU/MSS: debido a la encapsulación IPsec, la MTU útil se reduce. Configura MSS clamping (normalmente 1350-1380) en gateways fronterizos para evitar fragmentación y pérdidas.
• DPD y renegociaciones: Dead Peer Detection y temporización de rekey. Coordina lifetimes de IKE SA y Child SA en ambos extremos.
• ECMP y modo activo-activo: múltiples túneles con costo igual mejoran el ancho total y alta disponibilidad.
• NAT-T: transporte IPsec sobre UDP/4500 cuando hay NAT en el camino. Obligatorio al conectar por internet con cambio de dirección.

Deep dive: aspectos avanzados poco documentados

CIDR superpuestos: cómo manejarlo

Bloques heredados 10.0.0.0/8 suelen superponerse en fusiones y migraciones multi-nube. Soluciones:

• NAT en el borde: en Azure es posible VPN NAT en gateway (bidireccional/unidireccional) para traducir prefijos. En AWS y Yandex mediante routers virtuales (VyOS/FRR) o NGFW con NAT.
• Segmentación y re-direccionamiento: re-IP gradual es la opción estratégica más limpia, aunque costosa durante la migración. Combina con NAT temporal para servicios críticos.
• Enrutamiento específico por prefijo: asigna subredes conflictivas a tablas TGW/vWAN separadas, evita la propagación automática y usa importación estática solo de prefijos necesarios.

Ingeniería BGP en nubes

• ASNs: en AWS TGW puedes asignar ASN privado (por defecto 64512, rango extendido 4200000000+ disponible). En Azure vWAN, hubs y gateways VPN usan ASN de servicio (privado), se configura ASN local para on-prem/peer. Coordina unicidad.
• Prioridad de tráfico: AS-Path prepending y MED para designar túnel activo y reserva. Dentro del mismo proveedor, preferencia local en tabla suele bastar.
• Agregación: agrupa redes a /16-/20 donde sea posible para reducir ruido y riesgos por congestión de tablas.

Capacidad y SLA

• Límites de túneles: gateways VPN gestionados tienen límites de throughput por túnel y en agregados. Diseña sobre capacidad P95+ N+1 con margen 20-30%, no en picos.
• Multi-región: minimiza hairpin. Hubs regionales cerca de consumidores bajan latencia y costo de egress.
• Cuándo usar transporte privado: si P99 es sensible al jitter, considera canales privados (Direct Connect, ExpressRoute) a un punto de intercambio y luego IPsec a la tercera nube. Más complejo, pero predecible.

Seguridad: perfiles cripto y claves

• Conjuntos de cifrado: AES-256-GCM con PFS (DH Group 14/19/20) es buen balance. Alinea lifetimes (ejemplo: IKE 8h, Child 1h), incluye margen para rekey.
• Gestión de claves: PSK en secretos (AWS Secrets Manager, Azure Key Vault, Yandex Lockbox). Automatiza rotación.
• Logging: activa flow logs, auditorías de cambios y métricas de estado de túneles.

Práctica 1: AWS Transit Gateway como hub multi-nube

Cuándo elegirlo

Si ya estás en AWS, la mayoría de workloads y funciones de red están ahí, y necesitas conectar Azure y Yandex Cloud con mínimos componentes extra. TGW actúa como router central, Azure/Yandex como sitios VPN.

Diagrama

VPC (prod/dev/shared) conectadas a TGW. Para cada nube externa creamos VPN attachment con dos túneles. BGP propaga prefijos entre VPC y nubes externas. Tablas de rutas TGW separadas aseguran segmentación.

Instrucciones paso a paso

1. Plan de direcciones: asigna CIDR únicos para todas las VPC y redes destino Azure VNet y Yandex VPC. Elabora matriz de acceso (quién accede a quién y por qué puertos).
2. Crear TGW: elige ASN privado (ej. 64520). Habilita tablas de ruta por zonas de confianza: prod-rt, dev-rt, external-rt.
3. Conectar VPC: crea attachments VPC, asigna tablas TGW correspondientes. Habilita propagación solo donde es necesaria.
4. Conectar Azure: obtén IPs públicas del Azure VPN Gateway (activo-standby o activo-activo). En AWS crea Customer Gateway, luego Site-to-Site VPN hacia Azure. Selecciona Transit Gateway attachment, IKEv2, conjuntos de cifrado. Activa BGP, asigna pares /30 para túneles según plantilla Azure.
5. Conectar Yandex Cloud: similar, crea Customer Gateway a IPs públicas de Cloud VPN Yandex. Levanta 2 túneles con BGP (zonas distintas), ASN únicos. Coordina lifetimes y DPD.
6. Enrutamiento: en TGW activa propagación de prefijos desde VPN attachments en external-rt y asociacion selectiva con VPC necesarias. Desactiva propagación amplia en prod-rt/dev-rt, importa solo prefijos requeridos.
7. Segmentación y FW: pasa tráfico entre VPC y redes externas a través de VPC de inspección con NGFW (GWLB o appliance). Configura rutas vía endpoint de firewall.
8. Pruebas: verifica sesiones BGP, prefijos, MTU/MSS. Usa Iperf3 para ancho de banda, pruebas básicas de apps, exporta métricas.

Esqueleto Terraform

• Módulos: tgw, attachments, vpn, route-tables, firewall-vpc.
• Variables: asn, cidr_map, bgp_params, ike_params, fw_endpoints.
• Pipeline: plan — revisión de seguridad — apply en no-producción, luego change set en producción.

Check-list para hub TGW

• ASNs únicos y perfiles IKE alineados.
• Dos túneles por enlace, ECMP activado.
• Aislamiento de rutas por tablas, asociación/propagación explícita.
• MSS clamping en interfaces frontera.
• Flow Logs y alarmas CloudWatch sobre estado de túneles.

Práctica 2: Azure Virtual WAN como backbone global

Cuándo elegirlo

Presencia fuerte en Azure, muchas sucursales o necesidad de optimización global de rutas sobre backbone Microsoft. El hub vWAN cerca de usuarios asegura latencia predecible, y NAT VPN facilita lidiar con CIDR superpuestos.

Diagrama

Se crea Virtual WAN y uno o varios Virtual Hub (en las regiones de los usuarios). Se conectan VNet (spokes), luego sitios VPN: AWS (a través de TGW VPN o VGW), Yandex Cloud (mediante Cloud VPN). Se activa Secure Hub con Azure Firewall para inspección.

Instrucciones paso a paso

1. Crea vWAN y Virtual Hub: elige región(es), SKU de VPN Gateway, y si es necesario Secure Hub (Azure Firewall).
2. Conecta VNet: mediante conexiones al hub con enrutamiento basado en políticas (propagación/asociación).
3. Conectar AWS: en Azure crea VPN Site con datos del lado AWS (IP públicas de túneles). En AWS crea Site-to-Site VPN hacia Azure con attachment TGW. Activa BGP en ambos extremos.
4. Conectar Yandex Cloud: similar, crea VPN Site en Azure, túneles a Yandex Cloud VPN. Si hay CIDR superpuestos, configura VPN NAT en Azure Gateway (política: inbound/outbound según necesidad).
5. Enrutamiento en vWAN: configura propagación y asociación hacia tablas de ruta necesarias, limita propagación en VNets sensibles. Exporta solo prefijos agregados.
6. Inspección de tráfico: via Azure Firewall en Secure Hub, configura reglas DNAT/SNAT si hacen falta, filtros FQDN, modo IDS.
7. Pruebas y SLO: monitoreo BGP y túneles con Azure Monitor, logs de FW, control de latencias P95/99.

Características de vWAN

• Enrutamiento flexible con múltiples tablas en el hub.
• NAT incorporado en VPN Gateway para facilitar fusiones y adquisiciones.
• Alta integración con sucursales y SD-WAN CPE.

Práctica 3: Conectando Yandex Cloud a AWS y Azure

Opciones

• A través de AWS TGW: Yandex Cloud VPN Site-to-Site a TGW. Componentes mínimos en Yandex, BGP dinámico, dos túneles en zonas diferentes. Ideal si el hub está en AWS.
• A través de Azure vWAN: Yandex Cloud VPN Site-to-Site a hub virtual. Forma sencilla de usar NAT Azure para resolver conflictos de direcciones.
• Via routers virtuales: VyOS/FRR en Yandex y AWS/Azure para protocolos fuera del estándar (por ejemplo, WireGuard para replicación entre nubes, si las políticas permiten).

Integración paso a paso de Yandex Cloud VPN

1. Plan y zonas: selecciona zona(s) Yandex para ubicar gateways VPN. Asegura resiliencia: mínimo 2 túneles por nube.
2. Crear Cloud VPN: crea gateway, establece parámetros IKEv2, conjuntos de cifrado, lifetimes. Define IP públicas de gateways remotos AWS/Azure.
3. BGP: asigna ASN privado para Yandex, coordina direcciones /30 para puntos BGP y prefijos de anuncio (agregaciones por entorno).
4. Rutas y tablas: asigna tablas de rutas a subredes y servicios. Enruta tráfico explícito a prefijos remotos via VPN gateway, excluyendo rutas locales a internet.
5. Chequeos: estabilidad BGP, logs IPsec, caída de un túnel no debe cortar conexión.

Rendimiento y cuándo usar Interconnect

Si la carga es constante y sensible al jitter (ej.: bases de datos síncronas), contempla canales privados a punto de intercambio y construcción IPsec allí. Yandex Cloud Interconnect ofrece SLA predecibles, luego IPsec puede extenderse a AWS/Azure mediante la misma conexión.

Práctica 4: Alta disponibilidad, automatización y operación

Patrones HA

• Múltiples túneles: al menos dos túneles entre cada par de dominios. Preferible en diferentes zonas/hubs regionales.
• ECMP: habilitar enrutamiento igualitario para ancho agregado y convergencia rápida.
• Salud de rutas: ocultar prefijos ante degradación (route health injection), integración con gestores de health-check.
• Dirección de tráfico: activo-activo para flujos menos críticos, activo-pasivo para sensibles al jitter.

Observabilidad y SLO

• Métricas: estado up/down de túneles, recuento de rekey, paquetes caídos, ancho por túnel, caídas de sesiones BGP, latencias P50/P95/P99, pérdidas, jitter.
• Logs: IPsec/IKE, flow logs, eventos de firewall. Correlación mediante bus único de logs.
• Alertas: violación de SLO, anomalías en ancho, aumento de RTT, caída de rutas, sobrecostos de egress.

Automatización e IaC

• Terraform: módulos comunes para AWS, Azure y Yandex. Parametriza perfiles cripto, ASN, esquemas de rutas. Separa estados por entornos, usa backends remotos y bloqueos.
• CI/CD: procesos PR, análisis estático, vista previa de planes, seguridad de secretos. Calendario de cambios y despliegues canary para modificaciones de red.
• Detección de desviaciones: validaciones periódicas, política de “no cambios manuales” en producción.

Pruebas

• Tests unitarios IaC: policy-as-code (regex para conjuntos de cifrado, restricciones de puertos).
• Chaos drills: desconexión de un túnel, degradación de cifrado, caída de zona. Espera convergencia rápida y mantenencia de SLO.
• Pruebas de carga: iperf3 en ambas direcciones, perfilado de packet loss con MSS variable.

Práctica 5: Seguridad y cumplimiento por defecto

Perfil seguro mínimo

• AES-256-GCM, PFS activado, DH grupo 14/19, solo IKEv2.
• Rekey Child SA 60 minutos, IKE 8 horas, DPD 10-15 segundos, 3-5 intentos.
• MSS clamping 1360 (ajustar tras test de descubrimiento MTU path).
• Prohibición de rutas generales (ej. 0.0.0.0/0) en BGP salvo decisión consciente vía hub de inspección.

Segmentación de acceso

• Tablas de rutas separadas en TGW/vWAN para prod/dev/partners.
• Inspección obligatoria de tráfico inter-zonas mediante firewall.
• Control de DNS y egress vía proxy/firewall.

Secretos y gestión de claves

• Almacenamiento de PSK/certificados en gestores de secretos, rotación programada.
• RBAC y acceso break-glass con auditoría.

Práctica 6: Economía y rendimiento

Modelo de costos

• Componentes: tarifas por gateways (por hora/throughput), tráfico egress/ingress, procesamiento de rutas en TGW/vWAN, inspección FW, NAT.
• Topología: hubs locales reducen egress interregional, mientras un backbone norte-sur centralizado puede generar cuello de botella y altos costos.
• Reserva: túneles N+1 aumentan costos, pero aseguran estabilidad. Balancea con SLO.

Optimización

• Agregación de rutas en lugar de miles de prefijos pequeños.
• Localidad de tráfico — mantenerlo dentro de la región.
• Desactivación automática de túneles no usados en entornos de prueba según agenda.

Práctica 7: Resolviendo casos complejos

CIDR superpuestos con mínima interrupción

1. Inventario de conflictos: qué subredes se comunican realmente.
2. NAT temporal en frontera (Azure VPN NAT o FW NAT) para pares conflictivos.
3. Re-IP gradual en ventanas de mantenimiento. Control de compatibilidad hacia atrás.
4. Eliminación de NAT temporal y simplificación de rutas.

WireGuard/OpenVPN sobre nubes

Para replicación entre nubes o puertos no estándar, levanta routers virtuales (Linux+WireGuard, VyOS, FRR) y termina en VPC/VNet separado con integración de rutas en TGW/vWAN. Considera requisitos de seguridad y cumplimiento.

Errores comunes que evitar

• Propagación automática total: causa conexiones no intencionadas y amplía la blast radius.
• CIDR idénticos: ahorra tiempo al inicio pero lleva a re-IP de meses después.
• Ignorar MTU/MSS: timeouts misteriosos y caídas raras suelen ser por fragmentación.
• Estática en vez de BGP: rutas manuales escalan mal y son riesgosas ante fallos.
• Falta de inspección: L3 sin control de puertos ni FQDN no pasa auditoría.
• Un solo hub para todas las regiones: latencias y costos de egress crecen exponencialmente.
• Secretos en configuraciones abiertas: PSK en texto plano es ruta directa a incidentes.

Herramientas y recursos recomendados

Servicios en la nube

• AWS: Transit Gateway, Site-to-Site VPN, Network Firewall, CloudWatch, VPC Flow Logs, Gateway Load Balancer.
• Azure: Virtual WAN, VPN Gateway (incluyendo VPN NAT), Azure Firewall (Secure Hub), Azure Monitor, Network Watcher.
• Yandex Cloud: Cloud VPN, Security Groups, Route Tables, Cloud Interconnect, Yandex Monitoring y Logs.

Routers virtuales y NGFW

• VyOS, FRR (BGP), StrongSwan/Libreswan, pfSense y NGFW comerciales (Palo Alto, Fortinet, Check Point, Cisco) para políticas sofisticadas, NAT e inspección.

IaC, pruebas y monitorización

• Terraform (multicloud), Terragrunt para estructurar.
• InSpec/OPA/Conftest para policy-as-code.
• iperf3, tcptraceroute, mtr para validaciones de red.
• Prometheus/Grafana, exportadores VPN y BGP, alertas en SLO.

Inicio rápido para pilotos

Para pilotos y pruebas de concepto que requieren levantar rápido un VPN corporativo entre equipos de desarrollo y entornos multinube, una opción práctica es vpn.how. Es un servidor VPN personal con IP dedicada (no compartida), que soporta WireGuard, OpenVPN, IKEv2, L2TP, SSTP — eliges protocolo según caso y restricciones de red. Tiene ubicaciones en Moscú, San Petersburgo, Ámsterdam, Fráncfort, Londres, Nueva York, San José, Chicago, Singapur, Sídney, Madrid, Helsinki, Estocolmo, Varsovia, Copenhague, Stavanger. Acepta tarjetas rusas (incluyendo Tinkoff y Ozon), SBP, USDT/BTC. Tarifas desde 490 ₽ por día y desde 2490 ₽ al mes con descuentos por periodos largos, activación en 5 minutos tras pago, sin logs. Ideal para ambientes rápidos y reconocimiento de red sin trámites largos. Para producción es mejor construir infraestructura propia gestionada o considerar VPN con certificación GOST según requisitos regulatorios.

Casos y resultados: qué muestra la práctica

Caso 1: Fintech, hub en AWS TGW

Contexto: 120+ microservicios en AWS, analítica en Azure, parte de la lógica de pagos en Yandex Cloud por requerimientos de localización. Solución: TGW como hub, dos túneles a Azure y Yandex, BGP con agregación, VPC de inspección con NGFW. Resultados: Latencia P95 AWS↔Azure 28-35 ms (EU), alta disponibilidad ante caída de túneles con caídas de ancho no mayores al 35%, auditoría PCI DSS aprobada gracias a segmentación clara y logging. Optimización de egress redujo costos ~18% en el primer trimestre.

Caso 2: Data/ML, hub en Azure vWAN

Contexto: DWH y pipelines ML en Azure, APIs de alta demanda en AWS, Yandex Cloud para inferencia local. Solución: Virtual WAN con dos hubs (Europa Oeste, Este), VPN a AWS TGW y Yandex Cloud VPN, Azure Firewall en Secure Hub, VPN NAT para pares subredes conflictivas. Resultados: Conflictos de direcciones resueltos sin downtime, ancho agregado ~2-3 Gbps por 4 túneles, incidentes reducidos 40% tras unificación de observabilidad.

Caso 3: Fusiones y adquisiciones con CIDR superpuestos

Contexto: Unión de dos compañías con 10.0.0.0/8 parcial superpuesto. Solución: NAT temporal en Azure VPN, enrutamiento en vWAN con aislamiento de tablas, re-IP gradual de subredes críticas, luego abandono total de NAT. Resultados: Downtime cero en servicios cliente, complejidad de rutas reducida un 60% tras re-IP completo.

FAQ: preguntas frecuentes

1. ¿Es obligatorio BGP o puede ser estático?

Para pilotos, estático puede valer. Para producción y crecimiento, BGP es esencial: reduce errores humanos, acelera convergencia y da prioridades flexibles a rutas.

2. ¿Qué política de cifrado elegir?

AES-256-GCM con PFS, IKEv2. Lifetimes acordados, margen para rekey y DPD. Auditorías externas prefieren suites industriales.

3. ¿WireGuard sirve para corporaciones?

Sí, como opción de alto rendimiento, pero revisa cumplimiento y requisitos de logging. Más común junto a routers virtuales cercanos a IPsec.

4. ¿Qué hacer con MTU?

Empieza con MSS 1360, activa PMTUD, monitorea fragmentación. Si hay problemas, baja MSS a 1350-1340.

5. CIDR superpuestos. ¿Siempre se necesita re-IP?

No siempre. A corto plazo ayuda NAT en VPN Gateway (Azure) o NGFW. Estratégicamente, sí, para evitar deuda técnica.

6. ¿Cómo controlar costos?

Localiza tráfico, agrega rutas, evita tráfico norte-sur único, analiza egress y procesamiento FW, apaga entornos cuando no se usan.

7. ¿Qué es mejor para hub: TGW o vWAN?

Si el foco está en AWS — TGW; si en Azure o tienes muchas sucursales/SD-WAN — vWAN. A menudo se usa híbrido: hubs regionales en ambas nubes.

8. ¿Qué SLA es alcanzable?

Con VPN por internet es realista 99.9-99.95 con múltiples túneles y regiones. Para críticos: canales privados + IPsec, monitorización y RHI.

9. ¿Cómo integrar inspección?

Mediante VPC/VNet de inspección con NGFW y rutas dirigidas (UDR, tablas TGW, hub seguro vWAN). Registra y automatiza reglas.

10. ¿Y DNS en multi-nube?

Resolución zonal con reenvío condicional entre resolvers en la nube, caching, control de egress DNS y protección contra fugas.

Conclusión: hoja de ruta hacia una red multi-nube confiable

Una red unificada entre AWS, Azure y Yandex Cloud es un proceso maduro, gestionado y auditado. Empieza con plan de direcciones y necesidades de tráfico, escoge hub (TGW o vWAN), estandariza perfiles cripto, activa BGP y segmentación, inspecciona tráfico, automatiza con Terraform y CI/CD, y consolida todo con métricas y SLO. Para POC actúa rápido y pragmático; para producción, justifica SLO, incluye N+1, planifica operación, observabilidad y presupuesto. Así obtendrás una red que no solo funciona, sino que resiste crecimiento, auditorías y fallos inesperados.

Apéndice: checklist rápida de diseño

• Plan de direccionamiento: CIDR únicos, agregabilidad, matriz de acceso.
• Hub: TGW o vWAN (o ambos), regionalización, tablas de rutas.
• Cifrado: IKEv2, AES-GCM, PFS, lifetimes, DPD.
• Túneles: mínimo 2 por enlace, ECMP, zonificación.
• Enrutamiento: BGP, prepending, MED, agregación, RHI.
• Segmentación y FW: hub de inspección, políticas L7, control de egress.
• MTU/MSS: iniciar en 1360, validar y ajustar.
• IaC: Terraform, policy-as-code, CI/CD, secretos.
• Observabilidad: métricas, logs, alertas, SLO, ejercicios regulares de fallo.
• Economía: localización de tráfico, egress, apagado de entornos, tarifas de gateways.