El examen AZ-700 evalua tu capacidad para tomar decisiones de diseno en escenarios de VNet, Subnet y NAT Gateway. Si los espacios de direcciones CIDR se superponen, el Peering de VNet se vuelve imposible. Calcular mal las IPs reservadas hace que la subred sea mas pequena de lo esperado. Comprender como NAT Gateway resuelve el agotamiento de puertos SNAT en conexiones salientes de gran volumen es otro punto clave del examen.
Limites de VNet: Region y Unidad de Aislamiento
Cuando una empresa abre una nueva oficina, primero disena el cableado completo del edificio antes de mover un solo escritorio. En Azure, un Virtual Network (VNet) debe crearse antes de desplegar casi cualquier recurso. Un VNet existe dentro de una unica region de Azure, y los recursos dentro del mismo VNet se comunican entre si sin configuracion adicional.
El trafico que cruza los limites de region requiere VNet Peering, una VPN Gateway o ExpressRoute. Los nombres de VNet solo necesitan ser unicos dentro de su grupo de recursos. Dos VNets en diferentes grupos de recursos de la misma suscripcion pueden compartir el mismo nombre sin conflictos. Si un VNet tiene una conexion de Peering activa, moverlo a otro grupo de recursos queda bloqueado hasta que se elimine ese Peering.
Un VNet puede tener varios bloques CIDR como espacio de direcciones. Se pueden agregar mas bloques mas adelante, pero si ya existe un Peering activo, agregar un CIDR que se superponga sera rechazado. Definir bien el espacio de direcciones desde el principio evita redisenos costosos en el futuro.
Particionamiento de Subredes e IPs Reservadas
Imagina las subredes como pisos en un edificio de oficinas: cada piso alberga un departamento diferente y tiene sus propios controles de acceso. En Azure, las subredes son la unidad principal de aislamiento de trafico y aplicacion de politicas. Azure reserva 5 direcciones IP en cada subred: las primeras 4 y la ultima.
Para una subred /27 (32 direcciones totales), solo hay 27 IPs disponibles para uso. Si planeas colocar 15 maquinas virtuales, /27 funciona, pero deja muy poco margen de crecimiento. Elegir /26 (59 IPs utilizables) proporciona un margen mucho mas comodo.
Ciertos servicios de Azure requieren una subred dedicada:
: exclusiva para Azure Firewall, minimo /26 recomendado : exclusiva para VPN Gateway y ExpressRoute Gateway : exclusiva para Azure Bastion, minimo /26 obligatorio
La Subnet Delegation permite que servicios PaaS especificos de Azure, como Azure Container Instances o App Service Environment, inserten NICs directamente en esa subred. Solo puede haber una Delegation activa por subred a la vez.
SKU de IP Publica: Basic vs Standard
Asi como el numero de telefono principal de una empresa debe mantenerse igual para que los clientes confien en ella, algunas cargas de trabajo necesitan una IP publica estable y predecible. La IP publica de Azure esta disponible en dos SKU: Basic y Standard, y las diferencias son importantes para el examen.
El SKU Basic admite asignacion estatica o dinamica y deja la entrada abierta por defecto. El SKU Standard admite solo asignacion estatica y deniega la entrada a menos que un NSG lo permita explicitamente. Las opciones Zone-Redundant y Zonal solo estan disponibles con SKU Standard. El SKU Basic funciona solo con Basic Load Balancer y el SKU Standard funciona solo con Standard Load Balancer.
La IP publica Standard es redundante por zona de forma predeterminada, lo que significa que sobrevive a un fallo de zona de disponibilidad sin cambiar la direccion IP. Si deseas anclarla a una zona especifica, debes elegir explicitamente la opcion Zonal. El SKU Basic esta programado para ser retirado el 30 de septiembre de 2025.
IPv6 y Dual-Stack tambien forman parte del alcance de AZ-700. Asignar tanto un espacio de direcciones IPv4 como IPv6 a un VNet crea una configuracion Dual-Stack. Para que el Peering transporte trafico IPv6, ambos lados deben tener definido un espacio de direcciones IPv6.
!SKU de IP pública: Basic vs Standard
NAT Gateway: Ampliando el Grupo de SNAT Saliente
Imagina una sala de correos corporativa donde docenas de empleados envian cartas usando la misma direccion de empresa en el sobre. Cuando el volumen escala, la direccion compartida se queda sin combinaciones distinguibles de puertos — eso es el agotamiento de puertos SNAT. NAT Gateway resuelve exactamente este problema.
Un unico NAT Gateway puede asociarse con hasta 16 IPs publicas o un Public IP Prefix. Cada IP proporciona 64,512 puertos SNAT, por lo que 16 IPs admiten teoricamente alrededor de un millon de conexiones salientes simultaneas.
NAT Gateway se asocia a nivel de subred. Todo el trafico saliente de esa subred pasa por el NAT Gateway, mientras que las conexiones entrantes no son manejadas por este. Las IPs publicas asociadas al NAT Gateway quedan dedicadas exclusivamente al uso saliente.
Elegir un Metodo de Salida: NAT Gateway vs Reglas de Salida de Load Balancer vs IP Publica de Instancia
Piensa en tres formas en que un restaurante gestiona los pagos: el cliente va directamente a la cocina, paga en la caja registradora, o usa un terminal de tarjeta gestionado de forma centralizada. El enrutamiento de trafico saliente en Azure funciona igual — hay tres rutas distintas.
Asi se comparan los tres metodos:
NAT Gateway: 64,512 puertos por IP, solo saliente, aplicado a nivel de subred, asignacion dinamica de puertos que evita el agotamiento Reglas de Salida de Load Balancer: hasta 64,512 puertos por IP preasignados entre las VMs del backend, menos puertos por VM a medida que crece el grupo, reglas de LB de entrada configuradas por separado IP Publica de Instancia: 64,512 puertos por VM de forma independiente, soporta entrada y salida, configurado por NIC de VM
Cuando un NAT Gateway esta asociado a una subred, tiene prioridad sobre las Reglas de Salida de Load Balancer para el trafico de esa subred. Para cargas de trabajo a gran escala, NAT Gateway es la opcion mas confiable.
Prevencion de Superposicion de IPs y Errores de Diseno en Peering
Dos departamentos que usan la misma direccion postal hacen que cada carta llegue al lugar equivocado. De la misma manera, dos VNets con bloques CIDR superpuestos no pueden conectarse mediante Peering. Este es el error de diseno de espacio de direcciones mas comun.
Si tu red on-premises usa 10.0.0.0/8 y tu VNet de Azure tambien cae dentro de ese rango, la conectividad hibrida mediante ExpressRoute o VPN fallara. Siempre concilia tu plan de direcciones de Azure con el sistema IPAM corporativo antes de crear VNets.
El Peering no es transitivo. Si el VNet A se conecta con el VNet B y el VNet B con el VNet C, el trafico entre A y C no fluye automaticamente. Debes crear un Peering directo entre A y C, o configurar un VNet hub con la opcion 'Allow Gateway Transit' en el lado hub y 'Use Remote Gateways' en el lado spoke.
En una configuracion de Peering Dual-Stack, ambos VNets deben tener asignado un espacio de direcciones IPv6. Si solo un lado tiene IPv6, los paquetes IPv6 no atravesaran la conexion de Peering.
Escenarios Practicos: Errores en Subredes y Agotamiento de Salida
Un equipo intento colocar 30 VMs en una unica subred /27. Con 5 IPs reservadas restadas de 32, solo quedan 27 direcciones disponibles, dejando 3 VMs sin IP. La solucion requiere recrear la subred como /26 (59 IPs utilizables) desde cero, ya que no existe un redimensionamiento en linea una vez que los recursos estan desplegados.
En otro escenario, cientos de VMs que compartian una unica IP publica comenzaron a experimentar agotamiento de puertos SNAT porque las Reglas de Salida de Load Balancer preasignan un numero fijo de puertos por VM. Agregar un NAT Gateway a la subred resuelve esto de inmediato: asigna puertos de forma dinamica, por lo que quedarse sin puertos es practicamente imposible incluso con trafico en picos.
Cuando una pregunta del examen menciona 'agotamiento de SNAT', 'limite de puertos de salida alcanzado' o 'gran numero de VMs conectandose a internet', la respuesta correcta es NAT Gateway.
Resumen para el Examen
"Las IPs reservadas son 5 por subred — calcular las direcciones utilizables" -- Restar 5 del total (/27 = 32 - 5 = 27 utilizables) "Nombre de subred dedicada para Azure Firewall" -- AzureFirewallSubnet (minimo /26) "Subred dedicada para puertas de enlace VPN y ExpressRoute" -- GatewaySubnet "Permitir que un servicio PaaS inyecte su NIC en una subred" -- Subnet Delegation "Prevenir el agotamiento de puertos SNAT para salida a gran escala" -- NAT Gateway "Puertos SNAT por IP en un NAT Gateway" -- 64,512 por IP, se pueden asociar hasta 16 IPs "NAT Gateway vs Reglas de Salida de Load Balancer, cual tiene prioridad cuando ambas aplican?" -- NAT Gateway tiene precedencia "Comportamiento de entrada predeterminado de Standard Public IP" -- Denegado por defecto, el NSG debe permitirlo explicitamente "Que SKU admite IP publica redundante por zona?" -- Solo SKU Standard "Los bloques CIDR superpuestos entre dos VNets causan que?" -- El Peering de VNet queda bloqueado "Peering no transitivo, como resolver A-C sin Peering directo?" -- VNet hub con Gateway Transit y Use Remote Gateways "Requisito de Peering Dual-Stack" -- Ambos VNets deben tener asignado un espacio de direcciones IPv6
VNet = limite de aislamiento regional, NAT Gateway = grupo de SNAT saliente escalable, Subnet Delegation = permiso de inyeccion de NIC para servicios PaaS