Las redes son uno de los dominios más exigentes del examen AZ-305. Se requiere una comprensión precisa de los límites entre servicios: la diferencia entre Front Door y Traffic Manager, las limitaciones de Application Gateway y por qué BGP es obligatorio con ExpressRoute. Este artículo se centra en los patrones clave extraídos del análisis de 42 preguntas reales del examen.
---
Diseño de VNet y subredes
Una VNet pertenece a una única región de Azure. Si despliegas infraestructura en 3 regiones, el número mínimo de VNets es 3, y la separación por capas (frontend/backend/base de datos) se gestiona a nivel de subred. Una trampa habitual en el examen es calcular número de regiones × número de capas cuando se pregunta por el "número mínimo de VNets".
En entornos híbridos, los conflictos de espacio de direcciones IP son fatales. Si las direcciones se solapan, el enrutamiento es imposible y no existe ninguna solución alternativa. Azure reserva 5 direcciones IP por subred (dirección de red, puerta de enlace, dos DNS y broadcast). Una subred /24 ofrece 251 direcciones utilizables, más que suficiente para 150 máquinas virtuales.
Principios de diseño de GatewaySubnet
La subred para un VPN Gateway o un ExpressRoute Gateway debe llamarse exactamente . Se aplican tres reglas estrictas.
Subred dedicada obligatoria: no se pueden colocar cargas de trabajo como máquinas virtuales junto con la puerta de enlace. No aplicar NSG: aplicar un NSG bloquea el tráfico del plano de control y provoca fallos en los túneles. Tamaño recomendado: /27 o mayor. Un /27 es la opción segura si se planea una migración a ExpressRoute o la coexistencia de dos puertas de enlace.
El requisito fundamental de VNet Peering es que los espacios de direcciones de las dos VNets no se solapen. Si se solapan, es obligatorio rediseñar el espacio IP — no existe ninguna solución alternativa mediante NAT Gateway o VPN Gateway.
---
Conectividad híbrida: VPN Gateway y ExpressRoute
ExpressRoute utiliza BGP (Border Gateway Protocol) como su único protocolo de enrutamiento. Si ves una opción de enrutamiento estático en una pregunta del examen, elimínala de inmediato. Cuando el sitio A falla, la sesión BGP termina y el tráfico se conmuta automáticamente al sitio B en cuestión de segundos. Para distinguir rutas primarias de rutas de respaldo en una configuración redundante, se utiliza AS Path Prepending: mantén el AS Path corto para la ruta primaria (sitio A) y largo para la de respaldo (sitio B).
Cuando aparezcan las palabras clave "conmutación por error automática + enrutamiento dinámico", elige BGP. Si el requisito es "fijar rutas manualmente", elige UDR.
Selección de SKU de Azure Virtual WAN
Virtual WAN entra en juego cuando necesitas gestionar múltiples sitios desde un hub central.
SKU Basic: solo admite VPN de sitio a sitio. No admite ExpressRoute ni enrutamiento transitivo entre regiones. SKU Standard: admite ExpressRoute, VPN S2S, VPN P2S y enrutamiento transitivo entre regiones.
Siempre que el examen mencione ExpressRoute o enrutamiento transitivo entre regiones, la respuesta es SKU Standard. Para la ubicación de hubs, si el requisito es "enrutamiento al punto más cercano en N continentes", se necesitan como mínimo N hubs. Un Secured Virtual Hub integra Azure Firewall en el hub. Cuando aparecen simultáneamente las tres palabras clave P2S + enrutamiento transitivo + filtrado de FQDN, selecciona Virtual WAN Standard + Secured Virtual Hub.
---
Enrutamiento global de tráfico: Front Door, Traffic Manager, CDN
Front Door es un proxy de capa 7 que opera mediante Anycast en la red de borde global de Microsoft. Acepta tráfico en el PoP más cercano al usuario y aplica políticas WAF en el borde. Proporciona conmutación por error automática entre regiones (en segundos), WAF integrado (SQL Injection, XSS, bots, limitación de tasa), descarga SSL, enrutamiento basado en ruta URL y afinidad de sesión basada en cookies, todo como un único servicio.
Front Door Premium admite orígenes de Private Link. Las máquinas virtuales del backend nunca quedan expuestas a internet; Front Door se conecta mediante una ruta privada. Para permitir solo el tráfico de Front Door en un NSG, usa la etiqueta de servicio . Microsoft la mantiene automáticamente, por lo que nunca necesitas gestionar listas de IP.
Traffic Manager es un servicio de entrega de tráfico basado en DNS. Simplemente devuelve la IP del punto de conexión óptimo al cliente como respuesta DNS — ningún paquete de tráfico pasa a través de él. Debido a esta arquitectura no interceptora, no puede realizar manipulación de encabezados HTTP, limitación de tasa ni descarga SSL. Combinarlo en capas con Application Gateway WAF por región es un patrón muy eficaz: Traffic Manager selecciona la región a nivel DNS, mientras que Application Gateway gestiona el enrutamiento por encabezado HTTP y el WAF.
---
Equilibrio de carga: Application Gateway y Azure Load Balancer
Application Gateway es un servicio de equilibrio de carga de capa 7 para una única región. No cuenta con enrutamiento entre regiones ni capacidad de conmutación por error automática. Para servir múltiples regiones, se despliegan instancias separadas en cada una y se coloca Traffic Manager o Front Door por encima. El SKU con WAF ofrece protección basada en OWASP CRS contra SQL Injection y XSS, afinidad de sesión por cookies, enrutamiento basado en ruta URL y escalado automático. Cuando el requisito sea "WAF + afinidad de sesión + equilibrio de carga como un único servicio", Application Gateway WAF es la respuesta correcta.
El patrón de combinar API Management (APIM) con Application Gateway también se evalúa. El tráfico externo entra a través de Application Gateway (WAF) y se reenvía al APIM dentro de la VNet. APIM en modo Internal solo recibe una IP privada y no puede accederse directamente desde internet, lo que lo hace adecuado para escenarios exclusivos de equipos internos.
Azure Load Balancer es un servicio de capa 4 OSI (TCP/UDP) para una única región. No dispone de enrutamiento por encabezado HTTP, WAF ni conmutación por error entre regiones. Gateway Load Balancer inserta de forma transparente NVAs de terceros en un balanceador de carga existente mediante tunelización VXLAN. Selecciónalo cuando veas la combinación de palabras clave "NVA de terceros + inserción transparente L4 + minimizar cambios en la configuración existente".
!Application Gateway vs Azure Load Balancer
Tabla comparativa de servicios
| Característica | Front Door | Traffic Manager | Application Gateway | Azure Load Balancer | |---------------|-----------|----------------|---------------------|--------------------| | Capa | L7 (HTTP/HTTPS) | Basado en DNS | L7 (HTTP/HTTPS) | L4 (TCP/UDP) | | Alcance | Global | Global | Región única | Región única | | WAF integrado | Sí | No | Sí (SKU WAF) | No | | Afinidad de sesión | Sí | No | Sí (cookies) | No | | Conmutación regional | Automática (segundos) | Basada en TTL DNS | Ninguna | Ninguna | | Caso de uso principal | App L7 global | Geo-enrutamiento DNS | L7 + WAF regional | Equilibrio L4 regional |
---
Criterios de decisión que suelen confundir a los candidatos
Cuando un único servicio debe cubrir HTTP/HTTPS global + terminación SSL + conmutación por error automática, elige Front Door. Traffic Manager no puede terminar SSL, y Application Gateway está limitado a una única región.
Cuando el requisito es enrutamiento al punto geográfico más cercano + enrutamiento por encabezado HTTP por región + WAF, elige el patrón en capas de Traffic Manager + Application Gateway WAF. Azure Load Balancer no admite encabezados HTTP ni WAF, por lo que la combinación Front Door + Load Balancer resulta insuficiente.
Cuando una aplicación local debe exponerse externamente, los servidores no deben quedar expuestos directamente y se requiere autenticación con Entra ID de forma simultánea, elige Microsoft Entra Application Proxy. Instalar únicamente un agente conector en el entorno local permite el acceso externo sin modificar ninguna regla de entrada del firewall, y el acceso condicional con MFA está disponible de forma nativa.
Cuando necesitas resolver FQDNs de Private Endpoint desde DNS local a través de ExpressRoute, combina Azure Private DNS Zone con un punto de conexión entrante de DNS Private Resolver. Configura el reenvío condicional en el servidor DNS local para el dominio apuntando a la IP del punto de conexión entrante y recibirás respuestas con IP privadas.
Cuando necesitas verificar de inmediato si un NSG está bloqueando tráfico, elige Network Watcher IP Flow Verify. Introduce la 5-tupla y obtendrás el resultado de permiso/bloqueo del NSG y el nombre de la regla correspondiente en cuestión de segundos. Los NSG Flow Logs son una herramienta de análisis agregado posterior y no son adecuados para diagnósticos inmediatos.
---
Consejos de implementación práctica
En todo escenario que involucre Private Endpoint, debes pensar también en el diseño del DNS. Crea una Azure Private DNS Zone y enlázala a la VNet para que los FQDNs se resuelvan automáticamente a IPs privadas. Al conectar App Service y SQL Database de forma privada, necesitas al menos dos subredes separadas. La subred de integración de VNet de App Service (mínimo /28) y la subred de Private Endpoint tienen funciones distintas y no pueden compartirse.
Para validar centralmente los tokens JWT en API Management, configura la política a nivel de puerta de enlace. Esto permite aplicar la validación de tokens en todas las API sin modificar el código de ninguna API de backend. Para configurar conectividad privada con servicios PaaS en Synapse Analytics, debes habilitar Managed Virtual Network al crear el área de trabajo. Esta configuración no puede modificarse después de la creación, por lo que debe decidirse en la fase de diseño.
---
Resumen
Estos son los criterios de decisión que aparecen repetidamente en las preguntas de redes del AZ-