Microsoft AZ-700: Diseño de Azure Virtual Network — Guía de estudio

By Laurynas Brazys · 1 August 2026 · #microsoft #az-700 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Network Engineer AZ-700 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Planificación del espacio de direcciones y subredes

Un plan disciplinado de direccionamiento IP previene retrabajos futuros y evita colisiones con redes locales (on-premises) u otras VNets. Utilice bloques CIDR jerárquicos (por ejemplo, un /16 por cada unidad de negocio principal, un /24 por VNet, de /26 a /22 por subred según su función) y reserve rangos contiguos para expansión, emparejamiento (peering) y mapeos de sitios VPN/S2S. Azure impone requisitos de nombre y subred para varios servicios de la plataforma: GatewaySubnet debe existir (y tener el tamaño adecuado para incluir la puerta de enlace VPN y sus unidades de escalado), AzureFirewallSubnet debe ser dedicada y llamarse AzureFirewallSubnet, y AzureBastionSubnet debe ser una subred dedicada de /27 o mayor. Application Gateway y muchos dispositivos virtuales de red (NVAs) también requieren subredes dedicadas (sin otros recursos). Planifique la no superposición de direcciones entre VNets emparejadas y rangos locales (on-premises); los espacios de direcciones superpuestos rompen el emparejamiento, la VPN y el enrutamiento. Considere la delegación de subred al desplegar servicios de plataforma (instancias administradas de AKS, Azure Database) y evite colocar NSGs o UDRs que entren en conflicto con las rutas de plataforma requeridas para esos servicios. Un error común es subdimensionar la GatewaySubnet o la AzureFirewallSubnet; estos servicios pueden escalar y requerir IPs adicionales con el tiempo. Compensaciones: los CIDR más pequeños ahorran espacio de direcciones pero aumentan el riesgo de reconfiguración futura; los CIDR más grandes no cuestan nada pero aumentan la superficie de administración. Documente todas las asignaciones y reserve bloques para puntos de conexión privados de PaaS, jump hosts, agentes de monitoreo y capacidad de NAT de salida.

Emparejamiento de VNet, tránsito de puerta de enlace y precedencia de rutas

El emparejamiento de VNet (VNet peering) proporciona conectividad de baja latencia y alto ancho de banda, pero no es transitivo: el tráfico de un spoke emparejado no se enruta automáticamente a través de una segunda VNet emparejada para llegar a un entorno local (on-premises). Para centralizar la conectividad local, debe desplegar una VNet hub con una puerta de enlace VPN Gateway o ExpressRoute. Configure el emparejamiento del hub con allowGatewayTransit habilitado y configure el emparejamiento del spoke con useRemoteGateways habilitado; la VPN Gateway debe existir únicamente en el hub. Recuerde que el emparejamiento requiere espacios de direcciones no superpuestos y admite tanto el emparejamiento regional como el global (el emparejamiento global incurre en costos de transferencia de datos y una latencia ligeramente mayor). La precedencia de rutas es importante: las rutas definidas por el usuario (UDRs) tienen prioridad sobre las rutas aprendidas por BGP y las del sistema; las rutas BGP tienen prioridad sobre las rutas del sistema. Si necesita tunelización forzada (forced-tunneling) para la inspección de salida, cree UDRs que apunten a un VirtualAppliance (NVA) o a Azure Firewall, y luego anuncie las rutas apropiadas de vuelta al entorno local a través de BGP si es necesario. Los errores comunes incluyen olvidar establecer allowGatewayTransit en el hub o useRemoteGateways en los spokes, no volver a descargar las configuraciones del cliente P2S después de agregar spokes (los clientes P2S necesitan rutas actualizadas) y asumir que el emparejamiento es transitivo. Elija los SKUs de VPN Gateway según el rendimiento (throughput) y las características de P2S: considere VpnGw1/2/3 para entornos de producción con P2S y BGP; el SKU Basic carece de muchas características.

SKUs de VPN Gateway: VpnGw1 — rendimiento moderado, soporta OpenVPN/IKEv2/P2S; VpnGw2 — mayor rendimiento y escalado de TLS; VpnGw3 — el más alto rendimiento y la mayor escala. Basic — características limitadas y no recomendado para escenarios hub.

Puntos de conexión de servicio vs. puntos de conexión privados e implicaciones de DNS

Los puntos de conexión de servicio (service endpoints) extienden la identidad de su VNet a los servicios PaaS de Azure (Storage, SQL, Cosmos DB), de modo que el tráfico utiliza la red troncal de Microsoft mientras que el punto de conexión público del servicio se asegura para las subredes seleccionadas. Los puntos de conexión privados (private endpoints) colocan una interfaz de red en su subred que se asigna a la IP privada del recurso PaaS, proporcionando una conectividad verdaderamente privada. Elija puntos de conexión de servicio cuando desee un control de acceso simple a nivel de subred sin cambios de DNS; elija puntos de conexión privados cuando requiera acceso por recurso, aislamiento a nivel de VNet o deshabilitar por completo el acceso a la red pública. Los puntos de conexión privados crean una ENI y deben asociarse con una zona DNS privada (privatelink.<service>.azure.com) o requieren registros DNS A manuales; un error frecuente es descuidar el DNS, lo que hace que los clientes resuelvan la IP pública en lugar del punto de conexión privado. Tenga en cuenta también que los puntos de conexión privados consumen una IP de la subred de destino; planifique la capacidad de IPs. Los puntos de conexión de servicio no eliminan el punto de conexión público; para bloquear completamente una cuenta de almacenamiento, debe deshabilitar el acceso a la red pública después de habilitar el punto de conexión privado. Compensaciones de costo y operativas: los puntos de conexión privados aumentan la gestión (DNS por recurso y aprobaciones) y una ligera complejidad operativa, pero ofrecen un aislamiento más fuerte; los puntos de conexión de servicio son más simples y de menor costo, pero menos granulares.

Compromisos de diseño de rutas, NAT Gateway y Azure Firewall

Para un SNAT de salida predecible y una gestión de egreso simplificada, implemente Azure Virtual Network NAT (Standard NAT Gateway) en subredes o NIC y asocie direcciones IP públicas estándar o prefijos (solo SKU estándar). NAT Gateway descarga la gestión de puertos efímeros; si prevé un gran volumen de conexiones de salida, asocie múltiples prefijos de IP públicas para aumentar los puertos SNAT disponibles y evitar el agotamiento de puertos, algo común con muchas VM o hosts de contenedores. Azure Firewall proporciona inspección de estado centralizada y totalmente gestionada, inteligencia sobre amenazas y filtrado de aplicaciones/FQDN; elija Azure Firewall Standard para el filtrado fundamental y el SKU Premium para la inspección de TLS, IDPS y capacidades de amenaza mejoradas. Los dispositivos de red virtuales (NVA de terceros) ofrecen una gran riqueza de funcionalidades o alternativas de costo, pero requieren gestión, configuración de alta disponibilidad (HA) y planificación de escalado. Las UDR que apuntan a VirtualAppliance o Internet/NAT deben evaluarse en comparación con las rutas del sistema de Azure, ya que UDR incorrectas pueden interrumpir el tráfico de los servicios de la plataforma (por ejemplo, bloqueando el tráfico de los puntos de conexión de servicio o los sondeos de estado gestionados por la plataforma). Para alta disponibilidad y rendimiento, considere los SKU con redundancia de zona (Application Gateway v2, Firewall en Zonas de Disponibilidad) y las capacidades de autoescalado frente a los dispositivos de costo fijo. Errores comunes: asociar NAT tanto a la subred como a la NIC, lo que conduce a una precedencia inesperada; olvidar que NAT requiere una o varias IP públicas estándar; nombrar y dimensionar AzureFirewallSubnet incorrectamente; y asumir que las UDR serán ignoradas (estas anulan las rutas del sistema).

Problema práctico: Escenario de caso de uso

Escenario: Contoso Enterprises opera una red de Azure en topología hub-and-spoke. El hub en West US aloja una puerta de enlace de ExpressRoute y un VpnGw2 (en GatewaySubnet). Varios spokes contienen subredes de aplicaciones y puntos de conexión privados para servicios PaaS. Los empleados remotos se conectan a través de una VPN de punto a sitio (P2S) al hub.

Desafío: Los usuarios remotos pueden acceder a los recursos en el hub, pero no pueden alcanzar los recursos de VNet en los spokes después de adiciones recientes de spokes, y algunos clientes P2S muestran conjuntos de rutas obsoletos.

Enfoque recomendado:

En la VNet del hub, asegúrese de que la puerta de enlace VPN sea un VpnGw2 implementado en una GatewaySubnet con el tamaño adecuado (al menos /27); valide que es la única puerta de enlace en la topología con emparejamiento y que ExpressRoute coexiste a través del intercambio de rutas.
En el emparejamiento de hub a spoke, establezca allowGatewayTransit = true en el lado del hub. En cada emparejamiento de spoke, establezca useRemoteGateways = true y asegúrese de que los espacios de direcciones no se superpongan.
Regenere y distribuya la configuración actualizada del cliente VPN P2S desde la puerta de enlace VPN del hub (incluya IKEv2/OpenVPN) y solicite a los usuarios remotos que reinstalen el cliente para que sus tablas de enrutamiento incluyan los nuevos prefijos de los spokes.
Si los spokes deben enrutar el tráfico de salida a través del hub para su inspección, agregue UDR en las tablas de rutas de los spokes que dirijan 0.0.0.0/0 al dispositivo virtual del hub o a Azure Firewall (implementado en AzureFirewallSubnet) y anuncie las rutas necesarias de vuelta a través de BGP en ExpressRoute/VPN.

Justificación: Habilitar el tránsito de puerta de enlace con useRemoteGateways centraliza el enrutamiento local (on-prem) y P2S a través de la puerta de enlace del hub sin crear puertas de enlace adicionales, mientras que volver a emitir las configuraciones del cliente P2S actualiza las tablas de enrutamiento del cliente para que los nuevos prefijos de los spokes sean alcanzables; las UDR y BGP aseguran un egreso controlado y visibilidad para la inspección.

← ExpressRoute y Conectividad WAN · Todos los dominios · Redes Híbridas →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →