¿Puedo usar mis licencias existentes de Palo Alto Networks o Fortinet en un hub de vWAN?

Sí, tanto los NVAs de Palo Alto Networks como los de Fortinet integrados con el hub de vWAN soportan el modelo "Bring-Your-Own-License" (BYOL). Esto le permite aprovechar los acuerdos empresariales y conjuntos de características existentes. También puede optar por el licenciamiento de pago por uso a través del Azure Marketplace.

¿Azure vWAN elimina por completo la necesidad de User-Defined Routes (UDRs)?

Para el enrutamiento de tránsito entre spokes, sucursales y datacenters, sí, la propagación dinámica de enrutamiento de vWAN reemplaza en gran medida los UDRs centrados en el hub. Sin embargo, seguirá utilizando UDRs dentro de una VNet spoke para tareas como forzar el tráfico de una VM de carga de trabajo a un dispositivo de seguridad local antes de que salga de la VNet.

¿Cuál es el rendimiento real de un NVA en un vWAN Secured Hub?

El rendimiento del NVA está directamente ligado al número de unidades de escala del hub de vWAN. Una sola instancia de NVA puede procesar hasta 20 Gbps. El sistema escala añadiendo más instancias de NVA, con un rendimiento máximo teórico que alcanza los 40 Gbps para Palo Alto y 100 Gbps para Fortinet a finales de 2023, una cifra que se espera que aumente para 2026.

¿Es suficiente Azure Firewall Premium para reemplazar mi NVA NGFW para 2026?

Para muchos casos de uso principales que requieren inspección TLS, IDPS y filtrado web, Azure Firewall Premium es una solución muy capaz y rentable. Sin embargo, las empresas que dependen de firmas de prevención de amenazas avanzadas y finamente ajustadas, control granular de Application-ID o integraciones de ecosistemas específicos de proveedores como Palo Alto o Fortinet, seguirán encontrando una profundidad de características superior en un NVA dedicado.

¿Cómo maneja vWAN la inspección de tráfico para la comunicación multi-región?

vWAN proporciona varios patrones. Puede implementar una solución de seguridad (Azure Firewall o NVA) en cada hub regional y usar "Routing Intent" para asegurar que todo el tráfico interregional sea inspeccionado en el hub de origen o destino, evitando el ineficiente tráfico "hair-pinning" a través del backbone global solo para los controles de seguridad.

¿Puedo conectar mi solución SD-WAN existente a Azure vWAN?

Sí, este es un caso de uso principal. Puede establecer túneles IPsec desde sus appliances SD-WAN (por ejemplo, Cisco, FortiGate, VeloCloud) a la "VPN gateway" de vWAN. El uso de BGP sobre estos túneles permite un intercambio de rutas sin fisuras entre miles de sitios de sucursales y sus VNets de Azure.

¿Es vWAN siempre más costoso que un hub-and-spoke tradicional?

No cuando se mide por el Total Cost of Ownership (TCO). Si bien el precio de lista de los componentes por hora de vWAN podría parecer más alto inicialmente, a menudo resulta ser más económico a escala. Esto se debe a la eliminación de los cargos de VNet peering para el tránsito y la reducción masiva de las horas operativas necesarias para gestionar tablas de rutas y la infraestructura de NVA.

Azure Virtual WAN vs Hub-and-Spoke: La Decisión Empresarial en 2026

Para los arquitectos de red empresariales, el debate entre Azure Virtual WAN (vWAN) y una topología hub-and-spoke autogestionada ya no es una simple cuestión de infraestructura gestionada versus no gestionada. Al mirar hacia 2026, la decisión se basa en una comprensión matizada de los patrones de tráfico, la profundidad de las características de los dispositivos de seguridad requeridos y el costo total de propiedad a escala. La promesa de un control casi infinito y programático sobre una "tela" de tránsito global hace de vWAN el valor estratégico predeterminado para la mayoría de las grandes empresas, moviendo la conversación más allá de la mera conectividad hacia una red inteligente y basada en políticas.

El Clásico Hub-and-Spoke: Máximo Control, Máxima Complejidad

El modelo tradicional de Azure hub-and-spoke es la traducción directa del diseño de un Datacenter On-Premises. Una Virtual Network (VNet) de "hub" central aloja servicios compartidos, siendo los más críticos un par de Network Virtual Appliances (NVAs) para la inspección de tráfico y el control de enrutamiento. Los "spokes", que albergan las cargas de trabajo de las aplicaciones, se conectan al hub a través de VNet peering. El control es explícito y granular, principalmente a través de User-Defined Routes (UDRs). Usted crea una tabla de rutas, la aplica a una subred y define el "next hop" para prefijos específicos, típicamente el Internal Load Balancer que está frente a su par de NVAs.

En este modelo, el NVA es el rey. Ya sea un Palo Alto Networks VM-Series ejecutando PAN-OS 11.2, un FortiGate-VM en FortiOS 7.6 o un Cisco Catalyst 8000V, usted retiene el control total sobre su configuración. Usted gestiona la alta disponibilidad (HA), el escalado (a través de VM Scale Sets) y las políticas de enrutamiento intrincadas directamente en el appliance. Esta es tanto su mayor fortaleza como su debilidad más significativa. La carga operativa de gestionar pares HA, tablas de rutas a través de docenas o cientos de spokes, y la infraestructura de VM subyacente es sustancial. Un cambio en la política de enrutamiento, como la introducción de un nuevo servicio en el hub, puede requerir la actualización de UDRs en cada VNet spoke, un proceso frágil y propenso a errores, incluso con prácticas maduras de Infrastructure as Code (IaC) usando Terraform o Bicep.

Virtual WAN: Azure como Proveedor Global de Tránsito

Azure Virtual WAN abstrae la infraestructura de red subyacente en un servicio gestionado por la plataforma. En su esencia, vWAN proporciona una arquitectura de red de tránsito global que simplifica la conectividad "any-to-any" entre sucursales (VPN/SD-WAN), usuarios remotos, datacenters (ExpressRoute) y VNets. Usted despliega un Virtual Hub en cada región de Azure requerida, y este hub actúa como el centro de su universo para esa geografía. La conectividad no se basa en peering, sino en "conexiones" al hub. El propio hub contiene routers gestionados que propagan automáticamente las rutas entre todas las entidades conectadas.

El diferenciador clave es este enrutamiento integrado. Cuando usted conecta una VNet al hub de vWAN, su espacio de direcciones es aprendido por el router del hub. Cuando usted conecta un circuito ExpressRoute, sus prefijos anunciados son aprendidos. El router del hub luego anuncia estas rutas aprendidas a todas las demás entidades conectadas según la política. Esto elimina la necesidad de una gestión manual de UDRs para el enrutamiento de tránsito. Añadir una nueva VNet o una nueva sucursal no requiere que usted toque la configuración de ningún spoke existente; el enrutamiento se actualiza dinámicamente. Esta es una solución a nivel de plataforma para el problema de escalabilidad que afecta los diseños clásicos de hub-and-spoke.

Secured Hub Deep Dive: Azure Firewall Premium vs. NVA Integrado

El "Secured Virtual Hub" es donde comienza la conversación sobre seguridad. Este es un hub de vWAN con un dispositivo de seguridad integrado. Tiene dos opciones principales: Azure Firewall o un NVA de terceros del Azure Marketplace.

Azure Firewall Premium: El Nativo Capaz

Para 2026, Azure Firewall Premium habrá madurado hasta convertirse en un NGFW-as-a-Service formidable. Ya proporciona características esenciales de prevención de amenazas como IDPS basado en firmas, inspección completa de TLS (una característica notoriamente difícil de implementar en la nube), filtrado de URL y filtrado de categorías web. Para la inspección de tráfico East-West entre spokes o para el tráfico de salida North-South, a menudo es suficiente. Su ventaja clave es ser un verdadero servicio de plataforma. Usted no gestiona las VMs subyacentes. Define una política, la asocia con el hub y Azure gestiona el escalado y la resiliencia. El throughput se define en implementaciones basadas en SKU, comenzando en 20 Gbps y escalando a más.

Sin embargo, no es un reemplazo directo para un NVA dedicado de primer nivel. Un equipo de seguridad acostumbrado a las políticas granulares de App-ID de un PA-5440 o a los "threat feeds" avanzados de un FortiGate 1800F encontrará que las capacidades de Azure Firewall son amplias, pero no tan profundas. Los conjuntos de firmas, aunque robustos, pueden no ser tan especializados, y la personalización de los perfiles de prevención de amenazas es menos granular que la disponible en un sistema operativo NVA dedicado como PAN-OS o FortiOS.

NVA en vWAN: ¿Lo Mejor de Ambos Mundos?

Para las organizaciones que requieren su marca específica de NGFW, vWAN permite el despliegue de NVAs directamente en el hub. Esto no es lo mismo que desplegar un NVA en una VNet de hub clásica. Cuando usted despliega un FortiGate o Palo Alto Networks NVA en un hub de vWAN, funciona como una aplicación gestionada. Azure gestiona el ciclo de vida, el escalado y la alta disponibilidad de los VMSS subyacentes. Críticamente, el enrutamiento se gestiona mediante BGP peering entre el NVA y el router del hub de vWAN. Ya no se aplican UDRs para forzar el tráfico al NVA; se utilizan las "Routing Intent and Policies" de vWAN para declarar qué flujos de tráfico (Privado, Internet) deben enviarse al NVA para su inspección primero. El NVA luego inspecciona el tráfico y, si está permitido, lo enruta de vuelta al router del hub para su entrega posterior. Esto mantiene el enrutamiento centralizado y dinámico de vWAN al mismo tiempo que permite una inspección de seguridad de primer nivel.

Análisis de Tamaño y Costo: Una Historia de Dos Topologías

Modelemos un escenario del mundo real para comparar los costos. Considere una empresa con presencia en "East US 2" y "West Europe". Cada región tiene un hub, 50 VNets spoke, un circuito ExpressRoute de 10 Gbps y 2,000 sucursales SD-WAN conectándose a través de VPN. Asuma 50TB de tráfico Inter-Spoke (VNet-to-VNet) por mes dentro de cada región.

Modelo de Costo Clásico Hub-Spoke (por región)

Cluster de NVA: Dos instancias de FortiGate-VM08 (para un rendimiento de protección contra amenazas de ~10 Gbps) con licenciamiento BYOL. Solo el costo del VM es aproximadamente $1.50/hora * 2 * 730 horas/mes = ~$2,190/mes. Añadir licencias de software a esto.
Azure Standard Load Balancer (Interno/Externo): ~$50/mes.
IPs públicas: ~$20/mes.
VNet Peering (El Costo Crítico): Este es el costo crítico. El tráfico que fluye de Spoke A -> Hub -> Spoke B se cobra por el ingreso y la salida en el enlace de peering. Para 50TB de tráfico: 50 * 1024 GB = 51,200 GB. El costo es de $0.01 por GB. Entonces, 51,200 GB * $0.01/GB * 2 (ingreso/egreso) = $1,024/mes. Este costo escala linealmente con el volumen de tráfico.
Sobrecarga de Gestión: Este costo oculto es significativo. Las horas de ingeniería requeridas para gestionar UDRs, patching/actualizaciones de NVA y el failover de HA son sustanciales.

Modelo de Costo de Azure Virtual WAN (por región)

Hub de vWAN Estándar: ~$1.25/hora * 730 horas = ~$912.50/mes.
Conexiones de VNet: 50 conexiones * $0.05/hora * 730 horas = $1,825/mes.
Unidades de Escala: Para manejar ~10 Gbps de tráfico de VNet, usted necesitaría 5 unidades de escala (2 Gbps por unidad). Estas cuestan $0.25/hora cada una. 5 * $0.25/hora * 730 horas = $912.50/mes.
Procesamiento de Datos (VNet-to-VNet): vWAN cobra por el tráfico procesado a través del hub. Para nuestros 50TB: 51,200 GB * $0.02/GB = $1,024/mes. Esto es comparable al costo de peering, pero es más predecible e incluye la infraestructura de enrutamiento.
Azure Firewall Premium: Un despliegue con capacidad de procesamiento de 10 Gbps y características premium tiene un costo de ~$2,500/mes.

A primera vista, los costos de los componentes de vWAN parecen más altos. Sin embargo, el modelo de vWAN elimina por completo los cargos de VNet peering para el tráfico de tránsito. Más importante aún, reduce drásticamente el costo operativo de gestionar la compleja red de UDRs y NVAs autogestionados. El Total Cost of Ownership (TCO) a escala, especialmente en escenarios multiregión, a menudo favorece a vWAN.

Enrutamiento Multi-Región: La Ventaja Injusta de vWAN

Aquí es donde vWAN realmente eclipsa el modelo clásico. En una configuración tradicional, conectar dos hubs regionales requiere otro conjunto de NVAs para VPN de hub a hub o usar Global VNet Peering. El Global Peering es costoso (~$0.035-$0.12/GB dependiendo de la región) y crea una malla punto a punto que no escala. Con vWAN, los hubs se conectan a través del backbone global de Microsoft por defecto. Los routers del hub regional intercambian rutas, proporcionando una conectividad inter-hub sin fisuras. Usted obtiene una red global totalmente enrutada gestionada por la plataforma. Ampliar su red a una nueva región es tan simple como desplegar un nuevo hub de vWAN y conectarlo; el enrutamiento global se actualiza automáticamente.

Trampa Común: La Mentalidad de "Lift and Shift" de NVA en vWAN

Un error frecuente es intentar gestionar un NVA dentro de un hub de vWAN como si estuviera en una VNet estándar. No se puede, por ejemplo, asignar múltiples interfaces de red al NVA o configurar manualmente la HA. La plataforma se encarga de esto. Su interacción no es con la VM, sino con la sesión BGP que establece con el router del hub y las "Routing Intent Policies". Su objetivo es influir en las decisiones de enrutamiento del hub de vWAN mediante el anuncio de rutas específicas desde el NVA, no cablear manualmente la red con UDRs. Tratar el NVA como solo un motor de políticas que recibe tráfico a través de una política declarativa es el modelo mental correcto.

Cuándo NO usar Virtual WAN (Edición 2026)

A pesar de sus ventajas, vWAN no es una solución universal. Hay escenarios específicos en los que un hub-spoke clásico o incluso una topología más simple sigue siendo superior.

Despliegues Pequeños y de Una Sola Región: Si su huella de nube completa consiste en menos de 10-15 VNets en una sola región con tráfico modesto, vWAN es excesivo. El costo y la complejidad de una VNet de hub simple con Azure Firewall Basic/Standard o un pequeño par de NVAs de FortiGate/Palo Alto serán significativamente menores.
Enrutamiento Hiper-Personalizado: El motor de enrutamiento de vWAN es potente pero dogmático. Si su arquitectura depende de comportamientos de enrutamiento complejos y no estándar, como Policy-Based Routing (PBR) basado en IP de origen o métricas de capa de aplicación que no se pueden expresar a través de BGP o vWAN Routing Intent, necesitará el control total de un NVA en una VNet de hub clásica (potencialmente con Azure Route Server para facilitar la propagación de BGP).
Topologías de NVA no Compatibles: Si su arquitectura de seguridad exige una característica de NVA muy específica y no compatible, por ejemplo, un protocolo de clustering propietario de un proveedor que requiere adyacencia de capa 2 o virtualización de múltiples contextos que no se alinea con el modelo de "NVA como un appliance" en vWAN, se verá obligado a una arquitectura de hub DIY.

Conclusión: La Elección Estratégica para la Escala Empresarial

Para 2026, para cualquier organización que opere a una escala significativa en múltiples regiones de Azure, la elección es clara. La agilidad operativa, el enrutamiento global automatizado y la escalabilidad predecible de Azure Virtual WAN la convierten en la base superior. Si bien el modelo clásico de hub-and-spoke ofrece un control máximo, ese control conlleva el alto precio de la complejidad y la fragilidad operativa. La capacidad de insertar NVAs NGFW de primera clase en el hub de vWAN mitiga el principal inconveniente histórico, combinando la escala nativa de la plataforma con una seguridad especializada. El debate ya no se trata de cuál ofrece más características, sino de cuál proporciona la plataforma más inteligente y escalable para una red empresarial global.

Para diseñar su red Azure de próxima generación y evaluar el TCO preciso para su entorno, explore nuestros servicios de consultoría expertos en techleague.io. También puede interesarle nuestros análisis detallados sobre Azure Route Server for Advanced NVA Integration o Securing ExpressRoute Private Peering End-to-End.