Microsoft AZ-700: Azure Virtual WAN y Hub-Spoke — 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.

Virtual WAN frente a hub-and-spoke clásico: elija el modelo de tránsito adecuado

Diseñar el tránsito global requiere elegir entre Azure Virtual WAN (vWAN) y un modelo hub-and-spoke tradicional construido con VNets, NVAs y peering. Virtual WAN proporciona una red troncal (backbone) global gestionada por Microsoft con vHubs que alojan de forma nativa la conectividad VPN, ExpressRoute y P2S y admiten la propagación de rutas automatizada, el escalado de sitio a sitio y las integraciones con socios de SD-WAN. Para las organizaciones que necesitan muchas conexiones de sucursales, enrutamiento global y un modelo operativo simple, vWAN reduce el trabajo de orquestación y mejora la resiliencia. En contraste, un hub-and-spoke manual (una VNet con un Azure Firewall o un NVA de terceros en un hub central y spokes conectados por peering) ofrece el máximo control sobre el flujo de paquetes, características personalizadas de NVA y, a menudo, un costo de estado estable más bajo para implementaciones pequeñas. Las principales compensaciones son el rendimiento (throughput) y la previsibilidad frente al control granular: los hubs de vWAN abstraen muchos detalles y ofrecen una escala casi global, pero añaden costos de servicio gestionado y una personalización menos flexible de la ruta de los paquetes. Las trampas comunes incluyen asumir que vWAN proporciona automáticamente peering transitivo a VNets no conectadas explícitamente; cada spoke o VNet debe estar conectado y asociado con las tablas de rutas del hub. Otro error frecuente es ignorar las restricciones de gobernanza y de nomenclatura de subredes (por ejemplo, el requisito de AzureFirewallSubnet para Azure Firewall) que rompen las implementaciones automatizadas si no se siguen.

Hub virtual seguro, Azure Firewall e integración de NVA

El modelo de hub virtual seguro añade capas de inspección y políticas sobre vWAN al integrar Azure Firewall (o un NVA de terceros) y Firewall Manager para centralizar la seguridad, el NAT y el enrutamiento para los spokes y los sitios on-prem. Azure Firewall debe desplegarse en la subred dedicada AzureFirewallSubnet y debe decidir entre los SKUs de Azure Firewall basándose en sus características. Planifique cuidadosamente las tablas de rutas: las tablas de rutas del hub controlan los flujos hacia los spokes, los sitios VPN, P2S e internet. Para forzar el túnel del tráfico hacia un NVA, asocie la conexión del spoke con una tabla de rutas del hub que dirija 0.0.0.0/0 al NVA/Firewall. Considere la alta disponibilidad y el rendimiento (throughput): Azure Firewall es zonal y admite el autoescalado con los SKUs Standard y Premium, pero el SKU Premium es necesario para la inspección de TLS y el IDPS. Evite colocar Application Gateway o endpoints de Private Link en subredes compartidas con la infraestructura del firewall; necesitan sus propias subredes. Vigile el agotamiento de puertos NAT y SNAT para flujos de salida a gran escala; implemente la agrupación de SNAT (SNAT pooling), Azure Firewall con reglas DNAT, o use NAT Gateway cuando sea aplicable.

Azure Firewall Standard vs Premium: Standard admite firewall con estado (stateful), filtrado de FQDN, SNAT/DNAT básico; Premium añade inspección de TLS, IDPS, filtrado de URL y exclusiones de etiquetas de nombre de dominio completo (FQDN).
Load Balancer Basic vs Standard: Standard admite redundancia de zona, sondeos de estado del backend (health probes) y es requerido para el ILB del servicio Private Link; Basic carece de resiliencia de zona y de reglas de seguridad más estrictas.
VPN Gateway SKUs: VpnGw1/2/3 (aumentan el rendimiento y los túneles concurrentes); use niveles superiores para más túneles S2S o un mayor rendimiento (throughput) agregado.

Patrones de conectividad privada: Private Link, Private Endpoints y service endpoints

Private Link y los private endpoints proporcionan acceso de primera clase a PaaS sin enrutar el tráfico por internet; los service endpoints aseguran el acceso al servicio pero mantienen la salida (egress) a través de la red troncal (backbone) del servicio público. Use un private endpoint cuando necesite IPs privadas por recurso e integración con DNS; use service endpoints cuando necesite un control de acceso más simple a nivel de subred y se sienta cómodo exponiendo la salida (egress) del servicio a la red troncal del servicio. Los detalles operativos importantes incluyen la resolución de DNS: los private endpoints requieren actualizar el DNS on-prem o las Azure DNS Private Zones para que los clientes resuelvan la IP privada; los reenviadores condicionales (conditional forwarders) a servidores DNS on-prem son comunes para redes conectadas por S2S. Los escenarios de servicio Private Link entre suscripciones son compatibles si los recursos están en el mismo tenant de Azure AD; despliegue el servicio Private Link detrás de un Standard Internal Load Balancer (ILB) para obtener escalabilidad y redundancia de zona. Una trampa frecuente es usar un Basic ILB o un SKU incorrecto, lo que limita el estado del backend y la escalabilidad. Para un servicio Private Link que soporte un alto volumen de conexiones, use un Standard ILB, backends de conjuntos de escalado (scale-set) y considere múltiples NIC de endpoint por instancia de backend. Considere también la protección contra DDoS: habilite DDoS Protection Standard para las NIC de cara al público y planifique el escalado de puertos SNAT y NAT Gateway donde se originen muchas conexiones de salida.

Tablas de enrutamiento del hub de vWAN y diseño práctico de rutas

vWAN utiliza tablas de enrutamiento del hub para dirigir el tráfico entre los spokes conectados, los sitios on-premise y el internet. Cada conexión (sitio, VNet, P2S) puede asociarse con una tabla de enrutamiento del hub; las prioridades de ruta y las reglas de propagación determinan el reenvío final. Un buen diseño comienza con una tabla de enrutamiento del hub predeterminada que reenvía el tráfico con destino a internet hacia Azure Firewall o un NVA, y tablas de enrutamiento especializadas para sucursales que requieren una salida local (breakout) on-premise. BGP desde los dispositivos VPN on-premise propaga los prefijos hacia el hub, y puede redistribuirlos a los spokes o filtrarlos con tablas de enrutamiento. Un error común son las rutas definidas por el usuario (UDR) en conflicto en las VNets de los spokes que intentan anular la propagación del hub; en vWAN, las tablas de enrutamiento del hub tienen precedencia para las interconexiones, pero las UDR en los spokes todavía afectan el egreso local. Para el túnel forzado, asocie las conexiones de los spokes a una tabla de enrutamiento del hub que dirija 0.0.0.0/0 a su dispositivo de inspección elegido. Supervise y planifique los límites de rutas: los hubs de vWAN tienen un número máximo de prefijos aprendidos y anunciados; diseñe la sumarización de prefijos y comunidades o filtros de BGP para mantenerse dentro de los límites. Pruebe siempre la resolución de DNS y el DNS dividido (split-DNS) para los private endpoints, y documente el comportamiento de conmutación por error (failover) para diseños multihub activo/activo para cumplir con los SLA de resiliencia.

Problema práctico: Escenario de caso de uso

Escenario: Contoso Manufacturing opera una infraestructura global en Azure con una arquitectura VNet hub-and-spoke existente en dos regiones, múltiples sitios on-premise conectados a través de SD-WAN y el requisito de centralizar la seguridad y proporcionar conectividad PaaS privada entre suscripciones.

Desafío: Necesitan un tránsito global gestionado y escalable que centralice la inspección (inspección TLS, IDPS), soporte muchas conexiones de sucursales a través de SD-WAN y exponga varios recursos PaaS de almacenamiento y bases de datos de forma privada a los spokes y a los sitios on-premise sin exponerlos públicamente.

Enfoque recomendado:

Desplegar Azure Virtual WAN (vWAN) y crear hubs virtuales seguros en cada región. En cada hub, habilitar Azure Firewall Premium (para inspección TLS e IDPS) e integrarlo con Firewall Manager. Asociar el hub con las conexiones SD-WAN de partners de vWAN para una incorporación directa de las sucursales (direct branch on-ramp).
Configurar las tablas de enrutamiento del hub para dirigir el tráfico con destino a internet y entre regiones hacia Azure Firewall Premium; crear tablas de enrutamiento especializadas para las sucursales que deben tener una salida (egress) on-premise. Usar BGP desde la SD-WAN para anunciar los prefijos on-premise en la vWAN y aplicar filtros de prefijos para evitar la sobrecarga de rutas (route bloat).
Para los servicios PaaS, aprovisionar servicios de Private Link en una VNet dedicada por región detrás de un Standard Internal Load Balancer y exponer Private Endpoints en las VNets de los spokes y en los sitios on-premise a través de la conectividad de vWAN. Usar Azure DNS Private Zones y reenviadores condicionales para asegurar la resolución desde los sitios on-premise.
Habilitar DDoS Protection Standard en los endpoints públicos, desplegar NAT Gateway para grandes necesidades de SNAT de salida en los spokes y supervisar las métricas de SNAT/DNAT. Usar políticas de Firewall Manager para la distribución centralizada de reglas y configurar el registro en un área de trabajo central de Log Analytics.

Justificación: Este enfoque aprovecha vWAN para una conectividad de sucursales escalable y un tránsito global, utiliza Azure Firewall Premium para la inspección avanzada y centralizada requerida por la política de seguridad, y Private Link para un acceso seguro a PaaS sin exposición pública, equilibrando la capacidad de gestión, la seguridad y la escala operativa.

← Supervisión y Solución de Problemas de Red · Todos los dominios

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