Ruta de diseño de redes entre nubes

En esta guía se proporciona una ruta de lectura secuenciada a través de la Guía de diseño de redes de Azure para los clientes que conectan Azure a Amazon Web Services (AWS), Google Cloud o migrando cargas de trabajo desde otro proveedor de nube. Siga los pasos numerados para diseñar la conectividad segura y supervisada entre Azure y la infraestructura en la nube existente.

¿Por qué la detección viene primero?

La conectividad entre nubes conecta Azure con uno o varios entornos de nube externos. Es posible que ejecute cargas de trabajo en AWS o Google Cloud que necesiten conectividad privada con Azure servicios, o bien puede migrar aplicaciones de otra nube a Azure a la vez que mantiene la conectividad con las aplicaciones que permanecen detrás. En cualquier caso, su red de Azure debe integrarse con infraestructura que no controla por completo en el otro extremo.

Esta ruta de aprendizaje comienza con el descubrimiento en lugar del diseño de infraestructura de Azure. Primero, hay que trazar la topología multinube existente (entender qué se ejecuta en cada entorno, cómo se conecta y qué tráfico fluye entre nubes) antes de diseñar la parte de Azure. Este enfoque basado primero en el descubrimiento evita rehacer trabajo: si diseña las redes de Azure sin comprender la topología de AWS o de Google Cloud, corre el riesgo de sufrir conflictos de direcciones IP, lagunas de conectividad y puntos ciegos de seguridad.

La arquitectura de destino usa Azure Virtual Wide Area Network (WAN) como concentrador de tránsito (el Azure equivalente de AWS Transit Gateway) con túneles VPN IPSec a AWS Virtual Private Gateway y VPN de Google Cloud. Azure Firewall en un centro virtual seguro inspecciona todo el tráfico entre nubes y ramas. El DNS requiere una planificación minuciosa de la transición para garantizar que la resolución de nombres siga funcionando más allá de los límites de la nube durante la migración.

Prerequisites

  • Lea la información general de diseño y el plan de redes de Azure para obtener orientación sobre los servicios de red de Azure disponibles.
  • Detección completa de topologías de los entornos de AWS y Google Cloud:
    • AWS: Ejecuta AWS Migration Hub o Workload Discovery en AWS para realizar un inventario de las nubes privadas virtuales (VPC), las puertas de enlace de tránsito y la conectividad entre VPC.
    • Google Cloud: Utiliza el Network Intelligence Center para mapear redes VPC, conexiones de Cloud Interconnect y reglas de firewall.
  • Documente los flujos de tráfico entre distintas nubes: qué aplicaciones se comunican entre distintas nubes, el ancho de banda necesario, la sensibilidad a la latencia y los requisitos de cifrado.
  • Cree un inventario de intervalos de direcciones IP en las tres nubes para identificar superposiciones.

Ruta de lectura

Las siguientes fases le guían a través del diseño de red entre nubes en secuencia.

Fase 1: Detección

Comience con la detección. Comprenda el entorno multinube antes de diseñar Azure infraestructura.

1. Conectividad entre regiones y multinube

Este artículo es el punto de decisión de diseño central. Asigne la topología multinube: qué VPN de AWS y VPC de Google Cloud necesitan conectividad para Azure, qué tráfico fluye entre nubes y qué patrón de arquitectura se ajusta a su escala. Utilice la correspondencia entre servicios de los distintos proveedores de nube (de Transit Gateway a Virtual WAN, de Security Groups a Network Security Groups, de VPC Peering a VNet peering) para trasladar su diseño actual a la terminología de Azure.

2. Azure Virtual WAN

Virtual WAN es el modelo de tránsito recomendado cuando hay varias VPC, sucursales, regiones o periferias de la nube. Virtual WAN proporciona el equivalente en Azure de AWS Transit Gateway: enrutamiento automático, seguridad centralizada y escalabilidad para múltiples sucursales y múltiples regiones. Evalúa si tu entorno multicloud justifica el uso de una WAN virtual o si basta con una arquitectura hub-and-spoke más sencilla con una VPN Gateway.

Fase 2: Fundamentos

3. Redes virtuales y subredes

Diseñe la red virtual Azure como zona de aterrizaje para cargas de trabajo migradas o conectadas. Realiza la correspondencia a partir de los conceptos de VPC de AWS y Google Cloud: las subredes VPC se convierten en subredes de Azure, las zonas de disponibilidad se corresponden con las zonas de disponibilidad de Azure y las tablas de enrutamiento siguen patrones similares. Céntrese en el ajuste de tamaño de subred para las cargas de trabajo que llegan a Azure.

4. Planificación de direcciones IP

Planifica un espacio de direcciones que no se solape en las tres nubes. Este paso es fundamental para la conectividad entre nubes: si los intervalos de red virtual de Azure se superponen con intervalos de AWS VPC o intervalos de VPC de Google Cloud, no puede establecer túneles VPN entre ellos. Documente cada bloque CIDR en uso en todos los entornos antes de asignar el espacio de direcciones de Azure.

5. Grupos de seguridad de red y grupos de seguridad de aplicaciones

Replica tus grupos de seguridad de AWS y las reglas de firewall de Google Cloud como grupos de seguridad de red (NSG) de Azure. Traduzca las reglas de permiso y denegación existentes en formato de NSG. Use grupos de seguridad de aplicaciones (ASG) para replicar la agrupación basada en etiquetas que proporcionan las referencias del grupo de seguridad de AWS.

Fase 3: Conectividad

6. Conectividad híbrida

Configure túneles VPN IPSec entre Azure y AWS o Google Cloud para el tránsito cifrado entre nubes. Conecte Azure VPN Gateway (o conexiones VPN de Virtual WAN) a AWS Virtual Private Gateway y Google Cloud VPN. Elija el ancho de banda del túnel en función de sus necesidades de tráfico entre nubes. Planee túneles redundantes para evitar puntos únicos de error.

Fase 4: Seguridad

7. Seguridad DNS y resolución de nombres privados

Planifique la estrategia de cambio de DNS antes de migrar las cargas de trabajo. Las aplicaciones en AWS o Google Cloud resuelven nombres de host que podrían tener que apuntar a Azure tras la migración. Configura Azure DNS Private Resolver con puntos de conexión salientes para la resolución de nombres entre nubes. Consulte la lista de comprobación de migración de DNS más adelante en este artículo para obtener instrucciones de migración paso a paso.

8. Azure Firewall

Implemente Azure Firewall en un centro virtual seguro para inspeccionar todo el tráfico entre nubes y ramas. Cada paquete que atraviesa entre Azure y AWS o Google Cloud pasa por el firewall para el registro y la aplicación de directivas. Use reglas de red para patrones de tráfico entre nubes y filtrado de inteligencia sobre amenazas para bloquear destinos malintencionados conocidos.

Fase 5: Operaciones

9. Supervisión de red y observabilidad

Los entornos multinube son más difíciles de diagnosticar y resolver porque no controlas los dos extremos de cada conexión. Habilite Azure Network Watcher para pruebas de conectividad, diagnósticos de túnel VPN y captura de paquetes. Supervise el tiempo de actividad del túnel, la latencia entre nubes y el rendimiento con respecto a los requisitos de capacidad. Establezca alertas para las desconexiones de túnel que afectan a la disponibilidad de aplicaciones entre nubes.

Artículos condicionales

Incluya estos artículos en función de sus requisitos específicos:

Condition Artículo Cuándo incluir
Aplicación orientada al público Entrada de Internet La aplicación migrada está orientada a Internet (se requiere acceso público directo)
Aplicación HTTP/HTTPS Firewall de aplicaciones web Waf de nivel 7 es necesario para aplicaciones web orientadas al público
Se necesita una distribución de nivel 7 Entrega y rendimiento de aplicaciones Necesita distribución de tráfico global o regional después de la migración.
Puntos de conexión públicos Protección contra DDoS Tiene requisitos de tiempo de actividad para los servicios orientados al público
Se prefiere la arquitectura hub-and-spoke Topología de red en estrella tipo hub-and-spoke Su entorno multinube es lo bastante pequeño como para que Virtual WAN no se justifique
Azure de varias regiones Redes de varias regiones El destino de Azure abarca varias regiones más allá de la conectividad entre nubes
Acceso de administrador de máquina virtual Acceso de desarrollador y administrador Necesita acceso SEGURO a RDP/SSH para máquinas virtuales hospedadas Azure
Salida centralizada Acceso saliente a Internet La directiva centralizada de salida de Internet forma parte de su diseño objetivo
Gran parque de VNet Administración de red centralizada La parte de Azure evoluciona hasta convertirse en un entorno gobernado con varias suscripciones
Puntos de conexión privados de PaaS Acceso privado de PaaS La arquitectura de destino incluye Azure servicios PaaS con puntos de conexión privados

Lista de comprobación para la detección entre nubes

Antes de diseñar las redes de Azure, asigne sus servicios en la nube actuales a sus equivalentes en Azure. Esta correspondencia agiliza la toma de decisiones de diseño y evita expectativas desalineadas.

Asignación de servicios de AWS a Azure

Servicio de AWS Equivalente de Azure Notes
Puerta de enlace de tránsito Azure Virtual WAN Centro de enrutamiento centralizado para entornos con múltiples VPC, múltiples regiones y múltiples nubes
VPC Red virtual de Azure Límite de red aislado con subredes y tablas de rutas
Emparejamiento de VPC Emparejamiento de VNet Conectividad directa entre dos redes virtuales
Grupos de seguridad Grupos de seguridad de red (NSG) Filtrado de tráfico con estado en el nivel de subred o interfaz de red
ACL de red NSG (nivel de subred) Los grupos de seguridad de red de Azure combinan las funciones de grupo de seguridad y de NACL
Puerta de enlace privada virtual VPN Gateway Punto de terminación de VPN IPSec
Conexión directa Azure ExpressRoute Conectividad privada dedicada (no a través de La red pública de Internet)
Zonas hospedadas privadas de Route 53 Zonas DNS privadas de Azure Resolución de nombres DNS privados dentro de redes virtuales
Tablas de ruta Rutas definidas por el usuario (UDR) Enrutamiento personalizado para invalidar rutas del sistema de Azure o rutas implícitas de AWS
Elastic Load Balancer (ALB/NLB) Azure Load Balancer/Application Gateway Equilibrado de carga L4 y L7; Application Gateway proporciona capacidades de WAF similares a las de AWS ALB con AWS WAF
AWS WAF Firewall de aplicaciones web de Azure Protección HTTP/HTTPS de capa 7
Firewall de red Azure Firewall Cortafuegos de red con estado y con inteligencia sobre amenazas

Asignación de servicios de Google Cloud a Azure

Servicio de Google Cloud Equivalente de Azure Notes
Red de VPC Red virtual de Azure Un recurso global en Google Cloud; regional en Azure (use VNet peering para la conectividad entre regiones)
Interconexión en la nube Azure ExpressRoute Conectividad privada dedicada
VPN en la nube VPN Gateway Túneles VPN de IPSec
NAT en la nube Puerta de enlace NAT de Azure Acceso saliente a Internet para recursos privados
Enrutador en la nube Servidor de rutas de Azure Intercambio dinámico de rutas BGP con aplicaciones virtuales de red
Protección de la nube Firewall de aplicaciones web de Azure Protección contra DDoS y aplicaciones de nivel 7
Reglas de firewall Grupos de seguridad de red Filtrado de tráfico (las reglas de Google Cloud son globales; Azure NSG son por subred o por NIC)
Zonas privadas dns en la nube Zonas DNS privadas de Azure Resolución de nombres privados dentro de las redes
Centro de inteligencia de red Azure Network Watcher Supervisión de red, diagnósticos y visualización de topología

Lista de comprobación para el cambio de DNS

El cambio de DNS es el paso de mayor riesgo en una migración entre nubes. Siga esta lista de comprobación para minimizar los errores de resolución durante la transición.

Antes de la migración

  1. Reducir los valores de tiempo de vida (TTL) en todos los registros DNS que cambian. Establezca el TTL entre 60 y 300 segundos al menos 48 horas antes de la transición. Este paso garantiza que las memorias caché expiren rápidamente cuando se actualizan los registros.
  2. Documente cada registro DNS que apunte a la infraestructura que va a migrar: registros para servidores, registros CNAME para servicios, registros MX para correo y registros SRV para la detección de servicios.
  3. Configure Azure DNS Private Resolver con puntos de conexión salientes en su VNet de Azure. Este solucionador reenvía las consultas de las zonas hospedadas en AWS/Google Cloud a los servidores DNS ascendentes adecuados durante el período de coexistencia.
  4. Compruebe la resolución directa e inversa entre las redes virtuales de Azure y los nombres alojados en AWS/Google Cloud antes de migrar cualquier carga de trabajo.

Durante la migración

  1. Actualice los registros CNAME de los servicios que se mueven a Azure. Dirija los registros CNAME a los puntos de conexión de Azure Front Door, Azure Traffic Manager o Azure Application Gateway a medida que se migre cada servicio.
  2. Actualice los registros A del host para servidores individuales que migran. Sustituya las direcciones IP de AWS o Google Cloud por direcciones IP privadas de Azure en sus zonas DNS.
  3. Mantenga activo el reenvío condicional para que los nombres de las zonas que aún no haya migrado sigan resolviéndose a través de los servidores DNS de la nube original.

Después de la migración

  1. Compruebe la resolución de todas las ubicaciones: los clientes locales, las redes virtuales Azure y las cargas de trabajo de AWS o Google Cloud restantes deben resolver los nombres migrados correctamente.
  2. Vuelva a elevar los valores de TTL a los niveles de producción (3600 segundos o superior) después de confirmar la resolución estable.
  3. Quite los reenviadores condicionales de las zonas que se migran completamente a Azure DNS. Mantenga los reenviadores solo para las zonas que permanecen en AWS o Google Cloud.

Lo que ha creado

Siguiendo esta ruta de lectura, ha conectado Azure a su entorno de AWS o Google Cloud existente con tránsito cifrado, inspección centralizada del firewall y conectividad supervisada. El diseño incluye:

  • Detección de topologías multinube y asignación de servicios
  • WAN virtual o arquitectura de tránsito hub-and-spoke
  • Túneles VPN IPSec a AWS y Google Cloud
  • Azure Firewall para la inspección del tráfico entre nubes
  • Cambio de DNS con el resolutor privado para la resolución de nombres entre nubes
  • Supervisión del estado y del rendimiento del túnel con Network Watcher

Pasos siguientes

  • Last updated on