Conectividad entre regiones y multinube

Este artículo le ayuda a conectar Azure cargas de trabajo en varias regiones y ampliar la conectividad a otros proveedores de nube, como Amazon Web Services (AWS) y Google Cloud.

Lo que trata este artículo

En este artículo se abordan las decisiones de diseño para conectar redes virtuales de Azure (VNets) entre regiones y establecer rutas de red hacia cargas de trabajo que se ejecutan en otras nubes. Aprenderá cuándo usar el emparejamiento global de redes virtuales, Virtual WAN, ExpressRoute Global Reach, VPN de sitio a sitio y Azure Route Server para escenarios entre regiones y multinube.

Quién necesita este artículo

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

  • La arquitectura abarca varias regiones de Azure y necesita conectividad privada entre ellas.
  • Debe conectar las cargas de trabajo de Azure a AWS, Google Cloud u otra red externa.
  • Debe comparar Global VNet Peering, Virtual WAN, ExpressRoute Global Reach, VPN de sitio a sitio o Azure Route Server.
  • Debe diseñar conectividad resistente para la recuperación ante desastres, la expansión global o las operaciones multinube.

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: Incluye este artículo en tu ruta de lectura solo si tu migración abarca varias regiones de Azure o se conecta a otra nube. La mayoría de los proyectos de lift-and-shift comienzan con una sola región y agregan conectividad entre regiones más adelante cuando la recuperación ante desastres o la expansión geográfica se convierten en una prioridad.

Enfoque de modernización: Incluya este artículo si la modernización requiere conectividad privada entre regiones explícita más allá de lo que trata el artículo de varias regiones . Necesitará esta guía cuando los spokes de diferentes regiones requieran rutas de comunicación directas o cuando su implementación activa-activa necesite un peering privado entre hubs regionales.

Enfoque multinube: Este artículo le servirá como referencia central para tomar decisiones de diseño. Léelo antes de elegir entre hub-spoke y Virtual WAN para la arquitectura de tránsito entre nubes. Use este artículo para detectar la topología multinube existente, asignar servicios entre AWS o Google Cloud y Azure, y definir cómo se conecta Azure a las cargas de trabajo que permanecen en otras nubes durante la migración.

servicios y características de Azure

Azure proporciona varios servicios para la conectividad entre regiones y multinube. Cada servicio aborda diferentes requisitos de escala, ancho de banda y administración.

Servicio Qué proporciona Cuándo usarlo
Emparejamiento de VNet global Conectividad privada de baja latencia entre redes virtuales en diferentes regiones de Azure. El tráfico permanece en la red troncal de Microsoft. El ancho de banda solo está limitado por la SKU de la máquina virtual (VM), no por una puerta de enlace. Comunicación directa entre dos VNet de diferentes regiones sin un dispositivo de puerta de enlace.
Azure Virtual WAN (nivel Estándar) Hub de tránsito global administrado por Microsoft que conecta VNet, sucursales y usuarios remotos en todas las regiones. Proporciona enrutamiento transitivo entre todas las redes conectadas. Organizaciones con numerosas regiones y sucursales que necesitan conectividad cualquiera a cualquiera sin tener que administrar conexiones de emparejamiento individuales.
ExpressRoute a través de Cloud Exchange Conexión entre nubes dedicada a través de un proveedor de intercambio de terceros (como Equinix o Megaport). Proporciona conectividad privada y de alto ancho de banda a AWS o Google Cloud. Arquitecturas multinube con requisitos de Acuerdo de Nivel de Servicio de ancho de banda en los que el tráfico no debe atravesar la red pública de Internet.
VPN de sitio a sitio a otras nubes Túnel IPsec cifrado entre Azure VPN Gateway y la puerta de enlace de VPN de otro proveedor de nube (AWS Virtual Private Gateway o Google Cloud VPN). Conectividad multinube para escenarios de prueba, desarrollo o producción en los que los circuitos dedicados no están justificados.
Azure Route Server Habilita el intercambio dinámico de rutas BGP entre la red virtual y las aplicaciones virtuales de red (NVA). Inserta rutas aprendidas por NVA en el tejido de enrutamiento de SDN de Azure. Enrutamiento personalizado mediante NVA de terceros en una red virtual de tipo concentrador, o enrutamiento multinube complejo que requiere propagación de BGP a las redes conectadas a Azure.

Cómo funciona el emparejamiento global de redes virtuales (VNet)

Global VNet Peering establece un vínculo directo entre dos redes virtuales en distintas regiones de Azure. El vínculo se ejecuta por completo a través de la red troncal de Microsoft y nunca atraviesa la red pública de Internet. Después de configurar una relación de emparejamiento, los recursos de cada red virtual pueden comunicarse mediante direcciones IP privadas como si estuvieran en la misma red.

A diferencia de los enfoques basados en puertas de enlace, el emparejamiento no introduce ningún punto de estrangulamiento. El ancho de banda entre VNet emparejadas se adapta a la SKU de la máquina virtual de cada lado. No hay ningún dispositivo de puerta de enlace dedicado que limite el rendimiento. Este diseño hace que el emparejamiento global de redes virtuales sea la opción de menor latencia para la comunicación entre regiones entre un número reducido de redes virtuales.

Sin embargo, el emparejamiento es no transitivo por diseño. Si la red virtual A es del mismo nivel con la red virtual B y la red virtual B del mismo nivel con la red virtual C, el tráfico de la red virtual A no puede acceder a la red virtual C a través de la red virtual B. Cada par de redes virtuales que necesitan comunicación directa requiere su propio vínculo de emparejamiento. En un modelo hub-spoke, esto significa que, por lo general, se establece el peering entre las VNet de los hubs regionales y se utilizan rutas definidas por el usuario (UDR) o NVA para reenviar el tráfico de spoke a spoke entre regiones a través de los hubs.

Tránsito global de la Virtual WAN

Azure Virtual WAN (nivel Estándar) elimina la necesidad de configurar manualmente el emparejamiento entre centros regionales. Al implementar centros de Virtual WAN en varias regiones, Microsoft establece automáticamente conexiones de concentrador a concentrador a través de la red troncal. Las rutas aprendidas en un hub se propagan a todos los demás hubs, creando una estructura de tránsito cualquiera a cualquiera.

Este enrutamiento automático significa que una red virtual radial conectada a un centro de conectividad del Este de EE. UU. puede llegar a una red virtual radial conectada a un centro de conectividad en Oeste de Europa sin ninguna configuración adicional de emparejamiento o tabla de rutas. Virtual WAN extiende también esta transitividad a las sucursales (conectadas a través de VPN de sitio a sitio o ExpressRoute) y usuarios remotos (conectados a través de VPN de punto a sitio). El resultado es una red global de malla completa administrada por Microsoft.

Para la inspección del tráfico entre regiones, habilite Routing Intent en hubs virtuales seguros. Routing Intent fuerza el tráfico entre concentradores a través de Azure Firewall, lo que le proporciona visibilidad centralizada y aplicación de políticas en todas las regiones sin tener que implementar y administrar instancias de NVA individuales en cada concentrador.

Cómo elegir

Use las siguientes tablas de decisión para seleccionar el enfoque de conectividad adecuado para su escenario.

Opciones de conectividad entre regiones

Diagrama que muestra patrones de conectividad entre regiones, incluidos Global VNet Peering, el tránsito de concentrador a concentrador de Virtual WAN y las rutas de VPN multinube.

Su escenario Enfoque recomendado Por qué
Dos VNets de distintas regiones necesitan comunicación directa Emparejamiento de VNet global Menor latencia en comparación con las rutas de Internet, sin cuellos de botella en la puerta de enlace, fácil de configurar. El ancho de banda depende de la SKU de la máquina virtual.
Muchas regiones, muchas sucursales: se necesita tránsito administrado Azure Virtual WAN (nivel Estándar) Proporciona enrutamiento transitivo de cualquiera a cualquiera en todos los hubs conectados. Microsoft administra la infraestructura de enrutamiento.
Conectar sitios locales entre sí a través de Azure ExpressRoute Global Reach Vincula dos circuitos ExpressRoute para que el tráfico local recorra la red troncal de Microsoft. No es necesario realizar un hairpin a través de las VNet de Azure.
Enrutamiento personalizado o NVA de terceros en un centro regional Azure Route Server Habilita el emparejamiento BGP dinámico entre NVA y Azure. Las rutas aprendidas por el NVA se inyectan automáticamente en las VNet de los spokes.

Opciones de conectividad multinube

Tu escenario Enfoque recomendado Por qué
Ancho de banda alto y Acuerdo de Nivel de Servicio necesarios para el tráfico entre nubes ExpressRoute a través del proveedor de cloud Exchange Proporciona capacidad dedicada con latencia predecible. El proveedor de exchange conecta el circuito ExpressRoute al servicio de conexión directa de la otra nube.
Cargas de trabajo con limitaciones presupuestarias, pruebas o bajo rendimiento VPN de sitio a sitio Usa la conectividad a Internet existente sin costos de circuito. Adecuado cuando los requisitos de ancho de banda son modestos.
Híbrido más multinube (local, Azure y otra nube) ExpressRoute Global Reach + Cloud Exchange Combina Global Reach para el tránsito local a Azure con un intercambio en la nube para la conectividad de Azure a otra nube, creando una red troncal privada unificada.

Consideraciones de diseño

Para la mayoría de las migraciones de tipo lift-and-shift, la conectividad entre regiones se considera una ampliación futura en lugar de un requisito desde el primer día. Es probable que la implementación inicial tenga como destino una sola región de Azure.

Cuando planee la expansión futura:

  • Emparejamiento global de VNet: Utilice el emparejamiento global de VNet entre las VNet de los hubs regionales cuando añada una segunda región de Azure. Este enfoque proporciona conectividad privada de baja latencia sin implementar un dispositivo de puerta de enlace. El tráfico permanece en la red troncal de Microsoft y escala en función de la SKU de la máquina virtual.
  • Complejidad diferida: Evite desplegar Virtual WAN o ExpressRoute Global Reach hasta que su entorno crezca más allá de dos regiones o añada necesidades de conectividad con sucursales.
  • Preparación de recuperación ante desastres: Incluso si la conectividad entre regiones no es necesaria actualmente, documente qué cargas de trabajo requieren recuperación ante desastres y planee previamente la topología de emparejamiento para que pueda implementarla rápidamente cuando sea necesario.

Su arquitectura modernizada utiliza implementaciones activo-activo entre regiones. El emparejamiento entre regiones permite la comunicación directa de spoke a spoke cuando los niveles de su aplicación traspasan los límites regionales.

Decisiones clave de diseño para la modernización:

  • Emparejamiento entre regiones para el modo activo-activo: Empareja las redes VNet de los centros de las regiones principal y de respaldo para habilitar el flujo de tráfico bidireccional. Los equipos de aplicaciones de los radios ContosoBiz y ContosoCare pueden acceder a los recursos de cualquiera de las dos regiones a través de la ruta de emparejamiento del centro.
  • Enrutamiento a través de hubs: Dado que el emparejamiento global de VNet no es transitivo, enrute el tráfico de los spokes entre regiones a través de la NVA del hub regional o de Azure Firewall. Utilice rutas definidas por el usuario (UDR) para dirigir el tráfico entre spokes de distintas regiones a través del firewall del hub para su inspección.
  • Emparejamiento selectivo: No todos los spokes necesitan conectividad entre regiones. Empareje únicamente las VNet del hub y utilice la propagación de rutas para llegar a VNet específicas de los spokes que participen en cargas de trabajo activas-activas.

En este artículo se diseña la arquitectura de conectividad multinube. Antes de planificar la infraestructura de Azure, debes identificar tu topología de nube actual y correlacionar los servicios entre proveedores.

Flujo de trabajo de detección multinube

  1. Descubra su topología actual: Use Workload Discovery en AWS y Google Cloud Network Intelligence Center para trazar la topología actual de su nube privada virtual (VPC), las relaciones de interconexión y los patrones de flujo de tráfico.
  2. Identifique los flujos de tráfico: Documenta la comunicación de VPC a VPC, las rutas de entrada desde internet y de salida a internet, y las conexiones entre sucursales y la nube en tu entorno de AWS o Google Cloud.
  3. Asigne los servicios a sus equivalentes de Azure: Las correspondencias clave para el diseño de conectividad son:
AWS/Servicio en la nube de Google Equivalente de Azure
Puerta de enlace de tránsito Azure Virtual WAN
VPC / Red VPC Red virtual de Azure
Grupos de seguridad o reglas de firewall Grupos de seguridad de red (NSG)

Para obtener una correspondencia completa de servicios de AWS a Azure y de Google Cloud a Azure, consulta la lista de comprobación de detección entre nubes.

Decisiones sobre la arquitectura de conectividad

Después de completar el descubrimiento y el mapeo de servicios, decida:

  • Modelo de tránsito: Elija Virtual WAN si tiene varias VPC, ramas, regiones o bordes en la nube. Virtual WAN proporciona el equivalente en Azure de AWS Transit Gateway con enrutamiento administrado de cualquier origen a cualquier destino.
  • VPN entre nubes: Implementa conexiones de VPN Gateway desde tu concentrador de Virtual WAN (o red VNet del concentrador) a la puerta de enlace privada virtual de AWS y a la VPN de Google Cloud. Use túneles IPsec para la comunicación cifrada entre nubes.
  • Aplicaciones que permanecen: Identifique las cargas de trabajo que permanecen en AWS o Google Cloud durante la migración. Estas cargas de trabajo necesitan conectividad persistente a través de los túneles VPN entre nubes hasta que se complete la migración.

Prerequisites

Antes de implementar la conectividad entre regiones o multinube, confirme los siguientes requisitos:

  • Dos o más regiones de Azure con VNets implementadas: Sus cargas de trabajo ya deben existir (o estar previstas) en varias regiones. Consulte el artículo Redes virtuales y subredes para obtener instrucciones de planeación de redes virtuales.
  • Topología de tipo hub-and-spoke o Virtual WAN: Los diseños multirregión se basan en una topología establecida en cada región. Consulte el artículo sobre la arquitectura hub-spoke o el artículo sobre Virtual WAN.
  • Circuitos ExpressRoute (para Global Reach): Si tiene previsto conectar sitios locales, necesita circuitos ExpressRoute existentes en cada ubicación. Consulte el artículo conectividad híbrida.
  • Acceso a cuentas entre nubes: Para la conectividad VPN multicloud o de intercambio, necesita acceso administrativo a la consola de redes del otro proveedor de servicios en la nube para configurar el extremo remoto de la conexión.

Consideraciones de seguridad

La conectividad entre regiones y multinube presenta problemas de seguridad específicos que no existen en las implementaciones de una sola región.

Inspección del tráfico entre regiones

El emparejamiento global de VNet (Global VNet Peering) no es transitivo. El tráfico entre redes virtuales emparejadas fluye directamente sin pasar por un firewall o un punto de inspección. Si necesita inspeccionar el tráfico entre regiones, enrutelo a través de una aplicación virtual de red (NVA) o Azure Firewall en cada centro regional.

Para Virtual WAN, habilite intención de enrutamiento con directivas de tráfico privado en los hubs virtuales protegidos. Routing Intent obliga al tráfico entre centros a pasar por firewalls administrados por Azure Firewall Manager, lo que proporciona una inspección centralizada del tráfico entre regiones. Esta configuración requiere el nivel estándar de Virtual WAN.

Cifrado de conexiones entre nubes

Los túneles VPN de sitio a sitio a otras nubes se cifran de forma predeterminada (IPsec/IKE). Sin embargo, las conexiones de ExpressRoute a través de un intercambio en la nube son privadas pero no cifradas en el nivel de red. Si necesita cifrado a través de ExpressRoute, implemente MACsec en circuitos directos de ExpressRoute o use el cifrado TLS de capa de aplicación.

Para el tráfico entre nubes que atraviesa un intercambio en la nube sin superposición de VPN, considere la posibilidad de implementar un túnel IPsec basado en NVA dentro de la ruta de acceso de ExpressRoute. Este enfoque agrega cifrado sin renunciar al ancho de banda y a las ventajas de latencia de un circuito dedicado. Como alternativa, use TLS mutua (mTLS) en el nivel de aplicación para que cada punto de conexión de servicio valide la identidad y cifre los datos independientemente del transporte subyacente. La elección depende de si necesita cifrado de nivel de red (todo el tráfico) o puede aplicar el cifrado en el nivel de aplicación.

Consideraciones sobre los costos

Toda la conectividad entre regiones incurre en cargos de transferencia de datos. Tanto el emparejamiento global de VNet (Global VNet Peering) como el tráfico entre hubs de la Virtual WAN y los túneles interregionales de la VPN Gateway utilizan una tarificación basada en el tráfico de salida. Las tarifas varían según el par de zonas:

  • Intra-continental (por ejemplo, Este de EE. UU. a Oeste de EE. UU.): tasa inferior por GB, normalmente en el intervalo de precios de salida estándar para la región.
  • Intercontinental (por ejemplo, del Este de EE. UU. a Europa Occidental): mayor tarifa por GB debido a las mayores distancias de la red troncal y a la capacidad intercontinental.

Virtual WAN agrega un cargo por unidad de conexión para cada red virtual spoke o sucursal conectada a un hub, además de un cargo por procesamiento de datos para el tráfico que transita a través de un hub protegido en el que se ejecuta Azure Firewall. Esta estructura de precios por capas implica que la Virtual WAN puede resultar más cara que el simple emparejamiento global de VNet en arquitecturas con pocas regiones y pocos radios, pero ofrece una mejor rentabilidad unitaria a gran escala cuando se conectan docenas de sucursales y regiones.

Para la conectividad multicloud, ExpressRoute a través de un punto de intercambio en la nube conlleva cargos por puerto y tarifas de conexión cruzada del proveedor del punto de intercambio, además de los cargos por circuito de Azure ExpressRoute y los cargos por conexión directa de la otra nube. La VPN de sitio a sitio evita los costes del circuito, pero sigue incurriendo en cargos estándar de salida por los datos que salen de Azure.

Guía: Coloque cargas de trabajo de alto tráfico en la misma región siempre que sea posible. Reserva rutas interregionales para la sincronización del plano de control, la replicación asíncrona y la conmutación por error en la recuperación ante desastres, que suelen ser flujos de menor volumen.

Patrones de recuperación ante desastres

La conectividad entre regiones es fundamental para la recuperación ante desastres (DR). El patrón que elija determina el objetivo de tiempo de recuperación (RTO) y el objetivo de punto de recuperación (RPO).

Active-active

Ambas regiones sirven simultáneamente al tráfico de producción. Un equilibrador de carga global (como Azure Front Door o Azure Traffic Manager) distribuye las solicitudes entre regiones. Si una región falla, el tráfico se redirige a la región que sigue operativa con una interrupción mínima. Este patrón ofrece el RTO más bajo (segundos a minutos), pero requiere una infraestructura completa en las regiones y la sincronización de datos bidireccionales, lo que aumenta el costo y la complejidad.

Active-passive

Una región gestiona el tráfico de producción, mientras que la segunda región permanece en reserva con infraestructura preaprovisionada (aunque con capacidad potencialmente reducida). La replicación mantiene actualizados los datos de la región pasiva. En caso de fallo, se promueve la región pasiva y se redirige el tráfico. El RTO depende de la rapidez con la que se amplíen los recursos pasivos y se complete la conmutación por error del DNS o del Load Balancer, lo que suele llevar entre unos minutos y varias decenas de minutos.

Luz piloto

Presencia mínima en la región secundaria (bases de datos en replicación, infraestructura de red principal desplegada) sin capacidad de cómputo activa. En caso de conmutación por error, se implementa o amplía la capacidad de proceso de la aplicación y se redirige el tráfico. Este patrón minimiza el coste en estado estable, pero aumenta el RTO porque los recursos de computación deben iniciarse antes de que la región pueda atender el tráfico.

En todos los patrones, la conectividad entre regiones (emparejamiento global de redes virtuales o Virtual WAN entre centros de conectividad) proporciona la ruta de datos privada para el tráfico de replicación. Asegúrese de que sus guías de recuperación ante desastres tengan en cuenta cualquier retraso en la propagación de rutas y compruebe que las reglas del grupo de seguridad de red (NSG) en la región secundaria permitan el tráfico de conmutación por error.

Restricciones de clave

Restricción Impacto
El emparejamiento global de VNet no es transitivo Que VNet A esté emparejada con VNet B y que VNet B esté emparejada con VNet C no significa que A pueda comunicarse con C. Debe emparejar A con C directamente o usar una solución de tránsito como Virtual WAN.
Virtual WAN nivel Básico carece de transitividad La WAN virtual básica no admite la conectividad transitiva de VNet a VNet. Use el nivel Estándar para el tránsito entre regiones.
ExpressRoute Global Reach requiere la SKU Premium para conexiones entre áreas geopolíticas Los circuitos de diferentes regiones geopolíticas (por ejemplo, EE. UU. y Europa) requieren el complemento Premium. Los circuitos de SKU estándar solo se pueden conectar dentro del mismo límite geopolítico.
VPN Gateway de tipo activo-activo recomendado para AWS AWS Virtual Private Gateway crea dos túneles por conexión VPN. Configure Azure VPN Gateway en modo activo-activo para usar todos los túneles disponibles y evitar el enrutamiento asimétrico.

Aprende más

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:

Redes multirregionales: Planifica la conectividad multirregional y la conmutación por error si tu migración se extiende más allá de una región.

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

Supervisión y observabilidad de la red: Habilita la observabilidad entre regiones para garantizar la preparación para la producción.

A continuación, en el itinerario entre nubes:

Topología de Virtual WAN: Use Virtual WAN como concentrador de tránsito para su conectividad multinube y multisucursal.

  • Last updated on