Microsoft AZ-700: Equilibrio de Carga y Gestión de Tráfico — 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.

Servicios principales de equilibrio de carga y perimetrales de Azure

Azure proporciona varias capas diseñadas específicamente para distribuir el tráfico: Azure Load Balancer (Capa 4), Application Gateway (Capa 7), Front Door (entrega y enrutamiento perimetral global) y Traffic Manager (enrutamiento basado en DNS). Elija Azure Load Balancer Standard para escenarios de producción TCP/UDP este-oeste y norte-sur donde se requiera un alto rendimiento, redundancia de zona y un comportamiento de SNAT predecible; la SKU Basic es limitada y no se recomienda para cargas de trabajo críticas. Application Gateway v2 admite el escalado automático, la redundancia de zona, WAF (WAF_v2) y el enrutamiento nativo basado en URL y host para el tráfico HTTP/S, mientras que la v1 carece de escalado automático y tiene una sobrecarga de planificación de capacidad. Front Door (Standard/Premium) proporciona Anycast global, terminación de TLS en el perímetro, conmutación por error rápida y un motor de reglas para la modificación de encabezados y rutas; la versión Premium añade WAF avanzado y soporte para orígenes privados. Traffic Manager está basado en DNS y es útil para el enrutamiento geográfico, la conmutación por error y la distribución ponderada, pero no puede proporcionar terminación de TLS ni actuar como un proxy inverso HTTP. Al combinar servicios, envíe los activos estáticos a una CDN y use Front Door para el enrutamiento global y Application Gateway para las políticas de L7 regionales y el acceso a backends privados. Considere estas comparaciones de SKU al seleccionar componentes:

Azure Load Balancer: Basic vs Standard (elija Standard para producción: redundante entre zonas, seguro por defecto).
Application Gateway: v1 vs v2 (v2 para escalado automático, actualizaciones de WAF más rápidas).
Front Door: Standard vs Premium (Premium para WAF avanzado y private link a los orígenes).

Sondeos de estado, reglas de reescritura y comportamiento del Web Application Firewall

Los sondeos de estado y los controles de WAF son fundamentales para las operaciones resilientes de la Capa 7. Configure los sondeos de estado con puntos de conexión realistas que ejerciten la ruta de solicitud completa (incluyendo encabezados de autenticación si es necesario) y que coincidan con el comportamiento del backend; establezca el intervalo del sondeo y los umbrales de estado incorrecto para equilibrar la velocidad de detección frente a los falsos positivos. Los sondeos de estado de Application Gateway pueden anular el encabezado de host y sondear una ruta específica; asegúrese de que la configuración HTTP del backend (afinidad basada en cookies, drenaje de conexiones, tiempos de espera de inactividad) coincida con las necesidades de la aplicación. Las reglas de reescritura existen tanto en los motores de reglas de Application Gateway como de Front Door y deben usarse para normalizar encabezados, eliminar o insertar prefijos, o realizar reescrituras de URL para el enrutamiento del backend, pero recuerde que las reescrituras pueden romper las heurísticas de almacenamiento en caché y las URL firmadas. Las políticas de WAF difieren según la plataforma: el WAF de Application Gateway protege los backends regionales con reglas administradas por OWASP y exclusiones personalizadas, mientras que el WAF de Front Door Premium protege en el perímetro y admite políticas globales, protección contra bots y limitación de velocidad avanzada. Las trampas comunes incluyen sondear una página de estado estática que pasa la prueba mientras los puntos de conexión de la aplicación están fallando, olvidar permitir los rangos de IP del sondeo en los NSG y configurar incorrectamente los encabezados de host para que los backends rechacen las solicitudes del sondeo.

Gestión de tráfico global: Front Door, Traffic Manager y CDN

Front Door y Traffic Manager abordan la distribución global, pero operan de manera diferente. Front Door funciona como un proxy HTTP/S global y con estado (stateful) con terminación de TLS en el perímetro, enrutamiento inteligente (latencia, prioridad y aceleración dinámica de sitios), una capa de caché de CDN integrada y un motor de reglas para la manipulación de encabezados/rutas. Traffic Manager es un selector basado en DNS para puntos de conexión que utiliza métodos de enrutamiento como prioridad, ponderado, rendimiento y geográfico; sobresale en la conmutación por error simple y el enrutamiento por cumplimiento, pero no puede descargar TLS ni realizar reescrituras a nivel de aplicación. Azure CDN (opciones Standard Microsoft, Standard Verizon, Premium Verizon/Akamai) está optimizado para contenido estático y almacenable en caché y puede tener a Front Door por delante o usarse de forma independiente; elija la CDN Premium para motores de reglas complejos, escudo de origen (origin shield) y opciones SSL avanzadas. Para el enrutamiento multisitio, use agentes de escucha (listeners) basados en host en Application Gateway para la segregación regional y Front Door para actuar como fachada multisitio entre regiones con dominios personalizados. Tenga en cuenta que el almacenamiento en caché de DNS afecta la velocidad de conmutación por error de Traffic Manager, Front Door proporciona una conmutación por error rápida en el perímetro y la configuración del origen de la CDN debe alinearse con las estrategias de purga y TTL para evitar contenido obsoleto. Para escenarios de origen privado, Front Door Premium admite Private Link para proteger los orígenes; de lo contrario, considere usar Application Gateway en un hub regional.

Compensaciones de diseño, trampas operativas y monitorización

Las decisiones de diseño sopesan el rendimiento, el costo y la resiliencia. Priorice Front Door o CDN para la entrega global y una menor latencia para el cliente, Application Gateway para controles de políticas de L7 enriquecidos cerca del backend, y Azure Load Balancer Standard para un rendimiento bruto de TCP/UDP y un escalado predecible. Las compensaciones de costos incluyen Front Door Premium/WAF y el escalado automático de Application Gateway v2 frente a alternativas v1 de menor costo y escalado manual; equilibre el costo consolidando el enrutamiento global en el borde mientras mantiene las puertas de enlace regionales para la inspección de tráfico privado. Las trampas operativas incluyen el agotamiento de puertos SNAT cuando muchos backends inician conexiones salientes desde un pequeño conjunto de direcciones NAT; utilice NAT Gateway o ajuste la configuración de SNAT y evite el tráfico de horquilla (hairpinning) a través del mismo NAT. Otro problema común es olvidar abrir las IP de sondeo en los NSG o configurar incorrectamente los dominios y certificados personalizados para Front Door y App Gateway. Para la monitorización, habilite los registros de diagnóstico y las métricas para cada servicio (Load Balancer, App Gateway, Front Door, CDN), envíelos a Log Analytics y utilice Traffic Analytics y Connection Monitor de Network Watcher para obtener visibilidad a nivel de flujo. Configure alertas sobre fallos de sondeo, anomalías en el rendimiento del backend y detecciones del WAF, y pruebe la conmutación por error con tráfico controlado para validar los runbooks y los procedimientos de reversión.

Problema práctico: Escenario de caso de uso

Escenario: Contoso Manufacturing opera un entorno de Azure multirregional con dos hubs regionales (EastUS y WestEurope), instancias regionales de Application Gateway v2, un par de grupos de aplicaciones de escalado de VM y una CDN existente para activos estáticos. Necesitan presentar un único punto de conexión global con WAF en el borde y conmutación por error rápida, preservando al mismo tiempo la inspección regional privada.

Desafío: Proporcionar un punto de conexión HTTPS global con WAF en el borde, conmutación por error rápida entre regiones y la capacidad de enrutar el tráfico a los backends regionales de Application Gateway (que son privados) sin exponer los orígenes públicamente.

Enfoque recomendado:

Desplegar Azure Front Door Premium como el punto de entrada global (SKU: Front Door Premium) con terminación TLS, habilitar la política de WAF de Front Door (reglas personalizadas + OWASP) y configurar un grupo de backends para cada región que apunte a la IP pública de un Application Gateway v2 regional con Private Link habilitado para una conectividad segura con el origen.
Configurar el origen de Front Door como un Private Link al frontend regional del Application Gateway y establecer sondeos de estado a un punto de conexión de estado protegido que el Application Gateway expone; establecer intervalos de sondeo bajos (p. ej., 10s) y un umbral de estado incorrecto agresivo (p. ej., 3) para una conmutación por error rápida.
Mantener Application Gateway v2 en cada región para el enrutamiento L7, la reescritura de URL y las reglas de WAF locales adaptadas a las políticas regionales; habilitar el escalado automático y los registros de diagnóstico a Log Analytics.
Usar Azure CDN (Standard Microsoft) para los activos estáticos almacenables en caché, respaldado por Front Door para un control óptimo de TTL y purga; implementar monitorización y alertas sobre fallos de sondeo de Front Door y tasas de bloqueo del WAF.

Justificación: Front Door Premium proporciona WAF en el borde y conmutación por error global rápida, mientras que Private Link asegura las puertas de enlace regionales como orígenes; el Application Gateway v2 regional permite controles de L7 granulares e inspección sin exponer las VM de backend, equilibrando rendimiento, seguridad y resiliencia.

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

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