AZ-900
Deep Dive
VNet, NSGs, Load Balancer, Application Gateway, VPN, ExpressRoute, DNS y DDoS. Las redes son ~15% del AZ-900 y la fuente de las preguntas más complejas del examen.
Contenido
¿Qué es una VNet?
Una red privada virtual en Azure. Aísla y segmenta tus recursos de red. Es el equivalente a una red corporativa local, pero en la nube. Cada VNet tiene un espacio de direcciones IP (ej: 10.0.0.0/16) que no se enruta públicamente.
Componentes de una VNet
Reglas de VNets para el examen
Crea tu primera red virtual en Azure y una subred dentro de ella. Las VNets son el fundamento del networking privado en la nube.
+1 más...
Diagrama interactivo — pasa el cursor sobre cada nodo
Firewall a nivel de subnet o NIC. Lista de reglas permit/deny para tráfico entrante y saliente.
Cómo funcionan las reglas NSG
Cada regla tiene prioridad (100–4096, menor = mayor prioridad). Se evalúan en orden hasta encontrar match. Si ninguna coincide → aplica regla default (Deny All para inbound, Allow VNet/Internet para outbound).
| Prioridad | Puerto | Protocolo | Fuente | Acción |
|---|---|---|---|---|
| 100 | 443 | TCP | Internet | Allow |
| 110 | 80 | TCP | Internet | Allow |
| 200 | 3389 | TCP | 10.0.0.0/8 | Allow |
| 4096 | * | * | * | Deny |
Error común: RDP expuesto a internet
Por defecto, las VMs nuevas NO tienen restricción de entrada si se crea una IP pública. Muchos admins dejan el puerto 3389 (RDP) o 22 (SSH) abierto a 0.0.0.0/0. Microsoft detecta millones de intentos de brute force diariamente contra estos puertos.
Solución correcta
Just-in-Time VM Access (Azure Defender): abre el puerto solo cuando un admin específico lo solicita, por tiempo limitado, desde su IP.
NSG en subnet vs NIC
Puedes asignar NSG a nivel subnet (afecta todos los recursos en ella) O a nivel NIC individual de una VM. Si ambos tienen NSGs, se evalúan los dos — el tráfico debe pasar ambos. NSG en subnet = defensa de primera línea. NSG en NIC = defensa de segunda línea.
Crea un NSG y agrega una regla de entrada para permitir tráfico HTTPS. Los NSGs son el firewall a nivel de red de Azure.
+1 más...
Despliega Azure Bastion para conectarte a tus máquinas virtuales por RDP/SSH sin exponer una IP pública en la VM.
+1 más...
Un sitio web dejó de ser accesible. Encuentra la regla de NSG responsable y corrígela — sin pasos guiados.
+1 más...
Azure tiene 4 servicios distintos de balanceo. Elegir el correcto es pregunta frecuente del AZ-900.
Azure Load Balancer
Distribuye tráfico TCP/UDP entre VMs o backends. Opera a nivel de transporte (Layer 4). No entiende HTTP. Para tráfico no-HTTP o ultra-baja latencia.
Cuándo usar
No usar para
No filtra por URL o headers HTTP
Azure Application Gateway
Web Application Firewall (WAF) + load balancing HTTP/S. Enruta por URL path (/api → backend1, /web → backend2). SSL termination. Protege contra OWASP top 10.
Cuándo usar
No usar para
Solo HTTP/S. No para TCP/UDP
Azure Traffic Manager
Balanceo de carga basado en DNS. Enruta usuarios al endpoint más apropiado según políticas (geográfico, performance, prioridad). No toca el tráfico directamente — solo resuelve DNS.
Cuándo usar
No usar para
No es un proxy — no puede inspeccionar tráfico
Azure Front Door
CDN + WAF + balanceo HTTP/S global. Acelera contenido con caché en edge. Enruta al backend más sano y más cercano. Combina Traffic Manager + Application Gateway + CDN.
Cuándo usar
No usar para
Solo HTTP/S. Más caro que Traffic Manager
Tabla de decisión rápida
| Escenario | Respuesta |
|---|---|
| Distribuir tráfico HTTP entre 3 VMs en East US | Azure Load Balancer (L4) o Application Gateway (L7) |
| Enrutar /api a backend1 y /web a backend2 | Application Gateway (URL-based routing) |
| Proteger app web contra SQL injection | Application Gateway con WAF |
| Enviar usuarios europeos a West Europe y americanos a East US | Traffic Manager (routing geográfico) |
| App web global de baja latencia con CDN + WAF | Azure Front Door |
| Failover automático de región primaria a secundaria por DNS | Traffic Manager (priority routing) |
Crea un Azure Load Balancer para distribuir tráfico entrante entre varias VMs, mejorando disponibilidad y escalabilidad.
+1 más...
Para conectar tu red on-premises (u otra red) a Azure de forma privada.
Azure VPN Gateway
Túnel VPN encriptado sobre internet público. Conexión segura pero con latencia variable y ancho de banda limitado (~1 Gbps máx). Económico.
Costo/mes
~$30–$700 (según SKU)
Ancho de banda
Hasta ~1 Gbps
Latencia
Variable (internet)
SLA
99.9%
Azure ExpressRoute
Conexión privada dedicada a Azure via un partner de telecomunicaciones (Telefónica, AT&T, Equinix, etc.). Nunca toca internet público. SLA garantizado. Hasta 100 Gbps.
Costo/mes
~$500–$5,000+
Ancho de banda
50 Mbps – 100 Gbps
Latencia
Predecible y baja
SLA
99.95%
VPN vs ExpressRoute — cuándo elegir
Usa VPN cuando:
Usa ExpressRoute cuando:
Azure Public DNS
Aloja zonas DNS públicas (ej: contoso.com) en Azure. Alta disponibilidad, anycast global, SLA 100% (Microsoft garantiza disponibilidad de resolución).
Soporta todos los tipos de registro: A, AAAA, CNAME, MX, TXT, NS, SOA, SRV
Integración con Azure Resource Manager (RBAC, tags, billing)
Alias Records para recursos Azure (actualización IP automática si cambia IP de VM/LB)
Azure Private DNS
Resolución DNS privada para recursos dentro de VNets. Sin exponer IPs privadas al DNS público.
vm1.internal.contoso.com → 10.0.1.4 (resolución interna)
Funciona entre VNets vinculadas (VNet links)
Servicios PaaS con Private Endpoints resuelven nombres privados
Sin gestionar servidores DNS propios (Azure lo gestiona)
VNet Peering
Conecta dos VNets para que los recursos se comuniquen como si estuvieran en la misma red. Tráfico va por la red backbone de Azure (no internet). Baja latencia.
Regional Peering
Dos VNets en la misma región. Gratuito el tráfico en la misma región (solo paga egress estándar).
Global Peering
Dos VNets en diferentes regiones. Pequeño costo adicional por tráfico cross-region.
El peering NO es transitivo. Si A→B y B→C, A NO puede hablar con C sin crear un peering A→C directo.
Private Endpoints
Expone servicios Azure PaaS (Storage, SQL, Key Vault, etc.) con una IP privada dentro de tu VNet. El tráfico nunca sale a internet público.
Sin vs Con Private Endpoint
Sin Private Endpoint
VM → internet → storage.core.windows.net
Tráfico sale por internet, potencialmente interceptable
Con Private Endpoint
VM → 10.0.1.5 (PE) → storage (privado)
Tráfico permanece en red privada de Azure
DDoS Basic (gratuito)
Protección automática incluida en Azure para toda la infraestructura. Mitiga ataques volumétricos comunes. Sin costo adicional. SIN dashboards ni alertas personalizadas.
Cuándo usar
Siempre activo. Sin configuración.
DDoS Standard (de pago)
Políticas de mitigación customizadas per-VNet. Telemetría en tiempo real. Alertas. Soporte especializado de DDoS Response Team. Garantía de crédito si Azure falla en proteger.
Cuándo usar
Apps en producción expuestas a internet con requisitos de SLA alto.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
¿Qué servicio de Azure permite conectar dos VNets para que los recursos en ambas se comuniquen como si estuvieran en la misma red?
Pon a prueba lo que aprendiste con preguntas originales del examen AZ-900.
Iniciar simulacro AZ-900Sin límite de simulacros con plan Pro
Inicia sesión para llevar tu progreso.