Introducción
En el diseño de infraestructuras críticas en la nube, la alta disponibilidad y la seguridad no son opcionales, son la norma. El Azure Load Balancer Standard se posiciona como una pieza fundamental para lograr este objetivo. Al operar en la Capa 4 del modelo OSI (TCP/UDP), este servicio permite distribuir el tráfico entrante entre múltiples servidores, garantizando que tus aplicaciones escalen de manera eficiente y resistan fallos individuales con una latencia ultrabaja.
Sin embargo, el verdadero reto técnico hoy en día no es solo equilibrar el tráfico, sino hacerlo de forma segura. En este tutorial, resolveremos el problema de la exposición innecesaria a internet aplicando una filosofía de arquitectura “Zero Trust” (Confianza Cero).
A lo largo de este artículo, utilizaremos exclusivamente la línea de comandos para automatizar la creación de nuestro entorno. Aprenderás el “porqué” detrás de cada configuración, desde la segmentación de redes hasta el bloqueo estricto del tráfico saliente, logrando un despliegue digno de un entorno de producción.
Requisitos Previos
Para seguir este tutorial y ejecutar los comandos con éxito, asegúrate de tener tu entorno local preparado con lo siguiente:
- Visual Studio Code: Será nuestro editor de código principal.
- Azure CLI: Debes tener instalada la interfaz de línea de comandos de Azure en tu sistema operativo (Windows, macOS o una distribución de Linux como Ubuntu).
- Extensiones de VS Code: Instala la extensión oficial Azure Account y Azure CLI Tools para facilitar la autenticación y el autocompletado.
- Cuenta de Azure Activa: Necesitarás permisos suficientes (como Contributor) para crear recursos de red y cómputo.
- Autenticación previa en tu terminal ejecutando el comando
az login.
Documentacion oficial Azure CLI
https://learn.microsoft.com/es-es/cli/azure/?view=azure-cli-latest
Repositorio de GitHub
https://github.com/DavidGonzalezCloud/azure-cli-journey.git
Paso a Paso: Construyendo el Azure Load Balancer Standard
El funcionamiento de este servicio se basa en cuatro componentes vitales: el Frontend IP (la cara pública), el Backend Pool (donde viven los servidores), el Health Probe (que monitorea la salud de las instancias, por ejemplo, en el puerto 80) y la Regla de Balanceo (que dicta cómo fluye el tráfico).
Vamos a construir esta arquitectura fase por fase. Puedes guardar todos los comandos en un archivo llamado deploy_alb.sh dentro de tu VS Code.
Fase A: Preparación y Puerta Frontal
Todo recurso en Azure necesita un contenedor lógico. Comenzaremos creando nuestro Grupo de Recursos y la dirección IP Pública. Es imperativo que el SKU de la IP sea Standard y su método de asignación Static, ya que un balanceador Standard requiere una IP de su mismo nivel.
# Archivo: deploy_alb.sh
# Variables base
RG_NAME="rg-estudio-alb"
LOCATION="eastus"
PIP_NAME="pip-frontend-alb"
# 1. Crear el Grupo de Recursos
az group create --name $RG_NAME --location $LOCATION
# 2. Crear la IP Pública (Standard / Static)
az network public-ip create \
--resource-group $RG_NAME \
--name $PIP_NAME \
--sku Standard \
--allocation-method StaticBash
Fase B: El “Cascarón” y el Cerebro del Balanceador
Aquí es donde definimos la inteligencia del balanceador. Creamos la estructura principal, el sondeo de salud que verificará que nuestros servidores web respondan, y la regla de balanceo.
Atención a la seguridad: En el paso 5, utilizamos el parámetro --disable-outbound-snat true. En una arquitectura Zero Trust, esto es crucial. Evita que las máquinas virtuales utilicen la IP pública del balanceador para navegar por internet. Si tus servidores necesitan salida a internet, lo correcto es configurar un Azure NAT Gateway dedicado, separando así el tráfico de entrada del de salida.
# Variables del ALB
ALB_NAME="alb-estudio-standard"
FRONTEND_NAME="FrontendIP"
BACKEND_POOL_NAME="BackendPool-Web"
PROBE_NAME="probe-http"
RULE_NAME="rule-http"
# 3. Crear el Load Balancer
az network lb create \
--resource-group $RG_NAME \
--name $ALB_NAME \
--sku Standard \
--public-ip-address $PIP_NAME \
--frontend-ip-name $FRONTEND_NAME \
--backend-pool-name $BACKEND_POOL_NAME
# 4. Crear el Sondeo de Salud (Puerto 80)
az network lb probe create \
--resource-group $RG_NAME \
--lb-name $ALB_NAME \
--name $PROBE_NAME \
--protocol tcp \
--port 80
# 5. Crear la Regla de Balanceo (Bloqueando SNAT de salida)
az network lb rule create \
--resource-group $RG_NAME \
--lb-name $ALB_NAME \
--name $RULE_NAME \
--protocol tcp \
--frontend-port 80 \
--backend-port 80 \
--frontend-ip-name $FRONTEND_NAME \
--backend-pool-name $BACKEND_POOL_NAME \
--probe-name $PROBE_NAME \
--disable-outbound-snat trueBash
Redes y Asociación Modular (“Brownfield”)
En un entorno de producción (“Brownfield”), las cosas no se crean monolíticamente. A menudo, el equipo de redes crea la infraestructura base y el equipo de sistemas despliega los servidores. Para simular esto, crearemos la Red Virtual (VNet) y las Tarjetas de Interfaz de Red (NICs) de forma aislada. Luego, actualizaremos las NICs para unirlas al Backend Pool del balanceador.
# Variables de Red
VNET_NAME="vnet-estudio-alb"
SUBNET_NAME="snet-web"
# 6. Crear la Red Virtual y Subred
az network vnet create \
--resource-group $RG_NAME \
--name $VNET_NAME \
--address-prefix 10.0.0.0/16 \
--subnet-name $SUBNET_NAME \
--subnet-prefix 10.0.1.0/24
# 7. Crear las NICs aisladas (Bucle)
for i in 1 2; do
az network nic create \
--resource-group $RG_NAME \
--name nic-web-0$i \
--vnet-name $VNET_NAME \
--subnet $SUBNET_NAME
done
# 8. Unir las NICs al Backend Pool del Load Balancer
for i in 1 2; do
az network nic ip-config update \
--resource-group $RG_NAME \
--nic-name nic-web-0$i \
--name ipconfig1 \
--lb-name $ALB_NAME \
--lb-address-pools $BACKEND_POOL_NAME
doneBash
Fase D: Seguridad (NSG) y Cómputo
A diferencia de la versión Basic, el SKU Standard de Azure está cerrado por defecto (“Secure by Default”). Ningún tráfico pasará hacia los servidores a menos que lo autoricemos explícitamente mediante un Network Security Group (NSG). Una vez creada la regla para el puerto 80, asociaremos el NSG a la subred entera y desplegaremos las máquinas virtuales conectándolas a las NICs que preparamos en la fase anterior.
NSG_NAME="nsg-web"
# 9. Crear el NSG y regla para el Puerto 80
az network nsg create --resource-group $RG_NAME --name $NSG_NAME
az network nsg rule create \
--resource-group $RG_NAME \
--nsg-name $NSG_NAME \
--name Allow-HTTP \
--protocol tcp \
--direction Inbound \
--priority 100 \
--source-address-prefix Internet \
--source-port-range "*" \
--destination-address-prefix "*" \
--destination-port-range 80 \
--access Allow
# 10. Asociar el NSG a la Subred completa
az network vnet subnet update \
--resource-group $RG_NAME \
--vnet-name $VNET_NAME \
--name $SUBNET_NAME \
--network-security-group $NSG_NAME
# 11. Crear las Máquinas Virtuales (Conectadas a las NICs preparadas)
for i in 1 2; do
az vm create \
--resource-group $RG_NAME \
--name vm-web-0$i \
--nics nic-web-0$i \
--image Ubuntu2204 \
--size Standard_B1s \
--admin-username azureuser \
--generate-ssh-keys \
--no-wait
doneBash
Fase E: Auditoría Final
Finalmente, como buenos Cloud Engineers, no asumimos que algo funciona; lo verificamos. Usaremos un query en Azure CLI para consultar el registro interno del balanceador y confirmar que las IPs privadas de nuestras máquinas están correctamente registradas en el Backend Pool.
# 12. Verificar las configuraciones IP en el Backend Pool
az network lb address-pool show \
--resource-group $RG_NAME \
--lb-name $ALB_NAME \
--name $BACKEND_POOL_NAME \
--query "loadBalancerBackendAddresses[].{Name:name, IPAddress:ipAddress, Subnet:subnet.id}" \
--output tableBashLista de recursos creados

Ahora hay que limpiar todos los recursos, para esto vamos a borrar el grupo de recurso para que se eliminen todos los recursos creados en este tutorial y evitar gastos no deseados.
az group delete \
--name rg-estudio-alb \
--yes \
--no-waitBash
Conclusión
¡Felicidades! Acabas de desplegar una infraestructura de alta disponibilidad utilizando principios de seguridad modernos. Has logrado construir un Azure Load Balancer Standard desde cero mediante CLI, aplicando separación de responsabilidades en la red y garantizando una arquitectura Zero Trust al bloquear el tráfico SNAT saliente. Te animo a que modifiques el script, pruebes agregando más servidores al bucle o experimentes instalando un servidor web como Nginx mediante extensiones de VM para ver el balanceo en vivo.
¿Te quedó alguna duda sobre la deshabilitación del SNAT o cómo escalar este script? ¡Déjame tus preguntas en los comentarios y sigamos la conversación!