El dominio de redes del AZ-104 representa entre el 15 y el 20 % del examen completo. Los temas centrales son la configuración de VNet, la seguridad, el DNS y el balanceo de carga. La terminología puede parecer desconocida al principio, pero una vez que comprendes cada concepto con analogías del mundo real, resulta mucho más sencillo de lo que imaginas.
VNet y Subredes
¿Qué es una VNet?
Una VNet (Virtual Network) te permite crear tu propia red privada dentro de Azure. En términos simples, es como construir un edificio de oficinas exclusivo para tu empresa dentro de la gigantesca nube de Azure. Dentro del edificio, los empleados internos pueden comunicarse libremente entre sí, pero las personas externas no pueden entrar a su antojo.
Al crear una VNet defines un espacio de direcciones (CIDR). Especificar , por ejemplo, establece el rango de direcciones internas que puede usar ese edificio, de forma similar a definir el esquema de numeración de habitaciones del edificio completo.
Las subredes son el concepto de dividir ese edificio piso por piso. Puedes zonificarlo por propósito: el piso 1 para servidores web, el piso 2 para bases de datos y el piso 3 para sistemas de administración. Dividirlo así te permite aplicar reglas de seguridad distintas por piso y aislar una zona específica cuando surge un problema, haciendo la administración mucho más cómoda.
VNet Peering: Un Corredor Dedicado que Conecta Dos Edificios
Conforme un negocio crece, puede haber un edificio en Seúl y otro en Busan. ¿Cómo se comunican? Usar el internet público es lento y representa riesgos de seguridad. VNet Peering crea un corredor dedicado entre dos VNets a través de la red troncal interna de Azure — sin internet, por lo que es rápido y seguro.
Existen dos tipos de VNet Peering:
Peering local: Conecta dos VNets dentro de la misma región de Azure (p. ej., Corea Central). Como conectar dos oficinas en la misma ciudad con una línea dedicada. Peering global: Conecta VNets en distintas regiones (p. ej., Corea Central y Este de EE. UU.). Como conectar la sede de Seúl con una sucursal en Nueva York mediante una línea dedicada internacional.
Característica clave: No transitividad
Hay una regla sobre VNet Peering que debes recordar: es no transitivo. Aquí hay un ejemplo para explicar qué significa.
Supón que el Edificio A y el Edificio B están conectados por un corredor dedicado, y que el Edificio B y el Edificio C también están conectados por un corredor dedicado. ¿Puedes ir del Edificio A, pasando por el Edificio B, hasta llegar al Edificio C? No. VNet Peering representa solo una conexión directa entre dos VNets. Para que A y C se comuniquen, debes configurar un Peering A↔C por separado. Esta regla se pregunta con frecuencia en el examen.
UDR (Ruta Definida por el Usuario): Tú Decides el Camino del Tráfico
De forma predeterminada, Azure determina automáticamente la ruta óptima para que el tráfico llegue a su destino. Sin embargo, por razones de seguridad puede que necesites forzar todo el tráfico a pasar por un punto de control específico. Por ejemplo, si quieres que todo el tráfico externo pase por una NVA (Network Virtual Appliance) que actúa como firewall, utilizas una UDR.
Una UDR (User Defined Route) anula las reglas de enrutamiento predeterminadas de Azure y te permite especificar exactamente qué camino debe seguir el tráfico. Es como exigir que los vehículos en una autopista deben pasar por una caseta de peaje (NVA) en un tramo determinado. Esto te permite inspeccionar todo el tráfico y bloquear paquetes sospechosos.
Seguridad de Red
NSG (Network Security Group): El Guardia de Seguridad del Edificio
Un NSG es como un guardia de seguridad para tu red. Define reglas sobre quién puede entrar (entrante) y quién puede salir (saliente). Estas reglas pueden aplicarse a una subred completa o a la interfaz de red (NIC) de una VM individual.
Por ejemplo, en la subred que aloja servidores web podrías crear una regla que diga: "solo se permite tráfico en el puerto 80 (HTTP) y el puerto 443 (HTTPS) desde el exterior; bloquear todo lo demás."
Comprensión de las Reglas de Prioridad
Las reglas de NSG tienen números de prioridad. Cuanto menor es el número, más temprano se evalúa la regla. Si una regla con prioridad 100 y una regla con prioridad 1000 entran en conflicto, la regla con prioridad 100 se aplica primero.
Es como un guardia de seguridad que lee un manual de instrucciones de trabajo donde el punto 1 se revisa antes que el punto 10. Al colocar reglas de permiso en alta prioridad (números bajos) y reglas de denegación en baja prioridad (números altos) — o viceversa — puedes ejercer un control granular sobre el tráfico.
Reglas Predeterminadas (No Se Pueden Cambiar)
Azure incluye automáticamente reglas predeterminadas en todos los NSG: Se permite la comunicación dentro del VNet Se permite el tráfico saliente hacia internet Se bloquea todo el tráfico entrante restante
Estas reglas predeterminadas no pueden eliminarse, pero puedes anularlas añadiendo reglas con un número más bajo (mayor prioridad).
ASG (Application Security Group): Administra por Rol, No por IP
¿Qué ocurre cuando tienes 10 o 20 servidores? Especificar la dirección IP de cada servidor uno por uno en las reglas del NSG se vuelve muy complejo. Cuando cambia la IP de un servidor, también hay que actualizar todas las reglas.
ASG (Application Security Group) resuelve este problema. Agrupa VMs en grupos lógicos por rol, de modo que las reglas del NSG pueden referenciar el nombre del grupo en lugar de direcciones IP.
Por ejemplo, agrupa 10 servidores web en un ASG llamado 'WebServers' y 5 servidores de base de datos en un ASG llamado 'DatabaseServers'. Luego define la regla del NSG como "permitir el puerto 1433 desde WebServers hacia DatabaseServers." Así, cuando se añade un servidor o cambia su IP, basta con añadirlo al ASG — no es necesario modificar las reglas del NSG. Es como administrar permisos de acceso por nombre de departamento ('Equipo de Ventas', 'Equipo de Desarrollo') en lugar de por listas individuales de empleados.
!NSG vs ASG
Azure Bastion: Accede a VMs de Forma Segura Sin una IP Pública
Normalmente, para conectarse a un servidor de forma remota necesita una IP pública y hay que abrir RDP (puerto 3389) o SSH (puerto 22) a internet. Hacerlo da a los hackers un objetivo persistente para atacar.
Azure Bastion resuelve este problema por completo. Incluso sin asignar una IP pública a la VM, puedes acceder a ella de forma segura mediante un navegador web en el portal de Azure. No es necesario exponer los puertos RDP o SSH a internet.
Por analogía: en lugar de anunciar públicamente el número de tu oficina en la entrada del edificio, todos los visitantes son escoltados al interior únicamente a través de una recepción con estrictas medidas de seguridad (Bastion). Los externos nunca conocen un número de habitación específico — siempre deben pasar por recepción.
Service Endpoint vs. Private Endpoint: Dos Formas de Conectarse de Forma Privada
Al acceder a servicios de Azure como Azure Storage o SQL Database, los recursos dentro de un VNet pueden conectarse de forma más segura y eficiente de dos maneras.
Un Service Endpoint optimiza la ruta desde un VNet hacia un servicio de Azure. El tráfico se mueve a través de la red interna de Azure en lugar de internet. Sin embargo, el servicio de Azure todavía tiene una dirección IP pública. Por analogía: en lugar de tomar una carretera normal hasta el aeropuerto, usas una autopista exclusiva. Más rápido y con menos tráfico, pero el aeropuerto en sí sigue siendo un lugar público.
Un Private Endpoint va un paso más allá. Asigna una dirección IP privada de dentro de tu VNet directamente al servicio de Azure. El servicio se comporta ahora como si fuera un recurso dentro de tu VNet. No se puede acceder desde internet — solo desde dentro del VNet. Por analogía: una sala VIP específica del aeropuerto se ha mudado físicamente al edificio de tu empresa. Solo es accesible desde el interior.
En resumen: Service Endpoint: Usa dirección IP pública, pero la ruta está optimizada (rápido y sencillo) Private Endpoint: Asigna una IP privada, completamente aislado (más seguro, más complejo)
!Service Endpoint vs Private Endpoint
DNS
¿Por Qué Necesitamos DNS?
DNS (Domain Name System) es como la guía telefónica de internet. Cuando escribimos una dirección como , en realidad se convierte en una dirección IP numérica como para la comunicación. DNS se encarga de esta conversión.
Azure Public DNS: Administra Tu Dominio en Azure
Azure Public DNS te permite administrar los registros DNS de un dominio que posee tu empresa (p. ej., ) en Azure. Soporta varios tipos de registros DNS: registros A (dominio → dirección IP), registros CNAME (alias de dominio), registros MX (servidor de correo), registros TXT (verificación de titularidad del dominio) y más.
Por ejemplo, para apuntar a la IP pública de una VM específica de Azure, crea un registro A. Para apuntar a , crea un registro CNAME.
Azure Private DNS: Una Guía Telefónica Interna Solo para el VNet
Las VMs dentro de un VNet se comunican utilizando IPs internas. Pero memorizar direcciones IP es incómodo, y administrarlas se vuelve difícil cuando se añaden VMs o cambian las IPs. Una Azure Private DNS Zone es un sistema DNS interno utilizado exclusivamente dentro de un VNet.
Por ejemplo, crea una Private DNS Zone y vincúlala a un VNet. Las VMs en ese VNet podrán encontrarse entre sí usando nombres como . Este nombre DNS no resuelve nada en el internet público — solo funciona dentro del VNet.
La función de registro automático es especialmente útil. Cuando se crea una VM en el VNet, su nombre e IP se registran automáticamente en Private DNS. No es necesario crear registros DNS manualmente. Es como que un nuevo empleado quede registrado automáticamente en el directorio telefónico de la empresa el primer día.
También puedes vincular múltiples VNets a una sola Private DNS