El dominio de redes de AZ-104 (15–20 %) enumera por separado en el temario oficial "configurar direcciones IP públicas", "configurar un equilibrador de carga interno o público" y "solucionar problemas de equilibrio de carga". En nuestro banco de preguntas, casi 30 preguntas tratan sobre IP públicas y más de 20 preguntan por las SKU de Load Balancer, los sondeos de estado y la persistencia de sesión, con Application Gateway, Front Door y Traffic Manager apareciendo entre las opciones. Si memorizas cuatro servicios de equilibrio de carga con nombres parecidos sin un criterio para distinguirlos, en el examen se mezclan.
Este artículo cubre las SKU y los métodos de asignación de las IP públicas, las dos preguntas que eligen uno de los cuatro servicios de equilibrio de carga, los componentes de Azure Load Balancer y la persistencia de sesión, un orden de diagnóstico para cuando el tráfico no llega y el cambio de 2026 en cómo las VM salen a internet de forma predeterminada. Las IP públicas de SKU básica y el Load Balancer básico se retiraron el 30 de septiembre de 2025, así que lo que los materiales antiguos dicen sobre la SKU básica hay que releerlo con eso en mente.
---
Direcciones IP Públicas: Conseguir un Número que no Cambie
Si el número de teléfono principal de una empresa cambiara cada mes, tanto los clientes como los administradores del firewall de sus socios lo pasarían mal. Las direcciones IP públicas, que permiten llegar desde internet a los recursos de Azure, funcionan igual: la SKU y el método de asignación que elijas deciden si la dirección se mantiene y qué tan segura es de forma predeterminada.
| Elemento | Estándar | Básica (retirada el 30 de septiembre de 2025) | |------|------|------| | Método de asignación | Solo estática | Dinámica o estática para IPv4 | | Seguridad predeterminada | Cerrada al tráfico entrante; un NSG debe permitirlo | Abierta de forma predeterminada | | Zonas de disponibilidad | Redundante entre zonas, zonal o no zonal | No compatible | | Preferencia de enrutamiento | Compatible (red de Microsoft o enrutamiento por internet) | No compatible | | Nivel global | Compatible (front-end de un equilibrador de carga entre regiones) | No compatible |
La asignación estática asigna la dirección al crearla y la conserva hasta que eliminas el recurso de IP pública; la dinámica la libera cuando se detiene el recurso asociado En regiones con zonas de disponibilidad, una IP pública estándar creada sin zona ahora se comporta como redundante entre zonas La zona de disponibilidad de una IP pública no se puede cambiar después de crearla Cuando necesitas un intervalo contiguo de IP públicas, crea un prefijo de IP pública y asigna direcciones desde él La nueva IP pública Standard v2 por ahora solo se puede asociar a un NAT Gateway Standard v2
Consejo para el examen: "La dirección registrada en el firewall de un socio no debe cambiar aunque la VM se reinicie" pide asignación estática. La SKU estándar solo admite estática, así que elegir Estándar lo resuelve automáticamente. Si "RDP falla después de asociar una IP pública estándar", comprueba primero si un NSG tiene una regla de entrada que lo permita.
---
Elige uno de Cuatro Servicios de Equilibrio de Carga con Dos Preguntas
El mostrador de información de un aeropuerto envía a la gente a puertas de distintas plantas; el centro de llamadas de una aerolínea desvía llamadas a oficinas de todo el mundo. Ambos "reparten", pero con distinto alcance y con distinta información. Microsoft clasifica los servicios de equilibrio de carga de Azure en dos dimensiones: global o regional, y tráfico web HTTP(S) o no.
!Elige un servicio de equilibrio de carga respondiendo dos preguntas: alcance y tipo de tráfico
| Servicio | Capa | Alcance | Funciones clave | Pistas en la pregunta | |------|------|------|------|------| | Azure Load Balancer | Capa 4 (TCP, UDP) | Regional (también existe un nivel entre regiones) | Alto rendimiento, latencia ultrabaja, front-end interno o público, reglas de salida | "puerto TCP", "UDP", "equilibrio de carga interno", "todos los puertos (puertos HA)" | | Application Gateway | Capa 7 (sobre todo HTTP, HTTPS) | Regional | Enrutamiento basado en rutas de URL, terminación TLS, WAF, afinidad de sesión basada en cookies | "enviar /images al grupo A", "firewall de aplicaciones web", "descarga SSL" | | Azure Front Door | Capa 7 (HTTP, HTTPS) | Global | Perímetro mundial, almacenamiento en caché (CDN), conmutación por error rápida, WAF | "usuarios de todo el mundo", "perímetro más cercano", "almacenar en caché contenido estático" | | Traffic Manager | Basado en DNS | Global | Elige un punto de conexión regional mediante respuestas DNS; enrutamiento por prioridad, rendimiento o geográfico | "en el nivel de DNS", "conmutación por error entre regiones para servicios que no son HTTP" |
Traffic Manager solo dirige el tráfico en el paso de DNS, así que los clientes pasan a otra región solo cuando caduca su caché de DNS. Por eso Front Door encaja mejor para una conmutación por error rápida entre regiones de aplicaciones web.
Consejo para el examen: En el temario de AZ-104 solo aparece por su nombre Load Balancer, pero los otros tres suelen colarse como opciones incorrectas. "Ruta de URL", "WAF" o "afinidad basada en cookies" indican un servicio de capa 7; "TCP/UDP" o "repartir sobre una IP interna" indican Load Balancer.
---
Los Componentes de Azure Load Balancer, de Nuevo
Un equilibrador de carga es un agente de tráfico que recibe las conexiones entrantes y las entrega a las VM de back-end según unas reglas. Un equilibrador de carga público recibe tráfico de internet en una IP pública, y uno interno recibe tráfico interno en una IP privada de la VNet.
| Componente | Función | Qué recordar | |------|------|------| | Configuración de IP de front-end | La dirección a la que se conectan los clientes | Un LB público necesita una IP pública estándar | | Grupo de back-end | VM o instancias de conjuntos de escalado que reciben el tráfico | Se configura por NIC o por dirección IP | | Sondeo de estado | Comprueba periódicamente si un back-end está en buen estado | TCP, HTTP, HTTPS; la IP de origen es 168.63.129.16 | | Regla de equilibrio de carga | Reparte un puerto de front-end a un puerto de back-end | Siempre requiere un sondeo de estado | | Regla NAT de entrada | Reenvía un puerto concreto a una VM concreta | Por ejemplo, front-end 50001 → puerto 3389 de VM1; no necesita sondeo | | Regla de salida | Configura SNAT para que las VM de back-end salgan a internet | Se usa con un LB estándar público |
Standard Load Balancer es "seguro de forma predeterminada". El tráfico entrante no fluye a menos que un NSG en la subred o NIC de back-end lo permita. En un Standard Load Balancer interno, una regla de puertos HA (protocolo Todos, puerto 0) reparte los flujos TCP y UDP de todos los puertos a la vez, por eso suele colocarse delante de aplicaciones virtuales de red (NVA) como firewalls.
Persistencia de Sesión: Mantener a un Usuario en la Misma VM
| Configuración | Hash basado en | Comportamiento | |------|------|------| | Ninguna (predeterminada) | Tupla de 5 (IP de origen, puerto de origen, IP de destino, puerto de destino, protocolo) | Incluso el mismo cliente puede ir a otra VM en cada conexión | | IP de cliente | Tupla de 2 (IP de origen, IP de destino) | La misma IP de cliente va a la misma VM | | IP de cliente y protocolo | Tupla de 3 (IP de origen, IP de destino, protocolo) | La misma combinación de IP de cliente y protocolo va a la misma VM |
Consejo para el examen: "Los datos de sesión están en la memoria de la VM, así que un usuario debe seguir conectándose a la misma VM" significa cambiar la persistencia de sesión a IP de cliente. La afinidad basada en cookies es una función de Application Gateway, no de Load Balancer.
---
Cuando el Tráfico no Llega al Back-End
La mayoría de los problemas de equilibrio de carga se dividen en dos ramas: "el sondeo de estado falla" o "el sondeo está bien, pero los datos no pasan". Esto es lo que hay que revisar para cada síntoma.
| Síntoma | Causa habitual | Qué revisar | |------|------|------| | Las VM de back-end no responden al sondeo de estado | La aplicación no escucha en el puerto del sondeo, o la VM está detenida | Si el puerto del sondeo escucha dentro de la VM, el estado de la VM | | El sondeo de estado está bloqueado | Un NSG o el firewall de la VM bloquea 168.63.129.16 o la etiqueta de servicio AzureLoadBalancer | Reglas de denegación evaluadas antes de la regla predeterminada AllowAzureLoadBalancerInBound | | El sondeo está bien pero el puerto del servicio no responde | La aplicación no escucha en el puerto de datos, o un NSG lo bloquea | El puerto de back-end de la regla de equilibrio, las reglas de entrada del NSG | | Fallan las solicitudes de una VM de back-end al front-end del LB interno | No se admiten flujos de una VM de back-end hacia el front-end del mismo LB interno | Probar desde otra VM o cambiar el diseño | | El tráfico entrante se corta tras pasar a Estándar | Estándar bloquea el tráfico entrante de forma predeterminada | Agregar una regla de NSG que permita el tráfico en la subred o NIC de back-end |
Para ver el estado en números, revisa juntas dos métricas de Load Balancer: Disponibilidad de la ruta de acceso de datos (el camino hasta el front-end) y Estado del sondeo de estado (resultado del sondeo por instancia de back-end). Si la ruta de datos está bien y solo el estado del sondeo es 0, el problema está en las VM de back-end.
Consejo para el examen: Si "todas las VM pasan a estar en mal estado después de cambiar el sondeo a HTTP /health", la aplicación no tiene la ruta /health o no devuelve 200. Un sondeo HTTP solo considera correcta una respuesta 200.
---
Salida a Internet de las VM: Ahora se Elige de Forma Explícita
Hasta ahora, incluso una VM sin IP pública podía salir a internet mediante una dirección de "acceso de salida