La topología de red es la base de toda landing zone. El AZ-305 evalúa el diseño hub-spoke, cuándo escalar a Virtual WAN, y cómo el enrutamiento (UDRs) fuerza el tráfico por el firewall central.
Contenido
Reglas de diseño
Segmentación por subnet
VNet peering conecta dos VNets por el backbone de Microsoft: latencia mínima, sin gateways ni cifrado adicional necesario. Global peering = entre regiones. No es transitivo: A↔B y B↔C no implica A↔C — la base de por qué existe el hub con firewall/gateway compartido.
🌐Árbol de decisión — Topología de red
Single VNet · Hub-Spoke · Virtual WAN · Mesh
Pregunta 1
¿La arquitectura necesita más de una VNet (múltiples equipos, workloads o suscripciones aislados)?
💡 Señal single VNet: organización pequeña, un solo workload, subnets por tiers (web/app/db), sin requisito de aislamiento fuerte entre equipos
| Topología | Cuándo |
|---|---|
| VNet única con subnets | Organización pequeña, un workload, una región |
| Hub-Spoke | El estándar enterprise: servicios compartidos centralizados, aislamiento por workload |
| Virtual WAN (hub gestionado) | Muchas regiones + muchas sucursales: Microsoft gestiona el hub y el enrutamiento |
| Mesh (full peering) | Pocas VNets que se hablan todas; con Virtual Network Manager se automatiza |
🏛️¿Por qué usar Hub-Spoke?
El patrón Hub-Spoke centraliza Firewall, VPN Gateway, Bastion y DNS en una VNet hub. Cada equipo tiene su propio spoke (VNet) aislado. Todo el tráfico entre spokes pasa por el Firewall — control centralizado sin duplicar infraestructura.
🛡️ Seguridad centralizada
Azure Firewall en el hub inspecciona todo el tráfico entre spokes. No hay comunicación directa spoke-a-spoke sin pasar por el Firewall.
🔒 Acceso admin seguro
Azure Bastion permite RDP/SSH a VMs de cualquier spoke desde el navegador, sin exponer IPs públicas en ninguna VM.
📡 DNS compartido
Una zona DNS privada en el hub resuelve nombres internos para todas las VNets sin configuración adicional por spoke.
El HUB contiene (servicios compartidos)
Los SPOKES contienen
Beneficios que el examen espera que cites
Un solo gateway y firewall compartidos (costo), aislamiento entre workloads (seguridad), gestión centralizada del tráfico norte-sur y este-oeste (gobernanza), y crecimiento añadiendo spokes sin tocar el hub (escala).
Hub-Spoke manual
Virtual WAN
User-Defined Routes
Casos relacionados
| Requisito | Diseño |
|---|---|
| Workloads aislados compartiendo firewall y gateway | Hub-spoke |
| Spokes usan el gateway del hub | Gateway transit + use remote gateways |
| Todo el tráfico saliente de spokes inspeccionado | UDR 0.0.0.0/0 → Azure Firewall |
| Spoke A habla con spoke B de forma controlada | UDRs vía firewall del hub (peering no transitivo) |
| 40 sucursales + 5 regiones + routing automático | Virtual WAN (secured hubs) |
| Internet de las VMs debe salir por el datacenter on-prem | Forced tunneling |
| IPs de salida predecibles para whitelisting de un partner | NAT Gateway en la subnet |
| Conectar VNets de regiones distintas | Global VNet peering (o vWAN) |
| Gestionar topología/seguridad de 100 VNets a escala | Azure Virtual Network Manager |
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa tiene 12 VNets de workload en una región, conectividad ExpressRoute a on-premises, y exige que TODO el tráfico (spoke-spoke, spoke-internet, spoke-onprem) sea inspeccionado por un firewall central, minimizando el costo de gateways. ¿Qué diseño propones?
Inicia sesión para llevar tu progreso.