El examen AZ-700 evalúa la capacidad de decidir qué servicio de equilibrio de carga corresponde a cada capa de red. Azure Load Balancer opera en L4 y enruta el tráfico basándose únicamente en la IP y el puerto. Application Gateway opera en L7 y lee encabezados HTTP, rutas URL y cookies antes de tomar decisiones de enrutamiento. Ambos servicios tienen propósitos diferentes y con frecuencia se despliegan juntos.
Azure Load Balancer: La Cinta Clasificadora de Correos
Imagine la cinta transportadora de una oficina de correos. Una cámara lee el código postal de cada paquete y lo empuja automáticamente hacia la ranura de la región correspondiente. Nadie abre el paquete para ver qué contiene. Azure Load Balancer funciona exactamente así. Calcula un hash de cinco valores — IP de origen, puerto de origen, IP de destino, puerto de destino y protocolo (hash de 5 tuplas) — y enruta cada conexión hacia una de las VM del Backend Pool. Gestiona cualquier tráfico TCP o UDP sin importar qué contiene la carga útil.
Los cuatro componentes esenciales son , , y . La IP de Frontend es el punto de entrada al que se conectan los clientes: una IP pública para un Public Load Balancer o una IP privada dentro de la VNet para un Internal Load Balancer. El Backend Pool agrupa las VM o instancias de VM Scale Set que reciben el tráfico. Las Load Balancing Rules asignan un puerto de frontend a un puerto de backend. Los Health Probes verifican periódicamente cada VM y eliminan automáticamente las instancias no saludables.
La elección de SKU se reduce a dos opciones. Basic está diseñado para cargas de trabajo pequeñas de desarrollo y prueba, y no admite Availability Zones. Standard admite implementación con redundancia de zona, Health Probes HTTPS y HA Ports, lo que lo convierte en el estándar para producción. Cuando un escenario menciona alta disponibilidad o Availability Zones, la respuesta es Standard. HA Ports es exclusivo del Standard Internal Load Balancer: configurar el puerto en 0 hace que una sola regla cubra todos los puertos del 0 al 65535, ideal para NVA.
Application Gateway: El Mostrador de Información de un Centro Comercial
Imagine el mostrador de información en la planta baja de un gran centro comercial. Un visitante dice 'busco electrónica' y la recepcionista lo dirige al quinto piso; otra persona pregunta por la sección de alimentación y la envían al sótano. La recepcionista escucha lo que dice el cliente, no solo dónde está parado. Application Gateway funciona de la misma manera. Lee el encabezado Host de HTTP, la ruta URL, la cadena de consulta e incluso las cookies antes de decidir qué Backend Pool recibirá la solicitud.
El flujo principal es . Un Basic Listener gestiona un único dominio; un Multi-site Listener distingue varios dominios en la misma IP y enruta cada uno a un Backend Pool diferente. Las Routing Rules son de dos tipos: Basic (todas las solicitudes van a un mismo pool) o Path-based ( va al Pool A, va al Pool B).
Las opciones de SKU son Standard_v2 y WAF_v2. Standard_v2 admite Autoscale y redundancia de zona. WAF_v2 agrega capacidad de Web Application Firewall, aplicando conjuntos de reglas OWASP para bloquear inyecciones SQL, XSS y otros ataques web. Cuando el escenario requiere defensa contra ataques web, WAF_v2 es la respuesta.
Health Probe: El Portero de un Hotel
El portero de un hotel se para en la entrada y verifica periódicamente si cada habitación está lista para recibir huéspedes. Si una habitación no está disponible, redirige a los clientes a otra. Los Health Probes de Application Gateway funcionan igual: envían solicitudes HTTP o HTTPS periódicas a cada servidor del Backend Pool y verifican que la respuesta tenga un código en el rango esperado (2xx o 3xx por defecto). Si un servidor deja de responder o devuelve un código inesperado, se elimina automáticamente del pool hasta que se recupere.
Los Health Probes de Azure Load Balancer admiten los protocolos TCP, HTTP y HTTPS, con un intervalo predeterminado de 15 segundos y un umbral de dos fallos. Los Health Probes de Application Gateway permiten especificar la ruta de la solicitud y los códigos de respuesta esperados, lo que brinda un control más granular. En ambos servicios, las instancias no saludables se excluyen del tráfico y se reincorporan automáticamente una vez que superan la prueba de nuevo.
SSL Termination y End-to-End TLS
Imagine una empresa de mensajería que recibe paquetes sellados, los reempaqueta en sus propias cajas para la distribución interna y los entrega al destinatario final en nuevos empaques. El SSL Termination de Application Gateway funciona igual. El tráfico HTTPS está cifrado entre el cliente y el gateway; el gateway lo descifra y reenvía HTTP plano a las VM del backend. Esto reduce la carga de procesamiento TLS en los servidores backend y es aceptable cuando la VNet del backend es de confianza.
End-to-End TLS va un paso más allá. Tras descifrar el HTTPS del lado del cliente, Application Gateway vuelve a cifrar el tráfico y lo reenvía a los servidores backend mediante HTTPS también. Esto es obligatorio cuando las normativas exigen el cifrado de todo el tráfico, incluidas las rutas internas. Siempre que un escenario mencione 'cifrado en todo el recorrido', End-to-End TLS es la respuesta. Azure Load Balancer, al ser un dispositivo L4, no puede terminar TLS — simplemente deja pasar el tráfico del puerto 443 hacia las VM del backend.
AGIC e Integración con AKS
Imagine un robot de almacén automatizado que lee una orden de pedido y transporta los artículos a la zona de estantería correcta sin instrucciones manuales. AGIC (Application Gateway Ingress Controller) hace lo mismo para AKS (Azure Kubernetes Service). Cuando se anotan los objetos Ingress de Kubernetes con las anotaciones de AGIC, el controlador crea y actualiza automáticamente Listeners, Routing Rules y Backend Pools en Application Gateway.
Las capacidades de WAF y SSL Termination de Application Gateway se extienden directamente al Ingress de AKS sin necesidad de ejecutar un NGINX Ingress Controller separado. El Autoscale de Application Gateway también responde automáticamente al crecimiento del tráfico en el clúster. Si una pregunta del examen AZ-700 combina AKS, web application firewall e Ingress, la respuesta es AGIC con WAF_v2. La afinidad basada en cookies (Cookie-based affinity) emite una cookie de sesión para enviar siempre al mismo cliente al mismo servidor backend, útil para aplicaciones heredadas con estado de sesión local.
L4 vs L7: Criterios de Selección
Piense en la diferencia entre una cabina de peaje de autopista y el control de inmigración de un aeropuerto. La cabina de peaje lee la matrícula del vehículo y lo deja pasar en segundos. El control de inmigración abre el pasaporte, verifica el propósito del viaje y dirige al viajero hacia una puerta específica. Azure Load Balancer es la cabina de peaje; Application Gateway es el control de inmigración.
Elegir L4 (Load Balancer): cualquier protocolo TCP/UDP, sin inspección de contenido HTTP, frente a un NVA, distribución interna entre VM Elegir L7 (Application Gateway): enrutamiento por ruta URL, múltiples dominios, WAF, SSL Termination, Ingress de AKS
Las Outbound Rules de un Standard Public Load Balancer controlan explícitamente cómo usan SNAT las VM al conectarse a internet. Si los puertos SNAT predeterminados se agotan, las Outbound Rules permiten aumentar el número — esta función solo existe en Standard SKU. Las NAT Rules asignan directamente un puerto de frontend al puerto de una VM específica, útil para el acceso SSH a máquinas individuales.
!L4 vs L7: Load Balancer vs App Gateway
Patrones de Despliegue y Errores Frecuentes
Imagine un centro de distribución regional (Application Gateway) que recibe pedidos de todo el país, los clasifica por categoría de producto y los envía a los almacenes de cada tienda (Internal Load Balancer), donde se distribuyen por sección. Dos capas de distribución trabajando juntas. El mismo patrón aparece en las arquitecturas de Azure: Application Gateway (con WAF) gestiona el tráfico HTTP desde internet, mientras que un Internal Load Balancer distribuye el tráfico entre VM dentro de la VNet.
El error más común en el examen es elegir Azure Load Balancer para todos los escenarios de tráfico externo. Si el escenario requiere enrutamiento por ruta URL o un WAF, Application Gateway es la respuesta correcta. Otro error frecuente es olvidar que HA Ports es exclusivo del Standard Internal Load Balancer y no existe en el Public Load Balancer.
Resumen para el Examen
'Todos los puertos TCP/UDP, frente a un NVA' -- Azure Load Balancer Standard + HA Ports 'Enrutar por ruta URL a pools distintos' -- Application Gateway Path-based Routing 'Varios dominios en una sola IP' -- Application Gateway Multi-site Listener 'Bloquear SQL injection y XSS' -- Application Gateway WAF_v2 'AKS + Ingress + WAF' -- AGIC + WAF_v2 'Cifrado en todo el recorrido' -- Application Gateway End-to-End TLS 'Reducir la carga de TLS en el backend' -- Application Gateway SSL Termination 'Sesiones persistentes, mismo cliente al mismo servidor' -- Cookie-based affinity 'Load Balancer con redundancia de zona' -- Standard SKU 'Agotamiento de puertos SNAT, control de salida' -- Standard Load Balancer Outbound Rules 'Asignación directa de puerto a una VM específica' -- Load Balancer NAT Rules 'Regla única para todos los puertos, NVA interno' -- HA Ports (solo Standard Internal LB)
Azure Load Balancer = distribución L4 por IP y puerto, Application Gateway = enrutamiento de políticas L7 por contenido HTTP + WAF