En Azure una subred tradicionalmente tiene un solo prefijo de direcciones, parte del espacio de direcciones de la red virtual VNet, y funciona bien hasta que las cargas de trabajo superan las IP disponibles.
Cuando eso ocurre la solución clásica consistía en crear una nueva subred y mover recursos, con el posible coste de interrupciones. Azure ha introducido la posibilidad de subredes con múltiples prefijos que permite ampliar capacidad sin redeploy y sin tiempo de inactividad, ideal para despliegues stateful o a gran escala como Virtual Machine Scale Sets VMSS.
Ejemplo práctico: una aplicación que requiere Azure SQL Database, un balanceador de carga y entre 10 y 15 máquinas virtuales se despliega con VMSS en modo flexible. Se crea una VNet con prefijo 192.168.0.0/24 y dos subredes: una para el endpoint privado de la base de datos 192.168.0.0/29 y otra para VMSS y LB 192.168.0.128/27. Al anunciarse la campaña de marketing es necesario multiplicar por seis la capacidad, lo que exige al menos 90 instancias VMSS y un prefijo /25 o mejor un /24 para no tener problemas al escalar.
Hay dos caminos: crear una nueva subred y migrar VMSS con el consiguiente downtime, o aprovechar la nueva funcionalidad y añadir un nuevo prefijo a la subred existente. La segunda opción evita interrupciones y es compatible hoy mediante PowerShell, Azure CLI, plantillas ARM y Bicep; el portal de Azure no soporta esta operación.
Pasos generales con PowerShell: actualizar el módulo Az, recuperar la VNet, añadir el nuevo prefijo al address space del VNet y después añadir ese prefijo a la configuración de la subred existente. Por ejemplo comandos clave: Update-Module -Name Az -Force $vnet = Get-AzVirtualNetwork -Name VNetName -ResourceGroupName ResourceGroupName $vnet.AddressSpace.AddressPrefixes.Add(192.168.1.0/24) Set-AzVirtualNetwork -VirtualNetwork $vnet Set-AzVirtualNetworkSubnetConfig -Name APP -VirtualNetwork $vnet -AddressPrefix 192.168.0.128/27,192.168.1.0/24 $vnet | Set-AzVirtualNetwork
Si prefieres infraestructura como código, en ARM y Bicep debes usar la propiedad addressPrefixes que acepta un array de bloques CIDR y emplear una versión de la API moderna que soporte esa propiedad. No mezcles addressPrefix y addressPrefixes en la misma definición de recurso.
Aspectos a considerar y restricciones: Azure reserva las primeras tres direcciones disponibles de cada prefijo para uso interno. No se admite delegación de subred salvo para gateways VPN y ExpressRoute. Tampoco se permite VNet injection para servicios de contenedores. La funcionalidad está pensada principalmente para cargas IaaS como VM y VMSS. Como buena práctica planifica el crecimiento desde el inicio definiendo addressPrefixes como array en tus plantillas.
En Q2BSTUDIO ayudamos a planificar y ejecutar este tipo de ampliaciones en entornos cloud, asegurando despliegues sin impacto y optimizados para escalado. Somos una empresa de desarrollo de software a medida y aplicaciones a medida, especialistas en inteligencia artificial y servicios cloud aws y azure, con experiencia en ciberseguridad y pentesting. Si necesitas migrar o ampliar subredes, o integrar soluciones de inteligencia artificial para tu empresa, consulta nuestros servicios cloud y de IA: servicios cloud aws y azure y inteligencia artificial y IA para empresas.
Además ofrecemos servicios de servicios inteligencia de negocio, agentes IA, power bi, ciberseguridad y automatización para que tu proyecto crezca sin sorpresas. Contacta con Q2BSTUDIO para diseñar redes y arquitecturas escalables que soporten software a medida, iniciativas de IA y soluciones seguras en la nube.