Azure redes virtuales y subredes

Las redes virtuales de Azure (VNets) y las subredes son los elementos básicos fundamentales de toda red de Azure. En este artículo se explica cómo las redes virtuales proporcionan aislamiento, cómo organizan las subredes los recursos y cómo ajustar y estructurar la red para cargas de trabajo de producción.

Lo que trata este artículo

En este artículo se tratan los límites de aislamiento de red virtual, el tamaño de subred y las direcciones reservadas, las subredes de plataforma dedicadas para servicios como Azure Firewall y Application Gateway, el emparejamiento de VNet y los patrones comunes de diseño de red.

Quién necesita este artículo

Lea este artículo si:

  • Implementa la primera carga de trabajo en Azure y necesita comprender cómo funcionan las redes antes de crear recursos.
  • Si está planificando un entorno con varias cargas de trabajo y necesita decidir cuántas VNets y subredes crear.
  • Están migrando cargas de trabajo locales a Azure y necesitan comprender cómo Azure las redes difieren de las redes físicas.
  • Es necesario ajustar el tamaño de las subredes correctamente para Azure servicios de plataforma, como Azure Firewall, VPN Gateway o Azure Kubernetes Service (AKS).
  • Quiere saber cuándo separar las cargas de trabajo en redes virtuales diferentes frente a mantenerlos en la misma red virtual.

Enfoque lift-and-shift: Refleja en Azure la segmentación de subredes de tu entorno local. Asigne las VLAN existentes y las zonas de seguridad a las subredes, mantenga los espacios de direcciones alineados con los rangos que su equipo ya utiliza y dimensione las subredes con suficiente margen para no tener que reasignar direcciones durante la migración.

Modernización del foco: Diseñar subredes en torno a servicios de plataforma y automatización. Dimensione correctamente las subredes para AKS, los puntos de conexión privados y los servicios de plataforma dedicados, y planifique el uso de Azure Virtual Network Manager para aplicar una configuración coherente en múltiples redes virtuales.

Enfoque multicloud: Planifique espacios de direcciones que no se solapen en Azure, AWS y Google Cloud antes de crear ninguna VNet. Reserve rangos CIDR que no entren en conflicto con las VPC existentes para poder interconectar nubes o conectarlas mediante VPN sin NAT.

servicios y características de Azure

Los siguientes servicios y características componen la base de redes virtuales en Azure:

Servicio o característica Qué proporciona Cuándo usarlo
Red virtual de Azure (VNet) Una red privada aislada en Azure. Todas las redes Azure comienzan aquí. Los recursos de la misma red virtual pueden comunicarse de forma predeterminada; Los recursos de diferentes redes virtuales no se pueden comunicar a menos que los conecte explícitamente. Siempre: cada carga de trabajo que necesite conectividad de red requiere una red virtual.
Subred Partición del espacio de direcciones de la red virtual. Las subredes constituyen el ámbito de asociación de los grupos de seguridad de red (NSG) y las tablas de enrutamiento. Siempre: organice los componentes de carga de trabajo en subredes por función o límite de seguridad.
Emparejamiento de VNet Baja latencia, conectividad privada entre dos redes virtuales de la misma región o entre regiones. El tráfico permanece en la red troncal de Microsoft. El emparejamiento no es transitivo; cada emparejamiento es un enlace directo. Cuando los recursos de distintas redes virtuales deben comunicarse. Para el emparejamiento entre regiones, consulte Conectividad entre regiones.
Interconexión de subredes (versión preliminar) Interconexión entre subredes específicas, en lugar de VNet completas. Proporciona un control granular sobre qué subredes participan en las relaciones de emparejamiento. Cuando se necesita un control detallado de la interconexión entre subredes específicas de diferentes VNet. Consulte la sección restricciones .
Tabla de rutas/Rutas definidas por el usuario (UDR) Invalide las rutas del sistema predeterminadas en Azure para controlar dónde se envía el tráfico. Aplicado en el nivel de subred. Cuando necesite forzar el tráfico a través de un firewall o una aplicación virtual de red (NVA). Requerido para el control de salida en topología hub-and-spoke. Consulte Diseño de Azure Firewall y Topología hub-and-spoke.
Azure Virtual Network Manager (AVNM) Cree, administre y aplique de forma centralizada configuraciones de red a VNets en distintas suscripciones. Al administrar muchas redes virtuales en varias suscripciones. Consulte Administración de red centralizada.

Diagrama que muestra la red virtual con subredes de carga de trabajo para niveles de datos, aplicaciones y web junto con subredes de plataforma dedicadas para puerta de enlace, firewall y Bastion

Cómo elegir

¿Qué es una red virtual?

Una red virtual (VNet) es una red aislada definida por software en Azure. Piense en ella como su red privada en Azure. A diferencia de una red física que usa cables, conmutadores y enrutadores, una red virtual está completamente definida por software. Lo crea, asígnele un espacio de direcciones e implemente recursos en él.

Características clave:

  • Con ámbito regional: una red virtual existe en una sola región de Azure. Todos los recursos de esa red virtual deben estar en la misma región. Una red virtual abarca zonas de disponibilidad dentro de esa región.
  • Aislamiento de forma predeterminada: los recursos de una red virtual no se pueden comunicar con los recursos de otra red virtual a menos que cree explícitamente una conexión (emparejamiento o VPN).
  • Conectividad interna predeterminada: los recursos de la misma red virtual pueden comunicarse entre sí de forma predeterminada a través de rutas del sistema que Azure proporciona.

¿Qué es una subred?

Una subred es un intervalo de direcciones IP dentro de la red virtual. Las subredes le permiten:

  • Segmente la red por componente de carga de trabajo (por ejemplo, nivel web, nivel de aplicación, capa de datos).
  • Aplique reglas de seguridad: Los NSG se asocian a nivel de subred para filtrar el tráfico.
  • Enrutamiento de control: las tablas de rutas se adjuntan en el nivel de subred para dirigir el tráfico.

Azure reserva cinco direcciones IP en cada subred: las cuatro primeras y la última. Por ejemplo, en una subred /24 (256 direcciones), solo se pueden usar 251. Tenga en cuenta esta reserva en sus cálculos de dimensionamiento.

Ejemplo: Aplicación de tres niveles

Una aplicación web típica de tres niveles usa tres subredes para separar los problemas y aplicar reglas de seguridad distintas:

Subred Intervalo CIDR propósito Recursos de ejemplo
web-subnet 10.0.1.0/24 Servidores web front-end que aceptan tráfico HTTP/HTTPS entrante desde Internet o Application Gateway Azure App Service Environment, conjuntos de escalado de máquinas virtuales que ejecutan NGINX
app-subnet 10.0.2.0/24 Lógica de aplicación de nivel intermedio. Acepta el tráfico solo desde la subred web. Azure Functions (integrado con red virtual), máquinas virtuales que ejecutan lógica de negocios
data-subnet 10.0.3.0/24 Almacenes de datos. Acepta el tráfico solo desde la subred de la aplicación. No hay acceso directo a Internet. Azure SQL Managed Instance, puntos de conexión privados para Azure SQL Database o Cosmos DB

Este diseño permite aplicar un NSG a cada subred para restringir el tráfico únicamente a lo que necesita esa capa. La subred web permite HTTPS entrante (puerto 443). La subred de la aplicación solo permite el tráfico entrante desde el intervalo IP de la subred web. La subred de datos solo permite el tráfico entrante desde el intervalo IP de la subred de la aplicación.

En el caso de un patrón de modernización basado en AKS, podría usar una subred aks-nodes como 10.0.4.0/24 para los grupos de nodos del clúster cuando implemente Azure CNI Overlay. En ese modelo, solo los nodos consumen direcciones IP de la VNet de la subred. Los pods utilizan un CIDR de superposición independiente, lo que permite mantener la subred de los nodos más pequeña que en un diseño de AKS con red plana.

Patrones comunes

Los siguientes diseños de subred cubren los escenarios de implementación de Azure más comunes:

Pattern Subredes Cuándo se deben usar
Aplicación web sencilla web + data Aplicaciones de dos niveles con un front-end y una base de datos. Complejidad mínima.
Empresa de tres niveles web + app + data + management Cargas de trabajo empresariales tradicionales con niveles diferenciados y una subred de salto o bastión para la administración.
AKS con servicios compartidos aks-nodes + aks-ingress + appgw + shared Cargas de trabajo de Kubernetes con una subred dedicada al controlador de entrada y Application Gateway para WAF.
Salida de tipo hub-and-spoke AzureFirewallSubnet + GatewaySubnet + AzureBastionSubnet + management La VNet hub en una topología de tipo hub-and-spoke. Servicios compartidos a través de los cuales las VNet spoke enrutan el tráfico. Véase Topología hub-and-spoke.
Carga de trabajo de datos compute + data + private-endpoints + management Cargas de trabajo de plataformas de análisis y datos en las que los puntos de conexión privados para almacenamiento y bases de datos necesitan su propia subred para una mayor claridad en la planificación de direcciones IP.

¿Cuántas redes virtuales y subredes?

El principio rector es sencillo: use una red virtual por aplicación y una subred por componente (nivel). Este valor predeterminado mantiene aislada cada carga de trabajo, hace que el tráfico entre niveles sea fácil de controlar con grupos de seguridad de red y deja espacio para crecer. Ajusta a partir de ahí en función de los servicios compartidos, los requisitos de aislamiento y las necesidades de escalado.

Use esta tabla de decisiones para determinar la estrategia de red virtual y subred:

Su situación Enfoque recomendado
Carga de trabajo única, equipo único, no se necesitan servicios compartidos Una red virtual con subredes por componente de aplicación (web, lógica de aplicación, datos). Consulte Topología de carga de trabajo única.
Varias cargas de trabajo independientes que comparten una puerta de enlace o un firewall VNet hub para servicios compartidos + una VNet spoke por carga de trabajo. Véase Topología hub-and-spoke.
Aislamiento estricto entre cargas de trabajo (radio de explosión, requisitos de cumplimiento) Una red virtual por carga de trabajo sin emparejamiento entre ellas.
Entorno muy grande con muchas suscripciones y regiones Azure Virtual WAN con administración automatizada de hubs. Consulte Virtual WAN topología.

Referencia de dimensionamiento de subred dedicada

Muchos Azure servicios de plataforma requieren su propia subred dedicada con un nombre específico y un tamaño mínimo. En el diagrama siguiente se muestran los requisitos de nomenclatura y los tamaños mínimos para las subredes de plataforma dedicadas:

Diagrama que muestra los tamaños mínimos de subred para cinco subredes de plataforma dedicadas, como puerta de enlace, firewall, Bastion y Route Server

Use esta tabla al planear el espacio de direcciones:

Servicio de Azure Tamaño mínimo de subred Nombre de subred requerido Notes
Azure Firewall /26 (59 direcciones IP utilizables) AzureFirewallSubnet Obligatorio para todos los SKU de cortafuegos. Consulte diseño de Azure Firewall.
VPN Gateway /27 (27 direcciones IP utilizables) GatewaySubnet Microsoft recomienda /27 o mayor para disponer de margen de escalabilidad.
Azure Bastion /26 (59 direcciones IP utilizables) AzureBastionSubnet Mínimo /26 para todos los despliegues creados con posterioridad a noviembre de 2021.
Application Gateway v2 /24 recomendado (251 direcciones IP utilizables) No se requiere ningún nombre Muy recomendable /24 para admitir el escalado automático. El mínimo se basa en una fórmula (instancias + 5 reservadas + 1 IP privada de front-end).
Entorno de Servicio de Aplicaciones /24 (producción), /23 (escala máxima) No se requiere ningún nombre El escalado consume direcciones IP de la subred. Use /23 si planea escalar cerca del máximo de 200 instancias.
Servidor de rutas de Azure /26 (59 direcciones IP utilizables) RouteServerSubnet Necesario para el intercambio de rutas BGP con las NVA.
Resolución privada de DNS de Azure Mínimo /28 por subred de punto de conexión Subredes de entrada y salida dedicadas Requiere subredes independientes para los puntos de conexión entrantes y salientes. No se puede compartir con otros recursos.
AKS (Azure Kubernetes Service) Basado en fórmulas (dependiente de CNI) No se requiere ningún nombre Consulte la guía de ajuste de tamaño de AKS.

Note

Los puntos de conexión privados consumen direcciones IP de subredes existentes. No requieren una subred dedicada. Factorice este consumo de IP en el ajuste de tamaño de la subred. Para obtener información detallada sobre el planeamiento de IP, consulte Planeamiento de direcciones IP.

Ajuste de tamaño de subred de AKS

El ajuste de tamaño de la subred de AKS depende de la opción del complemento de interfaz de red de contenedor (CNI). No hay ningún tamaño mínimo único:

  • Azure CNI Overlay: la subred solo necesita alojar nodos porque los pods usan un bloque CIDR privado independiente (enrutamiento entre dominios sin clases). Una subred significativamente más pequeña es aceptable en comparación con las redes planas.
  • Azure CNI (red plana): La subred debe tener capacidad para tanto los nodos como los pods. Fórmula: (nodes + surge) × (max_pods + 1). Un /21 o mayor es común para los clústeres con 50 o más nodos.
  • Kubenet: Solo los nodos consumen direcciones IP de las subredes de la VNet. Los pods obtienen direcciones IP internas del clúster.

Para obtener fórmulas de ajuste de tamaño por opción de CNI, consulte Planear el direccionamiento IP para el clúster de AKS.

Restricciones de emparejamiento de subredes

El emparejamiento de subredes conecta subredes específicas entre VNet en lugar de espacios de direcciones completos. Este enfoque proporciona un control granular sobre qué subredes participan en las relaciones de emparejamiento.

Importante

El emparejamiento de subredes está actualmente en versión preliminar y tiene las restricciones siguientes:

  • Requiere que la suscripción se añada a una lista aprobada (no es una inscripción de autoservicio).
  • CLI, plantilla de ARM, Terraform o PowerShell solo (sin compatibilidad con el portal)
  • Las SKU V5 basadas en Intel (o LAS SKU basadas en AMD Génova/Cobalt 100) son necesarias para su uso en producción para evitar un error conocido en las SKU de generación anteriores: consulte Configuración del emparejamiento de subredes para los requisitos de hardware actuales.
  • Máximo de 200 subredes por lado por enlace de emparejamiento
  • Un máximo de 1.000 subredes en total en todas las conexiones de emparejamiento por cada red virtual
  • Las subredes deben pertenecer a espacios de direcciones únicos y no superpuestos

Para conocer las limitaciones actuales y el registro, consulte Configurar el emparejamiento de subredes.

Note

Azure Virtual Network Manager (AVNM) no puede distinguir el emparejamiento de subred del emparejamiento de VNet. Si usa AVNM para administrar configuraciones de emparejamiento, tenga en cuenta que las relaciones de emparejamiento a nivel de subred aparecen como emparejamiento estándar de VNet en AVNM.

Consideraciones de diseño

Enfoque del diseño de VNet y subredes lift-and-shift.

  • Recree su segmentación local: asigne cada VLAN o zona de seguridad a una subred para que los límites existentes del firewall y las responsabilidades operativas se mantengan con un rediseño mínimo.
  • Dimensiona las subredes con margen de escalabilidad. Reasignar direcciones IP después de la migración resulta perjudicial, por lo que conviene asignar rangos CIDR mayores de los que requiere su número actual de hosts, para absorber el crecimiento y las cinco direcciones que Azure reserva por subred.
  • Mantenga los espacios de direcciones de Azure alineados con los rangos del entorno local siempre que sea posible para simplificar el enrutamiento y evitar solapamientos al conectarse mediante VPN Gateway o ExpressRoute.
  • El valor predeterminado es una red virtual por aplicación migrada con una subred por nivel. Este diseño refleja las arquitecturas locales típicas de tres capas y hace que la migración sea predecible.

Modernizar el enfoque de diseño de la VNet y la subred

  • Diseñe primero subredes en torno a los servicios de plataforma: subredes dedicadas para Azure Firewall, Application Gateway y Bastion, además de subredes de tamaño correcto para AKS en función de su elección de CNI.
  • Utiliza Azure CNI Overlay para AKS a fin de mantener pequeñas las subredes de los nodos, ya que los pods se asignan desde un espacio CIDR de superposición independiente, en lugar del espacio de direcciones de la VNet.
  • Reserve una subred dedicada para puntos de conexión privados, por lo que el consumo de IP permanece predecible a medida que adopta más servicios paaS Azure.
  • Adopte Azure Virtual Network Manager tempranamente para aplicar grupos de red, conectividad y configuraciones de seguridad de forma coherente a medida que el número de redes virtuales crece entre suscripciones.

Enfoque del diseño de VNet y subredes en entornos multinube

  • Establezca un plan de direcciones global antes de crear cualquier red virtual. Reserve bloques CIDR no superpuestos para Azure que no entren en conflicto con las VPN de AWS existentes o las redes de GOOGLE Cloud VPC. Esta reserva es obligatoria para las VPN enrutadas o la interconexión.
  • Asigne las primitivas de red de cada nube a Azure: una VPC de AWS o una red VPC de Google Cloud se corresponde con una VNet de Azure, y los grupos de seguridad se corresponden con los NSG.
  • Reserva espacio de subred para los componentes de conectividad entre nubes, como un GatewaySubnet para la VPN Gateway o el concentrador utilizado por Azure Virtual WAN, de modo que la infraestructura de tránsito tenga margen para escalar.
  • Normalice la nomenclatura y el etiquetado de subredes entre nubes para que los equipos de operaciones puedan correlacionar niveles equivalentes cuando solucionan problemas de tráfico multinube.

Prerequisites

Antes de diseñar la red virtual y el diseño de subred, asegúrese de que tiene:

  • Suscripción de Azure: una suscripción de Azure activa con permisos para crear recursos de red (rol de Colaborador de red o superior).
  • Grupo de recursos: un grupo de recursos de la región de destino para contener recursos de red virtual.
  • Decisión de región: elija la región de Azure principal en función de la proximidad a los usuarios, los requisitos de cumplimiento y la disponibilidad del servicio.
  • Planificación del espacio de direcciones: decida un intervalo de direcciones IP (bloque CIDR) que no se superponga con las redes locales de la organización ni con otras redes virtuales con las que pretenda establecer emparejamiento. Consulte Planeamiento de direcciones IP para obtener instrucciones.

Consideraciones de seguridad

Las redes virtuales y subredes son la primera capa de segmentación de red. Aplique los siguientes procedimientos de seguridad:

  • Grupos de seguridad de red (NSG): asocie grupos de seguridad de red a cada subred para filtrar el tráfico entrante y saliente. Defina reglas de permiso específicas del rol de cada subred y deniegue todo lo demás de forma predeterminada. Para obtener instrucciones detalladas, consulte Grupos de seguridad de red y grupos de seguridad de aplicaciones.
  • Tunelización forzada con UDR: si los requisitos de cumplimiento exigen que todo el tráfico enlazado a Internet pase a través de un dispositivo de inspección local o un firewall en la nube, use tablas de rutas con rutas definidas por el usuario para invalidar el enrutamiento de Internet predeterminado. Consulte Conectividad saliente y de egreso.
  • Aislamiento de subred: coloque recursos con distintos niveles de confianza en subredes independientes. Por ejemplo, mantenga las bases de datos en una subred que solo permita el tráfico entrante desde la subred del nivel de aplicación. Esta separación limita el movimiento lateral si un atacante pone en peligro un componente.
  • Subredes dedicadas para servicios de plataforma: muchos servicios de plataforma Azure (Azure Firewall, Application Gateway, Bastion) se implementan en subredes dedicadas. Este aislamiento garantiza que las reglas de seguridad y enrutamiento del servicio de plataforma no interfieran con las subredes de carga de trabajo.

Interacción entre NSG y la subred

Al asociar un grupo de seguridad de red (NSG) a una subred, las reglas del NSG se aplican a todos los recursos de esa subred. Comprenda estos comportamientos de interacción:

  • Evaluación acumulativa: si la NIC de una máquina virtual también tiene un NSG, Azure evalúa tanto el NSG de nivel de subred como el NSG de nivel de NIC. Para el tráfico entrante, Azure evalúa primero el NSG de la subred y, a continuación, el NSG de la NIC. Para el tráfico saliente, Azure evalúa primero el NSG de la NIC y, después, el NSG de la subred.
  • Denegación predeterminada: Azure incluye reglas predeterminadas que permiten el tráfico dentro de la red virtual y el acceso saliente a Internet. Después de agregar reglas de denegación personalizadas, compruebe que el tráfico legítimo (por ejemplo, Azure Load Balancer sondeos de estado de la dirección IP 168.63.129.16) no está bloqueado accidentalmente.
  • Etiquetas de servicio y ASG: use etiquetas de servicio (como AzureLoadBalancer, Internet, VirtualNetwork) y grupos de seguridad de aplicaciones (ASG) en reglas de NSG en lugar de direcciones IP sin procesar. Este enfoque simplifica la administración de reglas y se adapta automáticamente a medida que cambian los intervalos IP de Azure.
  • Registros de flujo para visibilidad: habilite los registros de flujo de NSG en cada NSG de nivel de subred para capturar el tráfico aceptado y denegado. Los registros de flujo le ayudan a comprobar que las reglas de seguridad funcionan según lo previsto y proporcionan evidencia para las auditorías de cumplimiento. Consulte Registros de flujo de NSG para obtener instrucciones de configuración.

Estos artículos de la guía de diseño de redes de Azure tratan temas relacionados:

Aprende más

Para obtener más información sobre Azure redes virtuales, consulte los siguientes recursos:

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:

Planee el espacio de direcciones IP: asigne un grupo de CIDR /16 que evite superponerse con los intervalos de direcciones locales.

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

Planifique su espacio de direcciones IP: asigne grupos de direcciones IP de dos regiones con rangos que no se solapen para el emparejamiento activo-activo.

A continuación, en el itinerario entre nubes:

Planear el espacio de direcciones IP: diseñe direcciones no superpuestas entre Azure, Amazon Web Services (AWS) y Google Cloud.

  • Last updated on