Topología de red plana de carga de trabajo única

Una red plana es la topología de red más sencilla Azure: una red virtual con varias subredes que hospedan una sola carga de trabajo. En este artículo se explica cuándo usar este patrón y cómo implementarlo.

Lo que trata este artículo

En este artículo se describe la topología de red Azure más sencilla: una sola red virtual con varias subredes que hospedan una carga de trabajo. Use este patrón cuando tenga una sola aplicación administrada por un equipo y no necesite servicios compartidos como un firewall central o una puerta de enlace de VPN.

Quién necesita este artículo

Lea este artículo si:

  • Vas a desplegar tu primera carga de trabajo en Azure.
  • Un único equipo posee y opera todos los recursos.
  • No necesita servicios de red compartidos (firewall, Bastion, puerta de enlace) en varias cargas de trabajo.
  • Quiere la red más sencilla que todavía proporciona aislamiento y seguridad de nivel de subred.

Cambiar el foco de forma gradual: Una única red VNet plana con una subred por componente suele ser el primer paso adecuado para reubicar una carga de trabajo en una región.

Enfoque de modernización: Utiliza una red plana para una prueba piloto inicial de PaaS o una única carga de trabajo modernizada, y diseña sus subredes de modo que pueda pasar sin problemas a una topología hub-and-spoke cuando añadas servicios compartidos o una segunda región.

Enfoque multinube: Use una VNet plana como un único punto de apoyo en Azure durante la migración entre nubes: implemente primero la carga de trabajo y, después, planifique su espacio de direcciones y su segmentación para que pueda unirse a un hub o a Virtual WAN conforme evolucione el diseño.

servicios y características de Azure

La topología de red plana usa estos servicios principales de Azure:

Servicio Rol en esta topología
Azure Virtual Network Proporciona un espacio de direcciones privado y aislado para la carga de trabajo. Una red virtual tiene como ámbito una sola región de Azure.
Subredes y grupos de seguridad de red (NSG) Las subredes separan los niveles de aplicación. Los NSG filtran el tráfico entrante y saliente en el límite de cada subred. Los NSG son con estado: el tráfico de retorno de las conexiones permitidas se autoriza automáticamente.
zona de Azure DNS privado Proporciona resolución de nombres interna para los recursos de la red virtual. Vincule la zona con el registro automático habilitado para que las máquinas virtuales obtengan automáticamente registros DNS.
Subred de puerta de enlace(opcional) Hospeda una puerta de enlace de VPN o ExpressRoute si necesita una sola conexión a una red local.

¿Cómo elegir: mantener la topología plana o pasar a la topología hub-and-spoke?

Utiliza la siguiente tabla de decisión para determinar si la topología plana es adecuada para tu entorno o si, por el contrario, deberías adoptar una topología hub-and-spoke.

Condition Recommendation
Carga de trabajo única, equipo único, sin servicios compartidos En posición horizontal: este artículo es aplicable
Una segunda carga de trabajo independiente necesita su propio aislamiento de red Pasar a la topología hub-and-spoke
Necesita un firewall compartido, una puerta de enlace VPN o Azure Bastion para varias cargas de trabajo. Pasar a la topología hub-and-spoke
Las directivas de seguridad deben administrarse de forma centralizada en varias cargas de trabajo Pasar a la topología hub-and-spoke

Sugerencia

Si prevé agregar una segunda carga de trabajo en un plazo de seis a 12 meses, considere la posibilidad de empezar con hub-and-spoke desde el primer día. La sobrecarga es mínima porque solo se agrega una red virtual adicional y una conexión de emparejamiento. Este enfoque evita una migración perjudicial más adelante.

Consideraciones de diseño

Enfoque de diseño de red plana lift-and-shift

  • Use una red virtual con una subred para cada componente de aplicación (web, aplicación, datos) para reflejar un diseño típico de tres niveles local con un rediseño mínimo.
  • Aplique los NSG entre las subredes para recrear la segmentación existente y mantenga el espacio de direcciones alineado con los rangos del entorno local para evitar solapamientos.
  • Mantenga una estructura plana cuando un único equipo sea responsable de la carga de trabajo y no necesite servicios compartidos de firewall, puerta de enlace o Bastion.
  • Planifique la transición a un modelo hub-and-spoke antes de incorporar una segunda carga de trabajo, para que los servicios compartidos se implementen en un hub en lugar de tener que adaptarlos posteriormente.

Modernización del enfoque de diseño de red plana

  • Use una red plana para un piloto de PaaS temprano o una sola carga de trabajo modernizada: coloque los niveles de aplicación en subredes y llegue a Azure PaaS a través de puntos de conexión privados en una subred dedicada.
  • Reserve subredes dedicadas por adelantado para los servicios de plataforma que vaya a agregar, como Application Gateway y puntos de conexión privados, para que la red pueda crecer sin necesidad de reasignar direcciones.
  • Aplica los grupos de seguridad de red (NSG) y los grupos de seguridad de aplicaciones por nivel, de modo que la segmentación ya esté establecida si la carga de trabajo pasa a ser posteriormente un spoke en un diseño hub-and-spoke.
  • Mantén el espacio de direcciones sin solapamientos con tus otras regiones y VNet, para que puedas establecer una conexión de pares o pasar a un hub más adelante sin necesidad de renumerar.

Enfoque del diseño de red plana multinube

  • Use una VNet plana como único punto de apoyo en Azure durante una migración entre nubes: implemente primero la carga de trabajo y, después, agregue conectividad desde un hub a medida que la arquitectura evoluciona.
  • Planifica el espacio de direcciones de la VNet plana para evitar solapamientos con las VPC de AWS y las redes de Google Cloud, de modo que pueda incorporarse a IPsec o al enrutamiento de interconexión más adelante sin necesidad de traducción.
  • Mantenga la segmentación por niveles con los NSG para que la postura de seguridad de la carga de trabajo se mantenga cuando se convierta en un spoke detrás de un hub de Virtual WAN protegido.
  • Normalice la nomenclatura y el etiquetado de subredes para que coincidan con las demás nubes para que la carga de trabajo sea fácil de correlacionar durante y después de la migración.

Prerequisites

Antes de implementar esta topología:

  • Una suscripción Azure con permisos para crear redes virtuales y grupos de seguridad de red.
  • Un espacio de direcciones IP planificado. Un espacio de direcciones /16 proporciona 65 536 direcciones, que es un punto de partida común para una sola carga de trabajo. Azure reserva 5 direcciones por subred para uso interno. Para obtener instrucciones detalladas, consulte Planear el direccionamiento IP.
  • Descripción de los niveles de aplicación (por ejemplo, web, aplicación y datos) para que pueda asignarlos a subredes. Para obtener instrucciones de diseño de subred, consulte Diseño de redes virtuales y subredes.

Diseño de red

Diagrama que muestra una topología de red plana con subredes de capa de datos, aplicaciones y web, cada una protegida por un grupo de seguridad de red, dentro de una sola red virtual.

Una topología de red plana sigue esta estructura:

  • Una red virtual con un solo espacio de direcciones (por ejemplo, 10.0.0.0/16).
  • Varias subredes: una por nivel de aplicación o componente:
    • Subred de nivel web (por ejemplo, 10.0.1.0/24).
    • Subred de nivel de aplicación (por ejemplo, 10.0.2.0/24).
    • Subred de capa de datos (por ejemplo, 10.0.3.0/24).
    • Subred de puerta de enlace (opcional, por ejemplo, 10.0.255.0/27).
  • NSG asociados a cada subred con reglas que solo permiten el tráfico que necesita cada nivel.
  • Una zona DNS privada vinculada a la red virtual con el registro automático habilitado.

Note

Planee cuidadosamente los intervalos de direcciones IP. Si más adelante migra a una topología hub-and-spoke, las redes virtuales spoke deben tener rangos CIDR que no se solapen con los del hub. La elección de un esquema de direcciones bien estructurado ahora impide conflictos durante la migración.

Consideraciones de seguridad

Aplique estos procedimientos de seguridad a la red plana:

  • NSG en cada subred. Comience con una configuración base que deniegue todo el tráfico entrante y agregue reglas específicas de permiso para el tráfico legítimo entre niveles. Por ejemplo, permita HTTPS desde el nivel web al nivel de aplicación y permita SQL desde el nivel de aplicación hasta el nivel de datos.
  • No hay direcciones IP públicas directamente en máquinas virtuales. Exponga los servicios a través de un equilibrador de carga o Application Gateway. Use Azure Bastion para el acceso administrativo.
  • DNS privado para la resolución interna. Las zonas DNS privadas impiden que los nombres de host internos queden expuestos mediante consultas DNS públicas.
  • Aislamiento de la subred de puerta de enlace. Si agrega una vpn o una puerta de enlace de ExpressRoute, colóquela en una subred dedicada (denominada GatewaySubnet). No se admiten grupos de seguridad de red en la subred de puerta de enlace. Asociar un NSG a esta subred podría hacer que el gateway de red virtual deje de funcionar como se esperaba.

Importante

Al quitar una regla de NSG que permita una conexión, las conexiones activas existentes continúan sin interrupciones. Solo se bloquean las nuevas conexiones que coincidan con la regla eliminada.

En los artículos siguientes se proporcionan instrucciones más detalladas sobre temas relacionados:

Aprende más

Para obtener más información sobre los servicios de Azure usados en esta topología, consulte:

Pasos siguientes

Sugerencia

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

El siguiente paso en su proceso de lift-and-shift:

Diseñe su topología hub-and-spoke: La mayoría de las migraciones de tipo lift-and-shift superan rápidamente la capacidad de una red plana. Planee los servicios compartidos centralizados desde el principio.

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

Diseña tu topología hub-and-spoke: Las cargas de trabajo modernizadas con múltiples servicios, controles de seguridad y equipos necesitan una arquitectura hub-and-spoke desde el primer día.

Siguiente paso en su proceso de migración entre nubes:

Planifique su arquitectura de conectividad multinube: los entornos multinube necesitan una arquitectura de tránsito, no redes planas. Diseñe el modelo de conectividad multinube.

  • Last updated on