Microsoft AZ-104: Equilibrio de carga de Azure y Gestión del tráfico — Guía de estudio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

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

Descripción general

Azure ofrece un portafolio por capas para distribuir y proteger el tráfico: Azure Load Balancer (Capa 4, TCP/UDP), Application Gateway (Capa 7, HTTP/S), Azure Front Door (perímetro global de Capa 7), Azure Traffic Manager (basado en DNS) y Azure CDN (almacenamiento en caché perimetral). Cada uno se enfoca en un segmento específico de la ruta de la solicitud, desde la toma de decisiones de DNS global y los POP perimetrales hasta el enrutamiento HTTP regional y el tráfico privado este-oeste. El dominio se logra seleccionando el servicio adecuado para el protocolo y la audiencia, componiéndolos correctamente y configurando sondeos de estado y reglas que impulsen una conmutación por error confiable.

Azure Load Balancer (L4): SKU, componentes básicos, NAT/salida e IP flotante

Standard Load Balancer es el balanceador de carga de Capa 4 de nivel de producción. Es consciente de la zona y con redundancia de zona, admite HA Ports, diagnósticos y métricas avanzados, es seguro por defecto (sin entrada a menos que defina reglas), tiene reglas de salida configurables y una gran escala de backend. Basic es un SKU heredado con escala y características limitadas y sin redundancia de zona; está en proceso de retirada y no debe elegirse para nuevas cargas de trabajo.

Los componentes principales definen cómo fluye el tráfico:

IP de frontend: La VIP expuesta a los clientes. Los LB externos usan una Public IP o un Public IP Prefix; los LB internos usan una IP estática privada de una subred. Standard admite múltiples frontends e IP públicas con redundancia de zona.
Grupo de backend: NIC, configuraciones IP en las NIC o instancias de VM scale set en la misma región/VNet. Un único grupo puede servir a muchas reglas. Standard admite backends entre zonas dentro de una región.
Sondeos de estado: Determinan qué instancias de backend están en buen estado. Los sondeos TCP completan un handshake; los sondeos HTTP/HTTPS realizan un GET a una ruta y consideran 200–399 como éxito. Usted controla el protocolo, el puerto, la ruta (para HTTP/S), el intervalo y el umbral de mal estado (fallos consecutivos antes de marcarlo como inactivo).
Reglas de balanceo de carga: Vinculan un frontend (IP/puerto/protocolo) a un grupo de backend y un sondeo de estado. La configuración de la regla incluye el puerto de backend, el protocolo (TCP/UDP), la persistencia de la sesión, el tiempo de espera de inactividad y la Floating IP (Direct Server Return).

Las reglas de NAT de entrada son traducciones por VM que reenvían un puerto de frontend específico a una única NIC/puerto de backend (por ejemplo, para exponer RDP o SSH a una VM sin balanceo de carga). No utilizan el sondeo de estado y no son un mecanismo de escalado horizontal.

Las reglas de salida definen el comportamiento de SNAT para los backends de Standard Load Balancer que inician conexiones a Internet a través de los frontends públicos del LB. Le permiten controlar qué frontend(s) suministran puertos SNAT y cuántos puertos se asignan por instancia de backend, ayudando a evitar el agotamiento de puertos SNAT bajo alta concurrencia de salida. Si se adjunta un NAT Gateway a la subred, este reemplaza al SNAT del LB; prefiera NAT Gateway para una salida consistente y escalable.

Floating IP (Direct Server Return) es una opción de regla que se utiliza cuando la IP/puerto de destino debe preservarse de extremo a extremo. Es necesaria para escenarios en clúster como los listeners de grupos de disponibilidad SQL Server Always On. Para un SQL AG, use un Standard Load Balancer interno con un sondeo TCP (no HTTP) al puerto de sondeo del clúster y habilite Floating IP en la regla del LB; no sondee el puerto 1433 con HTTP, ya que SQL no es una carga de trabajo HTTP.

La elección entre balanceadores de carga internos y externos depende de la audiencia y del límite de seguridad. Use un LB interno al exponer una VIP privada dentro de una VNet o a través de conectividad privada (VPN/ExpressRoute) para aplicaciones de línea de negocio, bases de datos y NVA. Use un LB externo para servicios de Capa 4 orientados a Internet. Para los LB internos, asigne un frontend privado estático en la subred de destino; para los LB externos, vincule una Standard Public IP y, opcionalmente, use múltiples frontends.

Cross-region Load Balancer proporciona un balanceo de carga de Capa 4 global y anycast entre regiones. Usted despliega Standard Public Load Balancers en cada región (nivel regional) y coloca sus frontends públicos en el backend de un único Load Balancer global (nivel global). El LB global utiliza sondeos de estado para cada LB regional y dirige a los clientes a la región saludable más cercana (por latencia) con simetría de flujo basada en hashing de 5 tuplas. Es solo TCP/UDP —sin terminación TLS— y complementa a las puertas de enlace L7 regionales.

Application Gateway (Capa 7) y Azure Front Door (Capa 7 global)

Application Gateway es un proxy inverso regional de Capa 7 con WAF. Termina las conexiones HTTP/HTTPS, inspecciona encabezados y rutas, y enruta hacia backends privados o públicos.

Componentes clave de Application Gateway:

Listeners: Vinculan una IP/puerto/nombre de host de frontend y la configuración SSL para aceptar tráfico. SNI permite múltiples sitios TLS por IP. Use listeners básicos para un solo sitio, listeners multisitio para enrutamiento basado en host y hosts con comodines para una cobertura amplia.
Reglas de enrutamiento y configuración HTTP: Las reglas asignan listeners a grupos de backend y especifican la configuración HTTP que se aplica a los backends (protocolo, puerto, sustitución del encabezado Host, afinidad basada en cookies, drenaje de conexiones, tiempo de espera de la solicitud). Puede redirigir, reescribir encabezados o enrutar según segmentos de la ruta de la URL.
Grupos de backend: Los destinos pueden ser IP de NIC, FQDN, App Services o VM Scale Sets. Los sondeos de estado personalizados verifican rutas/hosts específicos y respetan los códigos de estado de éxito.
WAF: Protección basada en el Core Rule Set de OWASP en modo de detección o prevención con reglas personalizadas, listas de exclusión y asociación por ruta en la v2. El escalado automático y la redundancia de zona son compatibles con la v2.

Patrones avanzados de Capa 7:

Enrutamiento basado en la ruta de la URL: Enrute /api/* a microservicios y /images/* a un origen estático o CDN, permitiendo una distribución en abanico (fan-out) a microservicios detrás de una única VIP.
Alojamiento de múltiples sitios: Aloje contoso.com y fabrikam.com en un solo gateway usando listeners SNI y reglas basadas en el encabezado Host. Útil para la consolidación con un fuerte aislamiento mediante políticas de WAF por sitio.
Terminación SSL: Descargue la gestión de TLS en el gateway para una administración centralizada de certificados y la inspección del WAF. Use TLS de extremo a extremo (recifrado) cuando los backends requieran cifrado o validación de certificados de cliente.

Azure Front Door proporciona balanceo de carga HTTP/HTTPS global y aceleración en el borde con anycast, TCP dividido y optimización de POP a origen. Es ideal para aplicaciones orientadas a Internet que requieren enrutamiento global, WAF en el borde y almacenamiento en caché opcional en el borde.

Balanceo de carga global: Enruta a los usuarios al origen saludable con la latencia más baja utilizando sondeos de estado desde múltiples POP. Los grupos de origen admiten la conmutación por error (failover) basada en prioridad y latencia, con afinidad de sesión si es necesario.
WAF: Reglas administradas con protección contra bots, reglas personalizadas, filtros geográficos/de IP, limitación de velocidad (rate limiting) y asociación por ruta.
Almacenamiento en caché: Con Front Door Standard/Premium, el almacenamiento en caché en el borde está integrado; defina el comportamiento del caché por ruta, controle el almacenamiento en caché de la cadena de consulta y los TTL, y descargue contenido estático globalmente.
Sondeos de estado: Sondeos por grupo de origen (HTTP/HTTPS) con ruta, intervalo y protocolo configurables desde diversos POP. Las decisiones de enrutamiento combinan el estado y la latencia.

Use Application Gateway para necesidades regionales de Capa 7 (backends privados, tráfico este-oeste, reescrituras complejas) y Azure Front Door para Capa 7 global, seguridad en el borde y aceleración. Comúnmente se componen juntos: Azure Front Door en el borde, Application Gateways por región y balanceadores de carga internos detrás de los gateways para servicios de Capa 4.

Traffic Manager (basado en DNS) y Azure CDN

Traffic Manager es un servicio de distribución de tráfico global basado en DNS. No actúa como proxy para el tráfico; en su lugar, devuelve el nombre DNS/IP de un punto de conexión según una política y su estado de salud, dejando que los clientes se conecten directamente. El estado se comprueba desde sondeos distribuidos a puntos de conexión HTTP/HTTPS/TCP; los TTL bajos reducen la latencia de conmutación por error, pero aumentan el volumen de consultas DNS.

Prioridad: Conmutación por error activa/pasiva. Coloque el principal primero; Traffic Manager lo sirve a menos que no esté saludable, y entonces conmuta al de la siguiente prioridad.
Ponderado: Distribuir por pesos para soportar transiciones graduales o pruebas A/B.
Rendimiento: Elegir el punto de conexión con la latencia de red más baja desde la región del usuario hasta el punto de conexión.
Geográfico: Enrutar según la ubicación geográfica del usuario para soberanía de datos o localización de contenido.
Multivalor: Devolver múltiples puntos de conexión saludables para el mismo servicio para soportar una conmutación por error simple del lado del cliente. Puede anidar perfiles para políticas híbridas (p. ej., geográfico en el nivel superior, luego ponderado dentro de una geografía). Use Traffic Manager para protocolos no HTTP, servicios que no se benefician de un proxy en el borde, o cuando necesite control a nivel de DNS sobre puntos de conexión heterogéneos (Azure, locales, de terceros).

Azure CDN descarga contenido estático y almacenable en caché a los POP en el borde para reducir la carga en el origen y la latencia.

Perfiles: Contenedores para uno o más puntos de conexión vinculados a un proveedor/nivel (por ejemplo, las familias de Microsoft, Akamai o Verizon). Los perfiles ayudan a separar entornos o centros de costos.
Puntos de conexión: Definen los detalles del origen (nombre de host, encabezado Host de origen, protocolo/puerto) y el nombre de host del borde. Puede tener múltiples puntos de conexión por perfil para diferentes aplicaciones o tipos de contenido.
Reglas de caché: Las reglas predeterminadas y personalizadas controlan los TTL, el comportamiento basado en la ruta, el manejo de la cadena de consulta (reenviar, ignorar o almacenar en caché cada consulta única) y la compresión. Use reglas para forzar el almacenamiento en caché de activos con TTL de origen cortos, o para omitir el caché para API dinámicas.
Dominios personalizados: Asigne nombres de host amigables con TLS administrado por la CDN. Valide la propiedad del dominio mediante CNAME y habilite HTTPS con certificados administrados. Combine con filtrado geográfico (geo-filtering) o el motor de reglas (rules engine) según sea necesario.

Decisiones de diseño, integración entre regiones y comportamiento de los sondeos de estado

Los balanceadores de carga internos frente a los externos se eligen según la audiencia y la exposición de la ruta. Si los consumidores están solo dentro de redes privadas, use LBs internos para evitar la exposición pública y simplificar el control de los NSG. Para usuarios de internet o socios, use frontends públicos. Para la conectividad de salida a escala, prefiera NAT Gateway en lugar de SNAT del LB; reserve las reglas de salida para casos en los que el frontend del LB deba proporcionar SNAT.

Cross-region Load Balancer se integra con los Standard Public Load Balancers regionales para lograr una resiliencia global de Capa 4 activa-activa para servicios TCP/UDP. Coloque los frontends públicos de los LBs regionales en el conjunto de back-end del LB global. Los sondeos de estado en el nivel global reflejan la disponibilidad regional; el enrutamiento dirige el tráfico a la región saludable con la latencia más baja y realiza una conmutación por error automática si una región completa (o su LB regional) deja de estar saludable. Combine esto con Front Door cuando necesite soporte para ambos protocolos (p. ej., servicios TCP a través del LB entre regiones y HTTP/S a través de Front Door) bajo VIPs separadas.

Los sondeos de estado son la fuente de verdad para la conmutación por error:

Sondeos TCP: Funcionan para cualquier servicio TCP. Un handshake de 3 vías completado marca el éxito. Adecuado para SQL, SMTP o protocolos TCP personalizados.
Sondeos HTTP/HTTPS: Validan el estado a nivel de aplicación solicitando una ruta y esperando una respuesta 200–399. Permiten la personalización de host/ruta y pueden discriminar fallos parciales de la aplicación. Los sondeos HTTPS verifican la negociación TLS pero no la validez del certificado más allá del handshake; use las cabeceras de host correctas para aplicaciones alojadas virtualmente.
Umbrales de estado no saludable: Azure Load Balancer marca un back-end como inactivo después de N fallos consecutivos del sondeo (configurable; los intervalos predeterminados son cortos para acelerar la conmutación por error). Application Gateway y Front Door sondean desde múltiples puntos de observación y consideran un origen como inactivo cuando se acumulan suficientes fallos consecutivos en su conjunto de sondeos. La recuperación requiere éxitos consecutivos. Ajuste el intervalo y el umbral para equilibrar la sensibilidad y la inestabilidad (flapping); asegúrese de que los sondeos lleguen a un punto de conexión ligero y consciente de las dependencias.

Escenario de un problema práctico

Adobe necesita exponer globalmente una SaaS multirregional compuesta por front-ends web, microservicios y un grupo de disponibilidad Always On de SQL Server, con seguridad estricta, conmutación por error rápida y baja latencia para usuarios de todo el mundo. También exponen un servicio heredado de ingesta de telemetría basado en TCP.

Colocar Azure Front Door Standard en el borde (edge) con una política de WAF y rutas para www.adobe.com y api.adobe.com. Los orígenes son Application Gateways en East US y West Europe, agrupados con enrutamiento basado en latencia y conmutación por error por prioridad.

Por qué: Front Door proporciona anycast global, WAF en el borde y almacenamiento en caché opcional para acelerar y proteger el tráfico HTTP/S de internet; elige automáticamente la región saludable más cercana.

Desplegar Application Gateway v2 con WAF en cada región. Configurar listeners multi-sitio con SNI para ambos nombres de host, enrutamiento basado en la ruta del URL hacia los microservicios y sondeos de estado personalizados a /healthz en cada servicio. Habilitar SSL de extremo a extremo con anulación del host de back-end a los FQDN del servicio.

Por qué: Application Gateway ofrece enrutamiento L7 regional, inspección WAF cerca de la aplicación, distribución basada en rutas (fanout) y políticas por ruta; se conecta de forma segura a los back-ends privados y gestiona reescrituras/redirecciones de cabeceras.

Desplegar un Standard Load Balancer interno en cada región para el listener del AG de SQL. Configurar un frontend privado estático, un sondeo de estado TCP al puerto de sondeo del Windows Failover Cluster y una regla de equilibrio de carga con IP flotante (Floating IP) habilitada para el puerto del listener.

Por qué: El listener de SQL requiere L4 con retorno directo del servidor. La IP flotante preserva la semántica del destino, y un sondeo TCP refleja con precisión la propiedad del AG. Esto refleja el requisito conocido de que el sondeo HTTP en el puerto 1433 no es válido.

Respaldar los activos estáticos web con reglas de caché de Azure Front Door para /static/* con un TTL largo y revalidación, y también establecer un perfil y un punto de conexión de Azure CDN para descargas de medios grandes en downloads.adobe.com con almacenamiento en caché específico de la ruta y variación por cadena de consulta (query-string).

Por qué: El almacenamiento en caché de Front Door reduce la latencia para el contenido estático web principal en línea con el enrutamiento de borde, mientras que un punto de conexión de CDN dedicado optimiza la entrega de objetos grandes y la independencia de la política de caché para las descargas.

Publicar la ingesta de telemetría TCP heredada a través de un Standard Public Load Balancer regional en cada región, y luego ponerlos detrás de un Cross-region Load Balancer como la única VIP pública. Configurar sondeos globales para cada LB regional y usar enrutamiento por latencia.

Por qué: El servicio es TCP, no HTTP; Cross-region Load Balancer ofrece L4 global activo-activo con conmutación por error automática y selección de región de baja latencia.

Añadir Azure Traffic Manager con una política de Prioridad solo para un punto de conexión SFTP de un socio externo alojado fuera de Azure, listando el punto de conexión principal del socio y uno de respaldo alojado en Azure.

Por qué: Traffic Manager se basa en DNS y puede incluir puntos de conexión externos; ofrece una conmutación por error activa/pasiva simple para destinos que no son HTTP y de terceros donde no se desea el uso de un proxy.

Para la conectividad de salida desde las subredes de la aplicación, adjuntar un NAT Gateway y eliminar la dependencia del SNAT de salida del LB. Monitorear los resultados de los sondeos y las métricas de LB/App Gateway/Front Door en Azure Monitor y ajustar los intervalos de sondeo/umbrales de estado no saludable para eliminar la inestabilidad (flapping).

Por qué: NAT Gateway escala la salida de manera fiable sin el agotamiento de puertos SNAT; el ajuste preciso de los sondeos de estado produce un comportamiento de conmutación por error más rápido y estable en todas las capas.

← Redes virtuales de Azure · Todos los dominios · Almacenamiento de Azure →

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