Arquitectura de red en Azure (AZ-305)

0. Cómo entra la red en AZ-305

En AZ-305 ya no basta con saber crear una VNet. Se espera que diseñes topologías completas que soporten varios entornos (prod / pre / dev), múltiples regiones y conectividad híbrida.

El tipo de preguntas suele girar en torno a:

• Elegir entre HUB & SPOKE clásico o Virtual WAN para diseños a gran escala.
• Definir segmentación por dominios de seguridad (front, back, datos, gestión).
• Diseñar salida a Internet inspeccionada con Azure Firewall / NVAs.
• Integrar DNS corporativo con servicios PaaS usando Private Endpoints.

Patrón mental AZ-305: piensa siempre en plano de conectividad (VNets, peers, gateways), plano de seguridad (NSG, Firewall, WAF, Private Link) y plano de nombres (DNS).

1. Hub & Spoke vs Virtual WAN

Los dos modelos que más aparecen en el examen son:

Hub & Spoke clásico

• Una VNet central (hub) con componentes compartidos: firewall, VPN, ExpressRoute, etc.
• Varias VNets spoke para aplicaciones/entornos, emparejadas al hub.
• Ideal cuando tienes pocas regiones y el número de VNets es manejable.

Virtual WAN (vWAN)

• Servicio global que abstrae la conectividad: hubs virtuales gestionados por Microsoft.
• Conecta sedes, VNets y usuarios remotos de manera centralizada.
• Escenario típico: organizaciones con muchas sedes y múltiples regiones.

2. Segmentación, subredes y dominios de confianza

Una buena arquitectura de red en AZ-305 implica definir dominios de confianza claros:

• Capa de presentación: front-ends web, APIs públicas.
• Capa de negocio: microservicios, APIs internas.
• Capa de datos: bases de datos, caches, colas internas.
• Capa de gestión: jumpboxes, herramientas de administración, bastion hosts.

Cada dominio suele mapearse a una o varias subredes dedicadas con NSG específicos. En los enunciados se valora que:

• Limites claramente el acceso Este-Oeste entre capas.
• La gestión vaya siempre por subredes y puertos diferenciados.
• Los datos nunca sean accesibles directamente desde Internet.

3. Salida a Internet inspeccionada (egress)

Uno de los puntos clave en diseños modernos es cómo sale el tráfico hacia Internet:

• Salida directa por IP pública en cada recurso → simple, pero difícil de controlar.
• Salida centralizada por Azure Firewall o NVA en el hub → controla y registra todo.
• Salida a través de Secure Web Gateway o proxy corporativo.

En AZ-305, la opción “correcta” suele ser centralizar la salida a través de un Azure Firewall en el hub, con UDRs que envían el tráfico a dicho firewall.

Si el requerimiento menciona “registro y filtrado de todo el tráfico saliente hacia Internet”, busca una solución con Azure Firewall en el hub + UDRs desde los spokes.

4. DNS empresarial en Azure

En arquitecturas avanzadas tienes tres piezas de DNS a coordinar:

• DNS on-premises: suele seguir teniendo autoridad sobre dominios internos históricos.
• Azure Private DNS Zones: resolución interna para VNets y Private Endpoints.
• DNS público: dominios que resuelven en Internet (por ejemplo, con Azure DNS).

Patrones habituales

• Definir zonas privadas para servicios PaaS (p.ej. privatelink.database.windows.net) y enlazarlas a las VNets relevantes.
• Integrar DNS on-prem con Azure reenviando consultas hacia un DNS forwarder en la VNet.
• Usar Private Endpoints para exponer PaaS solo por redes privadas.

5. Patrones de examen y laboratorio guiado

Patrones típicos de examen

• “Muchas sedes en todo el mundo, múltiples regiones, gestión centralizada” → Virtual WAN con hubs seguros.
• “Necesitamos inspeccionar todo el tráfico saliente” → Azure Firewall en el hub + UDRs.
• “Debemos publicar servicios PaaS solo para redes internas” → Private Endpoints + Private DNS Zones.

Laboratorio recomendado

1. Construir un hub & spoke sencillo con un Azure Firewall en el hub.
2. Crear UDRs en un spoke para enviar tráfico de salida al firewall.
3. Configurar una Private DNS Zone y un Private Endpoint para Azure SQL.