AZURE NETWORKING / LAB-002

Application Gateway con dos servidores IIS

Adaptación de Bicep a una red existente, selección de tamaño de VM y validación de dos servidores web detrás de un único punto de entrada.

AZ-700 · M528 de septiembre de 2026Evidencia histórica recuperada

Resultado documentado: Ambos backends aparecen Healthy con HTTP 200. Las capturas posteriores muestran respuestas de BackendVM1 y BackendVM2. No se realizó una prueba de caída.

01 / Arquitectura y objetivo

El laboratorio M5 se retomó con ContosoVnet, sus subredes y ContosoAppGateway ya desplegados. El objetivo era incorporar dos VM con IIS sin gestionar nuevamente la configuración de esa red.

Cliente HTTP → frontend público → ContosoAppGateway
ContosoVnet
  AGSubnet → Application Gateway → listener / regla → BackendPool
  BackendSubnet
    ├─ BackendVM1 · 10.0.1.4 · IIS :80
    └─ BackendVM2 · 10.0.1.5 · IIS :80

El cliente accedía a una única IP pública del Gateway. Los destinos registrados en el pool eran las IP privadas de las VM. Las direcciones del diagrama son las del laboratorio histórico; no son endpoints actuales para probar.

02 / Adaptaciones y decisiones

Reutilizar la red con existing

Se conservaron los originales y se creó main.Juan-existing-network.bicep. La VNet y BackendSubnet se declararon como recursos existing, y las NIC utilizaron backendSubnet.id. El archivo corregido mantiene dos VM, dos NIC y dos extensiones IIS; no declara un nuevo Application Gateway.

Adaptar el tamaño a las restricciones disponibles

El archivo de parámetros corregido usa Standard_D2s_v7, admitido por la plantilla, en lugar de D2s_v5. El historial documenta la elección ante las restricciones de SKU/cuota del entorno. Esto no significa que todas las cuentas Free tengan la misma cuota ni que ese tamaño esté disponible hoy.

Validar antes de desplegar

El historial registra compilación, validación en Cloud Shell y un What-If de seis creaciones y tres recursos ignorados, sin modificaciones ni eliminaciones. Después de la autorización se registró un despliegue incremental satisfactorio. Son resultados históricos del chat, no una ejecución nueva durante esta recuperación.

Registrar explícitamente los destinos

Tras crear las VM, el BackendPool no tenía destinos. Se añadieron 10.0.1.4 y 10.0.1.5. Crear una VM dentro de la VNet no la incorpora automáticamente al pool.

Fragmento recuperado de la plantilla corregida

resource vnet 'Microsoft.Network/virtualNetworks@2020-06-01' existing = {
  name: virtualNetworkName
}
resource backendSubnet 'Microsoft.Network/virtualNetworks/subnets@2020-06-01' existing = {
  parent: vnet
  name: subnet2Name
}
// NIC subnet reference:
// id: backendSubnet.id

Extracto explicativo verificado contra el archivo local. No es una plantilla completa ni incluye credenciales.

03 / Validación y resultados

Qué demuestra cada comprobación
Comprobación	Resultado registrado	Límite
Referencia de red	existing en VNet y subred	Comprobado en el archivo local; no consulta el estado actual de Azure.
Despliegue	Succeeded según el historial del chat	No se presenta como una nueva prueba ni como evidencia de recursos actualmente activos.
Salud de backend	2/2 Healthy; HTTP 200; puerto 80	Captura original E01: conectividad y respuesta del servicio en ese momento.
Acceso a la aplicación	BackendVM2 y BackendVM1	E02/E03 muestran ambos nombres; no prueban reparto 50/50 ni failover.

04 / Evidencias originales

Capturas enviadas durante el laboratorio y recuperadas del historial local. Las copias se recortaron con autorización para excluir datos personales e interfaz ajena al resultado. No se reconstruyeron ni generaron con IA. Se conservan los originales y el registro de procedencia. Las capturas mantienen su idioma original.

E01 · Dos destinos Healthy; ambos recibieron código 200 por HTTP/80. Se excluyó la cabecera de cuenta.

E02 · Respuesta histórica BackendVM2. El recorte conserva el cuerpo; la URL original queda fuera de la copia pública.

E03 · Respuesta histórica BackendVM1. El vínculo con el mismo frontend se documenta en los originales y el chat, no en este recorte.

05 / Alcance y lecciones

Se utilizó HTTP. No se configuraron ni validaron HTTPS, certificados o WAF en este caso.
No se detuvo IIS ni se simuló la caída de una VM: no se afirma failover probado.
Dos respuestas distintas no prueban distribución uniforme, tolerancia a fallos zonales ni sincronización de datos o sesiones.
Los recursos son históricos. No se consultó su estado actual ni se volvió a desplegar; el usuario indicó que realizaba la limpieza al terminar sus laboratorios.

Lección práctica: Separar la infraestructura existente de los recursos nuevos, revisar el cambio previsto y validar tanto las sondas como la respuesta que recibe el usuario.

Procedencia y referencias

Caso recuperado de «Corrige el laboratorio M5 de AZ-700» y de los archivos M5 conservados por Juan. Trabajo guiado con asistencia de IA. Evidencia del 28 de septiembre; recuperación y revisión documental del 16 de octubre de 2026.

Microsoft Learn · Bicep existing resources