topología de red de Azure Virtual WAN

En este artículo se explica cómo diseñar una red con Azure Virtual WAN. Virtual WAN proporciona infraestructura de concentrador administrado Microsoft con enrutamiento automático, integración de SD-WAN nativa y tránsito global integrado entre centros.

Lo que trata este artículo

En este artículo se abordan la arquitectura del centro de conectividad de Virtual WAN, el enrutamiento automático y la propagación de rutas, la comparativa entre los niveles Básico y Estándar, la intención de enrutamiento para la inspección del tráfico, los patrones de integración de SD-WAN y el modelo de costes de Virtual WAN.

Quién necesita este artículo

Lea este artículo si se aplican una o varias de estas condiciones:

• Necesita tránsito gestionado entre múltiples sucursales, sitios, usuarios remotos o redes virtuales conectadas.
• Desea disponer de enrutamiento y conectividad de sucursales administrados por Microsoft en lugar de crear y administrar usted mismo un centro de tránsito personalizado.
• Necesita comparar Azure Virtual WAN con hub-and-spoke antes de decidirse por una topología.
• Espera que la red crezca más allá de un pequeño número de bordes de conectividad administrados manualmente.

Sugerencia

¿Sigue la ruta del escenario? Seleccione el escenario en la parte superior de la página para obtener instrucciones adaptadas. La guía básica siguiente se aplica a todos los lectores.

Enfoque lift-and-shift: Omita este artículo si se trata de una migración lift-and-shift estándar. La mayoría de los entornos lift-and-shift tienen menos de 30 conexiones de sucursales y operan en una o dos regiones. Una topología tradicional de tipo hub-and-spoke con VPN Gateway ofrece conectividad suficiente. Considere Virtual WAN solo si tiene muchos sitios de sucursal o planea una rápida expansión.

Enfoque de modernización: Este artículo es relevante cuando el programa de modernización incluye requisitos de tránsito a escala de sucursales o de varias regiones. La topología dual hub-and-spoke con VPN Gateways en cada región se adapta a la mayoría de los escenarios de modernización. Virtual WAN se vuelve relevante cuando se supera la complejidad de enrutamiento que puede admitir la administración manual de UDR.

Enfoque entre nubes: Virtual WAN es el modelo de tránsito recomendado cuando tiene varias nubes privadas virtuales (VPC), ramas, regiones o bordes de nube. Virtual WAN actúa como equivalente de Azure a AWS Transit Gateway, lo que proporciona una administración centralizada de enrutamiento y conectividad a escala. Si va a migrar desde un entorno de AWS que usa Transit Gateway, Virtual WAN se asigna directamente a ese modelo.

servicios y características de Azure

En la tabla siguiente se enumeran los servicios y características de Azure que admiten una topología de Virtual WAN:

Servicio o característica	Rol en Virtual WAN	Aprende más
Azure Virtual WAN	Proporciona la red global de tránsito gestionada y la infraestructura de concentradores	Información general de Virtual WAN
Centro de conectividad virtual	Red virtual administrada por Microsoft que aloja servicios de enrutamiento y puerta de enlace	Enrutamiento del centro de conectividad virtual
VPN Gateway (en el centro)	Conectividad VPN de sitio a sitio y de punto a sitio para sucursales	Virtual WAN VPN Gateway
Puerta de enlace de ExpressRoute (en el centro)	Conectividad privada desde centros de datos locales a través de circuitos ExpressRoute	ExpressRoute para Virtual WAN
Administrador de Firewall de Azure	Administración centralizada de directivas de seguridad para centros virtuales protegidos	Introducción a Firewall Manager
Intención de enrutamiento	Dirección automática del tráfico a través de una solución de seguridad sin tablas de rutas personalizadas	Intención de encaminamiento

Cómo funciona

En una topología de Virtual WAN:

1. Un recurso de Virtual WAN actúa como el contenedor de nivel superior que agrupa uno o varios centros virtuales entre regiones.
2. Cada centro virtual es una red virtual administrada Microsoft. El centro contiene puntos de conexión de servicio para los servicios vpn, ExpressRoute y firewall. No se implementa ni se administra directamente la red virtual de concentrador.
3. Las VNet spoke se conectan a un hub virtual a través de conexiones VNet (similar al peering en la topología hub-spoke tradicional). El enrutador del centro virtual controla todo el enrutamiento automáticamente.
4. Los sitios de sucursal se conectan a través de vpn de sitio a sitio o puertas de enlace de ExpressRoute implementadas dentro del centro virtual.
5. Al implementar varios concentradores, se interconectan automáticamente a través de la red troncal de Microsoft, lo que permite el tránsito global sin enrutamiento administrado por el cliente.

Enrutamiento del centro de conectividad virtual

El enrutador del centro virtual administra todo el enrutamiento entre redes virtuales conectadas, ramas y otros centros. Comportamientos clave:

• Tránsito automático: Las redes virtuales conectadas al mismo centro pueden comunicarse sin UDR. El enrutador del concentrador propaga las rutas entre todas las conexiones de forma predeterminada.
• Tránsito entre centros: Las rutas se propagan automáticamente entre centros en la misma Virtual WAN. El tráfico entre regiones fluye a través de la red troncal de Microsoft.
• Tablas de rutas: Para escenarios de aislamiento avanzados (como aislar el desarrollo de producción), puede crear tablas de rutas personalizadas dentro del centro para controlar la propagación de rutas.
• Rendimiento agregado: El enrutador de concentrador virtual admite un rendimiento agregado de hasta 50 Gbps cuando se configura con el máximo de 50 unidades de infraestructura de enrutamiento. La implementación predeterminada usa 2 unidades de infraestructura de enrutamiento (3 Gbps). Puede ampliar el rendimiento aumentando las unidades de infraestructura de enrutamiento en la configuración del hub.

Note

El enrutamiento automático se aplica a la conectividad de tránsito estándar. Los escenarios personalizados que dirigen el tráfico a través de dispositivos virtuales de red (NVA) en el concentrador podrían requerir tablas de rutas personalizadas.

Cómo elegir

Esta sección le ayuda a seleccionar la topología y el nivel adecuados para su entorno.

Hub-spoke frente a Virtual WAN

Utilice esta tabla para determinar si una topología hub-and-spoke tradicional o una Virtual WAN es la opción adecuada para su entorno:

Factor	Hub-and-spoke (tradicional)	Azure Virtual WAN
Administración	Red virtual del centro administrado por el cliente	infraestructura del centro administrado Microsoft
Mejor para	Hasta ~30 conexiones VPN de sucursal	Más de 30 ramas de VPN o muchas regiones de Azure
Enrutamiento	El cliente configura los UDR para el tráfico de ramal a ramal	Enrutamiento automático en el centro virtual
integración de SD-WAN	Implementación y configuración manual de NVA	Integración nativa de socios de SD-WAN
Tránsito global	Requiere enrutamiento entre regiones administrado por el cliente	Integrado: todos los concentradores se interconectan automáticamente
Modelo de costo	Los recursos de la VNet del hub se pagan por separado (Firewall, puerta de enlace, Bastion)	Precios de las unidades de implementación y escalado

Sugerencia

La Virtual WAN es una alternativa escalable a la topología hub-and-spoke, no un sustituto. Las organizaciones con menos de 30 sucursales, una sola región y que necesiten un control total sobre los recursos del nodo central deben utilizar una topología tradicional de tipo hub-and-spoke.

Consideraciones sobre la migración: Si vas a pasar de una topología tradicional de tipo hub-and-spoke a una Virtual WAN, planifica una migración en paralelo. Implemente un hub de Virtual WAN junto con el hub existente, migre gradualmente las conexiones de spoke y valide el enrutamiento después de migrar cada conexión. Virtual WAN no admite la importación de configuraciones de UDR existentes, por lo que debe rediseñar el enrutamiento para usar el modelo de propagación automática del enrutador del concentrador.

Cuándo seguir con una arquitectura hub-and-spoke: Elija una arquitectura hub-and-spoke tradicional si necesita un control detallado sobre la red virtual del concentrador (por ejemplo, implementar NVA personalizadas directamente en la subred del concentrador), si su organización opera en una sola región con menos de 10 sucursales, o si los requisitos de cumplimiento exigen una infraestructura de enrutamiento gestionada por el cliente.

Estándar en comparación con el nivel Básico

Virtual WAN ofrece dos niveles. Elija el nivel que se adapte a sus necesidades de enrutamiento y conectividad:

Feature	Basic	Standard
VPN de sitio a sitio	✅	✅
VPN de punto a sitio	❌	✅
ExpressRoute	❌	✅
Tránsito de VNet a VNet	❌	✅
Tránsito entre centros	❌	✅
Azure Firewall en el centro	❌	✅
NVA en el nodo central	❌	✅

Importante

Puede actualizar del nivel Básico a Estándar, pero no puede cambiar de Estándar a Básico. Elija Estándar si necesita cualquier enrutamiento de tránsito, conectividad de ExpressRoute o integración de seguridad.

Modelo de costo

La Virtual WAN utiliza una tarificación por unidad que difiere de la topología tradicional de tipo hub-and-spoke:

• Unidades de implementación (concentrador): Se paga una tarifa por hora para el propio centro virtual. Esta tarifa es un costo fijo para la infraestructura del centro administrado.
• Unidades de escalado (puertas de enlace): Las puertas de enlace de VPN y ExpressRoute se facturan en función del número de unidades de escalado que aprovisione. Más unidades de escalado aumentan la capacidad de ancho de banda y el costo proporcionalmente.
• Unidades de infraestructura de enrutamiento: El enrutador del concentrador se factura por unidad de infraestructura de enrutamiento. La implementación predeterminada incluye dos unidades (3 Gbps). Puede escalar verticalmente hasta 50 unidades (50 Gbps) para entornos de alto rendimiento.
• Procesamiento de datos: Pagas por los datos procesados a través del hub, incluidos el tráfico de VNet a VNet, de sucursal a VNet y entre hubs. El tráfico enlazado a Internet enrutado a través de Azure Firewall tiene cargos de procesamiento de datos independientes.
• Complemento de centro virtual protegido: Al implementar Azure Firewall a través de Firewall Manager, los cargos de Azure Firewall estándar también se aplican a los costos del centro de Virtual WAN.

Compara los costes con los de una topología tradicional de hub-spoke. En el caso de implementaciones pequeñas con ramas mínimas, un centro administrado por el cliente podría ser más rentable. En el caso de los recuentos de sucursales grandes (30+), la automatización y la infraestructura administrada de Virtual WAN suelen compensar los precios por unidad. Para obtener información detallada sobre los precios, consulte Virtual WAN conceptos de precios.

Centro virtual protegido: cuándo usar Firewall Manager

Un centro virtual protegido integra Azure Firewall (o una NVA compatible) con Firewall Manager para una directiva centralizada:

Configuration	Se utiliza cuando	Ventajas
Centro virtual estándar (sin firewall)	Solo conectividad de sucursal a VNet; la seguridad se administra a nivel de spoke	Implementación más sencilla, costo más bajo
Centro virtual protegido con Firewall Manager	Inspección centralizada del tráfico para el tráfico privado e Internet	Una política coherente y la intención de enrutamiento eliminan la necesidad de las UDR
Hub virtual seguro con socio de NVA	Inversión existente en cortafuegos de terceros, requisitos específicos de funcionalidades	Uso de herramientas y conocimientos del proveedor existentes

Intención de enrutamiento

La intención de enrutamiento simplifica el control de tráfico en Virtual WAN al dirigir automáticamente el tráfico a través de una solución de seguridad (Azure Firewall o NVA compatible) sin tablas de rutas personalizadas o UDR.

Al habilitar la intención de enrutamiento, declara directivas para dos tipos de tráfico:

• Tráfico de Internet: Todo el tráfico enlazado a Internet desde redes virtuales conectadas se enruta a través de la solución de seguridad del centro.
• Tráfico privado: Todo el tráfico entre redes virtuales, sucursales y otros concentradores se enruta a través de la solución de seguridad.

La intención de enrutamiento elimina la necesidad de gestionar manualmente las tablas de rutas. El plano de control de la Virtual WAN configura automáticamente todas las rutas necesarias en todos los hubs conectados y las redes virtuales spoke.

Note

La intención de enrutamiento requiere un centro virtual protegido con Azure Firewall o un asociado de NVA compatible. Solo está disponible en el nivel Estándar.

Advertencia

Las modificaciones de la tabla de rutas que introduce la intención de enrutamiento son irreversibles. Puede quitar la intención de enrutamiento, pero quitarla no restaura automáticamente la configuración de defaultRouteTable anterior. Guarde una instantánea de la configuración antes de habilitar la intención de enrutamiento, ya que debe restaurar manualmente las rutas anteriores si posteriormente la quita.

Límites de conexión y escalabilidad

Virtual WAN admite implementaciones a gran escala:

• Hasta 1000 conexiones VPN de sitio a sitio por centro virtual.
• Varios centros por Virtual WAN (uno por región o varios por región para el aislamiento).
• Hasta 50 Gbps de rendimiento agregado por enrutador de concentrador (requiere un máximo de 50 unidades de infraestructura de enrutamiento. El valor predeterminado es de 2 unidades a 3 Gbps).
• Conectividad cualquiera a cualquiera en todas las conexiones de VNet, sucursales VPN y circuitos de ExpressRoute dentro del mismo hub.

En el caso de las organizaciones que superan los límites de un único centro, implemente centros adicionales en las mismas regiones o diferentes. El Virtual WAN controla automáticamente el enrutamiento entre centros.

integración de asociados de SD-WAN

Virtual WAN proporciona integración nativa con dispositivos asociados de SD-WAN. Los dispositivos asociados pueden:

• Exporte la información del dispositivo de rama a Azure mediante programación.
• Descargue automáticamente la configuración de Azure.
• Establezca la conectividad IPsec/IKE con el centro virtual sin configuración manual.

Esta automatización reduce el tiempo de despliegue de ramas de días a minutos a gran escala. Para obtener la lista actual de asociados admitidos, consulte Virtual WAN asociados.

Cómo funciona la automatización de los socios

Los socios de SD-WAN usan la API de automatización de conectividad de Virtual WAN para gestionar mediante programación los ciclos de vida de los dispositivos de sucursal:

• Registro de dispositivos: El controlador de asociado registra dispositivos de rama con el recurso de Virtual WAN, incluidos los requisitos de ancho de banda y metadatos del dispositivo.
• Descarga de configuración: La plataforma del asociado extrae la configuración de la puerta de enlace del centro de conectividad (direcciones IP, claves previamente compartidas, configuración de BGP) sin interacción manual del portal.
• Establecimiento del túnel: El dispositivo asociado establece túneles IPsec en la puerta de enlace de VPN del centro de conectividad virtual mediante la configuración descargada.
• Supervisión continua del estado de funcionamiento: La plataforma asociada supervisa el estado de los túneles y puede restablecer la conexión si los túneles se caen.

Los partners como VMware SD-WAN, Fortinet SD-WAN, Cisco Viptela y Versa Networks admiten este modelo de automatización. Cada asociado implementa su propia capa de orquestación sobre la API de Virtual WAN. Evalúe las funcionalidades específicas del asociado, como el enrutamiento compatible con la aplicación, la optimización del tráfico y la interrupción local de Internet antes de seleccionar un asociado.

Consideraciones de diseño

En la mayoría de las migraciones de tipo lift-and-shift, la Virtual WAN no es la topología inicial. Evalúe cuándo se justifica:

• Cuando Virtual WAN se justifica. Si su entorno de lift-and-shift incluye más de 30 sucursales, abarca tres o más regiones de Azure o requiere integración con SD-WAN, el enrutamiento automatizado de la Virtual WAN reduce la sobrecarga operativa en comparación con la administración de UDR a través de numerosos emparejamientos de tipo hub-spoke.
• La arquitectura hub-spoke es suficiente para entornos más pequeños. Un único hub con VPN Gateway administra hasta 30 conexiones de sitio a sitio y 500 emparejamientos spoke. Si su migración se mantiene dentro de estos límites, la arquitectura hub-spoke tradicional es más sencilla y rentable.
• Hay una ruta de migración. Si comienza con una arquitectura hub-spoke y más adelante necesita Virtual WAN, puede migrar implementando un hub de Virtual WAN junto con su hub existente y trasladando de forma gradual las conexiones de los spokes.

Las implementaciones de varias regiones no requieren automáticamente Virtual WAN. Evalúe la complejidad del enrutamiento:

• A menudo basta con una arquitectura hub-spoke dual. Para arquitecturas activas-activas de dos regiones, implementa un concentrador en cada región con emparejamiento de VNet (VNet peering) entre los concentradores. Este patrón controla la mayoría de los escenarios de modernización sin la sobrecarga de precios por unidad de Virtual WAN.
• Cuando la complejidad se dirige hacia Virtual WAN. Si la modernización crece más allá de dos regiones, agrega conectividad de rama entre regiones o requiere propagación automática de rutas entre centros sin administración manual de UDR, Virtual WAN simplifica las operaciones.
• No confunda varias regiones con Virtual WAN. La decisión de usar Virtual WAN depende del número de ramas, el recuento de regiones y la complejidad del enrutamiento. La multirregión por sí sola no es justificación suficiente.

Virtual WAN proporciona el Azure equivalente de AWS Transit Gateway para tránsito centralizado y escalable:

• Equivalencia de Transit Gateway. El concentrador virtual de la Virtual WAN funciona como AWS Transit Gateway: enruta automáticamente el tráfico entre redes virtuales conectadas, sucursales y túneles VPN entre nubes. Si estás migrando desde AWS, esta correspondencia simplifica la adaptación de tu arquitectura.
• Centro virtual seguro (centro virtual protegido). Implemente Azure Firewall a través de Firewall Manager en el centro virtual. Habilita la intención de enrutamiento para dirigir todo el tráfico privado y de Internet a través del firewall. Esto proporciona una inspección centralizada para el tráfico entre nubes que entra en Azure.
• Conexiones VPN a Google Cloud y AWS. Cree conexiones VPN de sitio a sitio desde el concentrador de Virtual WAN a Google Cloud VPN (HA VPN) y a las puertas de enlace privadas virtuales de AWS. Virtual WAN admite hasta 1000 conexiones VPN por centro, lo que proporciona espacio para el crecimiento a medida que migra más cargas de trabajo.
• Planificación multiregión. Implemente centros virtuales en cada región de Azure donde llegan las aplicaciones migradas. El enrutamiento entre concentradores se propaga automáticamente a través de la red troncal de Microsoft, siguiendo el modelo de emparejamiento de Transit Gateway en AWS.

Prerequisites

Antes de implementar una topología de Virtual WAN:

• Comprende los conceptos de la topología hub-spoke. Virtual WAN se basa en el modelo hub-spoke. Revisa la topología hub-and-spoke para conocer los conceptos básicos.
• Haz un inventario de tus sucursales. Documente el número de ramas, su distribución geográfica y la conectividad actual (VPN, MPLS, SD-WAN).
• Defina la estrategia de la región. Determine qué Azure regiones hospedan cargas de trabajo y dónde necesita centros virtuales.
• Elija el nivel. Decida entre Básico (solo VPN de sitio a sitio) y Estándar (tránsito completo, ExpressRoute, firewall) en función de la tabla de comparación de niveles de este artículo.
• Evaluar los requisitos de seguridad. Determina si es más adecuado el control centralizado (Secured Virtual Hub) o la seguridad por cada spoke.

Consideraciones de seguridad

• Centro virtual protegido. Implemente Azure Firewall a través de Firewall Manager para aplicar directivas de seguridad coherentes en todas las redes virtuales y ramas conectadas. Firewall Manager proporciona administración centralizada de reglas en varios centros protegidos.
• Intención de enrutamiento. Habilite la intención de enrutamiento para dirigir automáticamente el tráfico privado y el tráfico de Internet a través de su solución de seguridad. Este enfoque impide que el tráfico pase la inspección mediante la eliminación de la configuración de enrutamiento manual.
• Limitaciones de NVA en el hub. Las aplicaciones virtuales de red implementadas en el centro tienen diferentes funcionalidades que Azure Firewall. Compruebe la paridad de características con los requisitos de seguridad antes de elegir un asociado de NVA.
• Modelo de seguridad de SD-WAN. Al integrar SD-WAN dispositivos asociados, la seguridad del tráfico depende de la implementación del asociado. Evalúe las funcionalidades de cifrado, autenticación y inspección del tráfico del asociado.
• Aislamiento del tráfico entre centros. El tráfico entre centros virtuales fluye a través de la red troncal de Microsoft y no atraviesa la red pública de Internet. La red troncal es una red privada, pero el tráfico no se cifra en la capa de red de forma predeterminada. Use TLS de capa de aplicación para datos confidenciales entre regiones.

Artículos relacionados

• Topología hub-and-spoke: si necesita un control total sobre los recursos del hub o tiene menos de 30 sucursales.
• Redes multirregionales: para patrones de hub de la Virtual WAN multirregional y diseño de conmutación por error regional.
• Conectividad entre regiones y multinube: tránsito global entre regiones y patrones de conectividad híbrida.
• VNet y subredes: Las VNet de los radios siguen conectándose a los hubs de la Virtual WAN a través de conexiones de VNet.
• Conectividad de ExpressRoute: configuración de puerta de enlace de ExpressRoute dentro de un centro virtual.
• Azure Firewall e inspección de tráfico: patrones de integración del firewall de Secured Virtual Hub.

Aprende más

• ¿Qué es Azure Virtual WAN?
• Introducción al enrutamiento de Virtual WAN
• Intención de enrutamiento y políticas de enrutamiento
• Centro virtual protegido de Azure Firewall Manager
• Conceptos de precios de Virtual WAN
• Virtual WAN asociados y ubicaciones

Pasos siguientes

Sugerencia

¿Explorando por su cuenta? Vuelva al navegador de información general para encontrar el siguiente artículo por funcionalidad.

A continuación, en el itinerario de lift-and-shift:

Conectividad híbrida: vuelva a conectar las cargas de trabajo migradas al entorno local a través de VPN Gateway o ExpressRoute.

A continuación en su proceso de modernización:

Planifica tu implementación multirregional: Amplía tu diseño a varias regiones para lograr una resiliencia activa-activa.

A continuación, en el itinerario entre nubes:

Diseña las VNet de tu zona de aterrizaje de Azure: Crea la base de la VNet de Azure para tus cargas de trabajo conectadas y migradas.