Microsoft AZ-104: Redes virtuales de Azure — Guía de estudio

By Laurynas Brazys · 6 August 2026 · #microsoft #az-104 #certification #exam-prep #study-guide

Forma parte de la Microsoft Azure Administrator Associate AZ-104 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.

Información general

Azure Virtual Networking establece el entramado de centro de datos definido por software para cargas de trabajo IaaS y PaaS. Usted diseña un plan de direccionamiento con CIDR, divide subredes alineadas con los límites de confianza, asegura los flujos este-oeste y norte-sur con Network Security Groups (NSGs) y Azure Firewall, conecta entornos usando VNet peering, VPN Gateway o ExpressRoute, modela el tráfico con rutas definidas por el usuario y proporciona una resolución de nombres fiable con Azure DNS. Configurar correctamente estos elementos permite diseños escalables de tipo hub-and-spoke, acceso seguro a PaaS a través de Private Endpoints y un enrutamiento predecible que satisface los requisitos de cumplimiento y rendimiento.

Direccionamiento, segmentación y política (VNets, subredes, NSG, ASG, UDR)

Una red virtual define uno o más espacios de direcciones RFC1918 no superpuestos utilizando la notación CIDR (por ejemplo, 10.0.0.0/16). Puede agregar prefijos de dirección adicionales más tarde si no existen conflictos con las redes en peering. Las subredes segmentan la VNet en bloques enrutables (por ejemplo, 10.0.1.0/24 para la web, 10.0.2.0/24 para la aplicación). Reserve una GatewaySubnet dedicada para los gateways de VPN/ExpressRoute; asígnela generosamente (al menos /27) para evitar futuros límites de escalado. La asignación de IP es dinámica por defecto; puede establecer IP privadas estáticas en las NIC cuando sea necesario.

Las rutas de sistema predeterminadas permiten el tráfico dentro de la VNet y envían 0.0.0.0/0 a internet (sujeto a la presencia de una IP pública). Las rutas definidas por el usuario (UDR) sobrescriben estos valores predeterminados a nivel de subred. Cree una tabla de rutas y asóciela con una subred; las entradas incluyen:

Siguiente salto: Dispositivo virtual (la IP de un NVA en la misma VNet), Gateway de red virtual (para dirigir a on-premise a través de VPN/ExpressRoute), Internet (para forzar la salida a internet) o Ninguno (agujero negro o blackhole).
Túnel forzado: Envíe 0.0.0.0/0 a un gateway de red virtual para forzar todo el tráfico de salida hacia on-premise, o a un NVA/Azure Firewall para un control de salida centralizado. Si usa BGP con un gateway que anuncia una ruta predeterminada, considere deshabilitar la propagación de rutas del gateway en subredes específicas para evitar una selección de ruta no deseada.

Los NSG aplican una política con estado de L3–L4 en las NIC o subredes; ambos ámbitos se pueden usar simultáneamente y el tráfico debe ser permitido por todos los NSG aplicables. Las reglas se evalúan por prioridad (100–4096; los números más bajos primero) y dirección (entrada/salida). Las reglas predeterminadas incluyen:

Entrada: AllowVnetInBound (65000), AllowLoadBalancerInBound (65001), DenyAllInBound (65500)
Salida: AllowVnetOutBound (65000), AllowInternetOutBound (65001), DenyAllOutBound (65500) Sobrescriba los valores predeterminados con reglas personalizadas de mayor precedencia. Use etiquetas de servicio (service tags) (por ejemplo, Internet, AzureLoadBalancer, Storage) para simplificar el mantenimiento, y Grupos de IP (IP Groups) para listas de direcciones reutilizables.

Los Application Security Groups (ASG) desacoplan el direccionamiento IP de la política. Asigne NIC a los ASG que representan roles (por ejemplo, Web, App, DB) y haga referencia a esos ASG en las reglas de los NSG. Esto permite cambios en la política sin tocar las IP o las subredes y facilita una segmentación consistente basada en roles dentro de una VNet.

Opciones de conectividad: Peering, VPN Gateway y ExpressRoute

El peering de VNet conecta redes virtuales (VNets) a través de la red troncal de Microsoft con baja latencia y alto ancho de banda. El peering local es dentro de una región; el peering global se extiende entre regiones. El peering no es transitivo y requiere espacios de direcciones que no se superpongan. Indicadores clave:

Allow virtual network access habilita la conectividad enrutada entre los peers.
Allow forwarded traffic permite que el tráfico reenviado por NVAs atraviese el peering.
Use remote gateways permite que una VNet utilice una puerta de enlace de VPN/ER en un “hub” conectado por peering. El hub debe tener habilitado Allow gateway transit. Una VNet solo puede usar puertas de enlace remotas de un único peer. Las VNets conectadas por peering no reciben automáticamente las rutas de cliente P2S; los usuarios finales deben instalar configuraciones de cliente VPN actualizadas que incluyan las rutas a los nuevos spokes.

Azure VPN Gateway proporciona túneles IPSec/IKE:

Site-to-site (S2S) conecta dispositivos VPN locales (on-premises) con Azure; utilice VPN basadas en rutas (IKEv2) para la mayoría de los escenarios, especialmente con BGP y múltiples túneles.
Point-to-site (P2S) permite que clientes individuales (Windows, macOS, Linux) se conecten usando OpenVPN, IKEv2 o SSTP. La configuración del cliente contiene rutas estáticas a los prefijos de Azure; vuelva a descargarla cuando los espacios de direcciones cambien o cuando agregue spokes alcanzables detrás de un hub.
VNet-to-VNet utiliza S2S dentro de las regiones/tenants de Azure, requiriendo direcciones que no se superpongan. Es útil cuando el peering no es posible (por ejemplo, entre tenants con límites administrativos).
SKUs: Prefiera VpnGw1–VpnGw5 (y las variantes AZ para redundancia de zona). El SKU Basic es heredado y carece de características (sin IKEv2/BGP). El tipo basado en rutas (route-based) soporta P2S, BGP y activo-activo. El tipo basado en políticas (policy-based) es limitado (solo S2S, sin BGP).
BGP anuncia prefijos dinámicamente, soporta el tránsito a través de múltiples túneles y simplifica la conmutación por error de rutas (route failover). Las reglas de VPN NAT pueden traducir prefijos locales/Azure que se superpongan cuando sea inevitable.

ExpressRoute ofrece conectividad privada, respaldada por SLA, a través del circuito de un socio hasta el borde de la red de Microsoft:

Un circuito es aprovisionado por el proveedor (ancho de banda, medición, SKU) y se vincula a su suscripción mediante una clave de servicio. La redundancia está integrada: cada circuito expone conexiones duales primarias/secundarias; su enrutador debe establecer sesiones BGP duales para alta disponibilidad (HA).
Tipos de peering:
- Private peering transporta tráfico privado RFC1918 a las VNets a través de una puerta de enlace de red virtual de ExpressRoute (ErGw1AZ–ErGw3AZ). Soporta BGP, conmutación por error rápida (fast failover) y FastPath opcional para la aceleración del plano de datos.
- Microsoft peering expone servicios públicos de Microsoft (por ejemplo, Storage, SQL, Microsoft 365) a través de IPs públicas con filtros de ruta. Úselo para puntos de conexión orientados a Internet sin pasar por la red pública de Internet. Microsoft 365 requiere una revisión adicional.
Use ExpressRoute Global Reach para interconectar sitios locales a través de la red troncal de Microsoft. Para el túnel forzado (forced tunneling), anuncie una ruta predeterminada sobre el private peering, o combínelo con UDRs/Azure Firewall para una salida selectiva.

Coexistencia: Una VNet puede tener puertas de enlace de VPN y ExpressRoute usando la misma GatewaySubnet; utilice el tránsito de puerta de enlace y UDRs para controlar los flujos. Se prefiere ExpressRoute para el tráfico empresarial constante; la VPN sirve como respaldo o para el alcance de sucursales/oficinas pequeñas.

Resolución de nombres y acceso seguro a PaaS (Azure DNS, Endpoints)

Azure DNS aloja zonas públicas para que sus registros orientados a Internet residan en la plataforma DNS global de Azure con alta disponibilidad. Para la resolución dentro de una VNet, Azure DNS Private Zones proporcionan un servicio de nombres de tipo split-horizon. Vincule las VNets a una zona privada para habilitar la resolución; opcionalmente, habilite el registro automático para que los registros A de las VM se registren y actualicen automáticamente con los cambios de IP de la NIC. Para la resolución de nombres híbrida y el reenvío condicional entre Azure y los sistemas locales (on-premises), implemente Azure DNS Private Resolver con puntos de conexión de entrada/salida y conjuntos de reglas que reenvíen dominios seleccionados (por ejemplo, corp.contoso.com al DNS local, o privatelink.* de vuelta a Azure).

Los Service Endpoints extienden la identidad de su VNet a servicios de Azure seleccionados (por ejemplo, Storage, SQL) a través de la red troncal de Microsoft, conservando la IP pública del servicio. En el firewall del servicio PaaS, restrinja el acceso a una VNet/subred específica. Son fáciles de habilitar por subred y por servicio, no requieren cambios de DNS y funcionan bien para escenarios simples y exclusivos de Azure. Sin embargo, el recurso todavía tiene una IP pública y no es accesible de forma privada desde el entorno local sin pasar por el punto de conexión público.

Los Private Endpoints colocan una NIC con una IP privada de su subred en el recurso PaaS a través de Private Link. El tráfico permanece en la red privada, lo que permite un control detallado de la exfiltración de datos y el acceso desde el entorno local a través de VPN/ExpressRoute. Un DNS adecuado es esencial: anule el FQDN público del recurso para que se resuelva a su FQDN de privatelink, que apunta a su IP privada. Utilice zonas de Azure Private DNS (por ejemplo, privatelink.blob.core.windows.net) vinculadas a las VNets. Elija Private Endpoints cuando necesite un direccionamiento verdaderamente privado, acceso entre entornos (cross-premises) y controles de salida estrictos.

Azure Firewall y gobernanza centralizada de salida/entrada

Azure Firewall es un firewall nativo de la nube y con estado que escala elásticamente y proporciona una política central para diseños de tipo hub-and-spoke. Despliéguelo en una subred dedicada llamada AzureFirewallSubnet. Para escenarios de túnel forzado, añada la subred AzureFirewallManagementSubnet para que el tráfico de gestión use internet mientras que el tráfico de datos sigue su ruta predeterminada.

Los tipos de colección de reglas se aplican en este orden y según la prioridad de la colección de reglas:

Las reglas DNAT traducen las IP/puertos públicos de entrada en el firewall a direcciones privadas (por ejemplo, mapear la IP pública del firewall:443 a una VM web). Combínelas con NSG en la subred de destino para aplicar el principio de privilegio mínimo.
Las reglas de red filtran el tráfico de L3–L4 (IP de origen/destino, protocolos, puertos). Úselas para protocolos que no sean HTTP(S) y para controlar los flujos de salida e intra-spoke.
Las reglas de aplicación controlan el tráfico HTTP/S de salida por FQDN o etiquetas de FQDN (por ejemplo, WindowsUpdate). La SKU Premium añade inspección TLS e IDPS para un filtrado profundo de HTTP(S). La inteligencia sobre amenazas se puede configurar en modo Alerta o Denegar para actuar sobre IP/dominios maliciosos conocidos. Combine Azure Firewall con UDR (Rutas Definidas por el Usuario) (0.0.0.0/0 hacia el firewall como dispositivo virtual) para centralizar la salida; permita el tráfico reenviado en el emparejamiento para los spokes. Envíe los registros a Log Analytics para auditoría y análisis, y use jerarquías de políticas/Azure Firewall Manager para estandarizar a escala.

Escenario de un problema práctico

Adobe debe modernizar una red híbrida: un hub seguro en Azure debe proporcionar salida a internet centralizada, conectividad on-premise con alta disponibilidad, acceso privado a Storage y SQL, y una resolución de nombres predecible entre Azure y los centros de datos. Los desarrolladores remotos también necesitan acceso P2S a todos los spokes.

Diseñar el espacio de direcciones y la segmentación

Crear una VNet Hub 10.0.0.0/16 con las subredes: AzureFirewallSubnet 10.0.0.0/26, GatewaySubnet 10.0.0.64/27, SharedServices 10.0.1.0/24. Crear VNets Spoke para Apps 10.1.0.0/16 y Datos 10.2.0.0/16.
Justificación: Los CIDR no superpuestos permiten el emparejamiento y el crecimiento futuro; las subredes dedicadas cumplen los requisitos de la plataforma y simplifican el ámbito de las UDR/NSG.

Establecer conectividad hub-and-spoke

Emparejar Hub↔Apps y Hub↔Datos con las opciones Permitir el acceso a la red virtual y Permitir el tráfico reenviado. En el hub, establecer Permitir tránsito de puerta de enlace; en los spokes, establecer Usar puertas de enlace remotas.
Justificación: Centraliza los flujos norte-sur a través de la puerta de enlace/firewall del hub mientras permite los flujos este-oeste a través del hub, evitando la complejidad de una malla.

Proporcionar conectividad on-premise privada y redundante

Solicitar un circuito ExpressRoute (emparejamiento privado) a través de un proveedor; configurar sesiones BGP duales. Desplegar una puerta de enlace de red virtual de ExpressRoute (ErGw2AZ) en la GatewaySubnet del hub y vincular el circuito.
Justificación: La conectividad privada respaldada por SLA con redundancia integrada y una puerta de enlace con redundancia de zona cumple con las necesidades empresariales de alta disponibilidad (HA) y rendimiento.

Centralizar la salida y proteger las cargas de trabajo

Desplegar Azure Firewall Standard en AzureFirewallSubnet. Crear una UDR en cada subred de los spokes: 0.0.0.0/0 con próximo salto de tipo Dispositivo virtual → IP privada del firewall. Añadir NSG (Grupos de Seguridad de Red) a los spokes que permitan solo los puertos requeridos hacia el firewall e intra-VNet.
Justificación: Azure Firewall + UDR aplican una política de salida coherente, registro e inteligencia sobre amenazas; los NSG proporcionan microsegmentación a nivel de subred/NIC.

Asegurar PaaS con acceso verdaderamente privado

Crear Private Endpoints para Storage y SQL en el spoke de Datos. Vincular las zonas de Azure Private DNS (privatelink.blob.core.windows.net, privatelink.database.windows.net) al Hub y a los Spokes. Deshabilitar el acceso a la red pública en los recursos PaaS.
Justificación: Los Private Endpoints eliminan la exposición pública y permiten el acceso desde on-premise a través de ExpressRoute; Azure Private DNS asegura la correcta resolución de nombres.

Implementar resolución de nombres híbrida y reenvío condicional

Desplegar Azure DNS Private Resolver en el hub con puntos de conexión de entrada y salida. Crear reglas para reenviar las consultas de corp.adobe.com al DNS on-premise y resolver las zonas privatelink dentro de Azure.
Justificación: Proporciona un DNS determinista de horizonte dividido entre Azure y on-premise sin necesidad de VM de DNS personalizadas.

Habilitar el acceso remoto de desarrolladores a todos los spokes

Configurar una VPN P2S en la VPN Gateway del hub junto con ExpressRoute (coexistencia). Distribuir el perfil del cliente VPN. Después de añadir spokes, volver a descargar el paquete del cliente para que se incluyan las rutas a 10.1.0.0/16 y 10.2.0.0/16.
Justificación: Una P2S basada en el hub simplifica las operaciones y, con las rutas de cliente actualizadas y el tránsito de puerta de enlace del emparejamiento, otorga a los usuarios accesibilidad a todos los spokes.

Reforzar la seguridad con ASG y NSG

Asignar las NIC a ASG (Grupos de Seguridad de Aplicaciones) (Web, App, DB) e implementar reglas de NSG que permitan Web→App (TCP 443), App→DB (TCP 1433) por ASG, denegando todo lo demás. Conservar las reglas predeterminadas cuando sea apropiado.
Justificación: La política basada en roles escala sin gestión de IP y aplica el principio de privilegio mínimo.

Esta arquitectura cumple los requisitos de Adobe con redundancia de ExpressRoute, gobernanza centralizada de Azure Firewall, acceso privado a PaaS y un DNS coherente, al tiempo que garantiza que los usuarios remotos y los sistemas on-premise puedan alcanzar de forma segura cada carga de trabajo a través del hub.

← Máquinas virtuales de Azure y Cómputo · Todos los dominios · Equilibrio de carga de Azure y Gestión del tráfico →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →