El 30 de septiembre de 2025 Microsoft retiró el acceso saliente por defecto en Azure. Si tienes máquinas virtuales desplegadas sin configuración explícita de salida, este artículo es para ti.

Qué es el default outbound access y por qué existe

Cuando despliegas una VM en Azure dentro de una red virtual sin definir explícitamente cómo va a salir el tráfico a internet, Azure te lo resuelve solo. Asigna a esa máquina una IP pública temporal propiedad de Microsoft, no tuya y la usa para SNAT (Source Network Address Translation). Tus paquetes salen, llegan a su destino, y tú ni te enteras. Cómodo. Hasta que deja de serlo.

Eso es exactamente el default outbound access: un comportamiento implícito de la plataforma que durante años ha servido de red de seguridad para VMs sin configuración de red explícita. Microsoft lo ofrece para no dejar colgado al desarrollador que levanta una VM para probar algo rápido. El problema es que mucha gente lo usa en producción sin saberlo.

Figura: Métodos explícitos de conectividad saliente en Azure (fuente: learn.microsoft.com)

Por qué Microsoft lo retira y tiene razón

Tres razones concretas. La primera es seguridad: el acceso saliente automático choca frontalmente con los principios Zero Trust. Una máquina que puede conectarse a internet sin que nadie lo haya decidido explícitamente es una superficie de ataque. Punto.

La segunda razón es la estabilidad. La IP que Azure asigna para el default outbound no es tuya es de Microsoft y puede cambiar sin previo aviso. Cualquier regla de firewall de destino basada en esa IP deja de funcionar el día que cambia. ¿Te suena haber visto problemas intermitentes de conectividad saliente en producción que nadie sabía explicar? A veces es esto.

La tercera: consistencia. Si tienes Scale Sets y escalas horizontalmente, cada nueva instancia puede obtener una IP diferente. Si tienes VMs con varias NICs, el comportamiento puede ser distinto por NIC. Y encima, el default outbound no soporta paquetes fragmentados ni pings ICMP. Total, que es un mecanismo con demasiados bordes raros para confiarle tráfico real.

Figura: Árbol de decisión para determinar cuándo se proporciona default outbound access (fuente: learn.microsoft.com)

La fecha que tienes que tener en la cabeza

El 30 de septiembre de 2025 fue la fecha de retirada oficial. Desde entonces, cualquier VM nueva que despliegues en una subnet que no tenga configuración explícita de salida puede quedarse sin conectividad a internet. Además, Microsoft ha dado un paso más: a partir de la versión de API publicada después del 31 de marzo de 2026, las nuevas redes virtuales crean subnets privadas por defecto es decir, con defaultOutboundAccess establecido a false de serie.

Ojo con esto: las VNETs existentes no cambian automáticamente. Las VMs que ya tienes en marcha siguen funcionando como hasta ahora, porque Microsoft no toca lo que ya existe. Pero las nuevas VMs en VNETs nuevas sí se ven afectadas. Y si alguien en tu equipo despliega una VNET desde cero sin tenerlo en cuenta, puede llevarse una sorpresa.

Los tres métodos explícitos para sustituirlo

Microsoft documenta cuatro alternativas (incluyendo NVA/Firewall con UDR), pero las tres más habituales para arquitecturas estándar son estas:

NAT Gateway la opción recomendada para la mayoría

Azure NAT Gateway es un servicio totalmente gestionado que proporciona conectividad saliente a todas las VMs de una subnet. Lo asocias a la subnet, le asignas una o varias IPs públicas (hasta 16 por gateway), y listo: toda la subnet sale a internet con esas IPs de forma estática y predecible.

La gran ventaja frente al resto es que gestiona los puertos SNAT de forma dinámica y automática, lo que elimina prácticamente el riesgo de SNAT port exhaustion — un problema real cuando tienes muchas conexiones salientes simultáneas. Aguanta hasta 50 Gbps de throughput (100 Gbps con la SKU StandardV2) y no requiere ninguna configuración de rutas adicional. Simplemente se asocia a la subnet y ya toma precedencia sobre cualquier otro método.

La SKU StandardV2, además, es zone-redundant opera desde todas las zonas de disponibilidad de la región y soporta IPv6. Si vas a desplegar algo nuevo hoy, StandardV2 es lo que tiene más futuro.

Para configurarlo son básicamente tres pasos:

# 1. Crear el NAT Gateway
az network nat gateway create \
–resource-group <rg> \
–name <nat-gw-name> \
–location <region> \
–public-ip-addresses <public-ip-name>

# 2. Asociar el NAT Gateway a la subnet
az network vnet subnet update \
–resource-group <rg> \
–vnet-name <vnet-name> \
–name <subnet-name> \
–nat-gateway <nat-gw-name>

# 3. (Opcional) Marcar la subnet como privada para evitar default outbound
az network vnet subnet update \
–resource-group <rg> \
–name <subnet-name> \
–vnet-name <vnet-name> \
–default-outbound false

Figura: NAT Gateway como método principal de conectividad saliente (fuente: learn.microsoft.com)

Standard Load Balancer con outbound rules

Si ya tienes un Standard Load Balancer delante de tus VMs, puedes configurar outbound rules para que las instancias del backend pool usen las IPs frontend del balanceador para el tráfico saliente. Es una opción válida, especialmente si ya tienes el LB desplegado y quieres evitar coste adicional de un NAT Gateway.

El punto débil aquí es la gestión de puertos SNAT. Con outbound rules tienes que calcular y asignar manualmente los puertos por instancia para evitar exhaustion. La fórmula es sencilla: número de IPs frontend por 64.000 dividido entre el número de instancias en el backend. Si el pool crece sin que hayas ajustado la asignación, las instancias nuevas pueden quedarse sin puertos suficientes y empezar a fallar conexiones salientes.

Microsoft lo clasifica como ‘OK, pero no a escala’. Para workloads donde el número de VMs es estable y controlado, funciona bien. Para entornos que escalan mucho o de forma impredecible, NAT Gateway se lleva la partida.

IP pública asociada directamente a la VM

La opción más directa: asignas una IP pública Standard SKU a la NIC de la VM. El tráfico saliente usa esa IP sin pasar por SNAT. Es una relación 1:1, así que la VM tiene todos los puertos efímeros disponibles para ella sola.

Útil para VMs individuales con requisitos específicos de IP saliente por ejemplo, si un proveedor externo necesita que la petición venga siempre de la misma IP estática y es una sola máquina. Pero escalar esto a un parque de VMs grande es costoso y difícil de mantener. No es la solución para casos generales.

Figura: Comparativa de métodos de conectividad saliente en Azure, ordenados por prioridad (fuente: learn.microsoft.com)

Cómo detectar las VMs afectadas y hacer la transición

Lo primero es saber qué tienes. Azure Advisor te lo pone fácil: busca en el portal la recomendación de Operational Excellence llamada ‘Add explicit outbound method to disable default outbound’ (hay una variante separada para Virtual Machine Scale Sets). Esa recomendación lista exactamente las NICs de las VMs que siguen usando el default outbound access.

Alternativamente, puedes usar el parámetro defaultOutboundConnectivityEnabled a nivel de NIC para identificarlas programáticamente. El portal ya muestra un banner de aviso en las VMs afectadas.

Una vez identificadas, el flujo de migración recomendado es:

Paso 1: Configura el método explícito de salida (NAT Gateway recomendado)
→ Crea el NAT Gateway y asócialo a la subnet de las VMs afectadas

Paso 2: Marca la subnet como privada
→ Esto evita que se generen nuevas IPs de default outbound
az network vnet subnet update \
–resource-group <rg> –name <subnet> \
–vnet-name <vnet> –default-outbound false

Paso 3: Stop/deallocate + start de las VMs afectadas
→ OBLIGATORIO para que el cambio de subnet se aplique a la NIC
az vm deallocate –resource-group <rg> –name <vm-name>
az vm start –resource-group <rg> –name <vm-name>

Paso 4: Verifica que el banner/alerta ha desaparecido en Azure Advisor

Un detalle que la documentación sí menciona pero que es fácil pasar por alto: el stop/deallocate es obligatorio. No basta con reiniciar la VM — hay que desasignarla completamente para que el cambio de configuración de la subnet se refleje en el parámetro de la NIC. Si no lo haces, la VM puede seguir mostrando el flag de default outbound incluso después de haber asociado el NAT Gateway.

Y si usas ARM templates o Terraform: ojo con la versión de API. Las plantillas que especifican versiones anteriores a la de marzo de 2026 siguen dejando defaultOutboundAccess como null, lo que permite el acceso implícito. Actualiza tus templates para incluir explícitamente defaultoutboundaccess: false en la definición de subnet.

# Fragmento ARM Template — subnet con default outbound deshabilitado
«subnets»: [
{
«name»: «my-subnet»,
«properties»: {
«addressPrefix»: «10.1.0.0/24»,
«defaultoutboundaccess»: false
}
}
]

Si tienes que recorrer todas las subnets de una VNET de forma masiva, este bloque de PowerShell del equipo de producto te ahorra trabajo:

$resourceGroupName = «<rg>»
$vnetName = «<vnet>»

$vnet = Get-AzVirtualNetwork -ResourceGroupName $resourceGroupName -Name $vnetName

foreach ($subnet in $vnet.Subnets) {
if ($subnet.DefaultOutboundAccess -eq $null) {
$subnet.DefaultOutboundAccess = $false
Write-Output «Marcada como privada: $($subnet.Name)»
} elseif ($subnet.DefaultOutboundAccess -eq $false) {
Write-Output «Ya era privada: $($subnet.Name)»
}
}
Set-AzVirtualNetwork -VirtualNetwork $vnet

Qué hacer ya — sin rodeos

La fecha de retirada ya pasó. Pero el impacto práctico en infraestructura existente se irá notando gradualmente no fue un corte abrupto para lo que ya existe. Lo que sí es inmediato es el nuevo comportamiento en despliegues nuevos. Aquí van las acciones concretas ordenadas por prioridad:

Primero, revisa Azure Advisor esta semana. Busca las recomendaciones de Operational Excellence relacionadas con default outbound access. Si aparecen NICs en la lista, tienes trabajo pendiente.

Segundo, despliega NAT Gateway en las subnets afectadas. Es el método recomendado por Microsoft para la mayoría de casos y elimina de raíz el problema de SNAT exhaustion. Coste: unos pocos euros al mes por gateway más el coste de procesamiento de datos.

Tercero, marca las subnets como privadas y haz stop/deallocate de las VMs. En ese orden. Después levántalas y verifica en Azure Advisor que el aviso ha desaparecido.

Cuarto y esto es para el equipo de plataforma o DevOps — actualiza vuestras plantillas de IaC (ARM, Bicep, Terraform) para que las nuevas subnets nazcan privadas por defecto y con un NAT Gateway ya asociado. Así te aseguras de que cualquier nuevo despliegue nace bien configurado desde el primer momento.

Pero hay un escenario que merece mención especial: si tienes un backend pool de Load Balancer configurado por dirección IP (no por NIC), ojo la documentación oficial advierte que en ese caso las VMs siguen usando default outbound access aunque tengas el LB configurado. La solución ahí es asociar un NAT Gateway a las VMs del pool. Es un known issue documentado, no un error tuyo.

Para cerrar

El default outbound access fue útil durante años como mecanismo de fallback. Pero ya no tiene cabida en arquitecturas que quieran cumplir con Zero Trust, tener comportamiento predecible y no sufrir sorpresas de conectividad. Microsoft lleva tiempo avisando las primeras alertas en Azure Advisor llevan activas bastante tiempo y ahora la retirada ya es efectiva en nuevos despliegues.

NAT Gateway resuelve el problema de forma limpia, sin configuración de rutas, con IPs estáticas predecibles y sin riesgo de exhaustion de puertos. Para la mayoría de arquitecturas en Azure es la respuesta correcta. Si ya tienes Load Balancer y el parque de VMs es pequeño y estable, las outbound rules también funcionan pero con NAT Gateway duermes más tranquilo.

El movimiento ahora mismo es claro: audita, configura el método explícito, marca las subnets como privadas y actualiza las plantillas. Cuanto antes lo hagas, menos riesgo de que alguien en tu equipo despliegue algo nuevo y se encuentre con que no tiene conectividad saliente y no sabe por qué.

Fuentes

• Default Outbound Access en Azure https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/default-outbound-access
• SNAT para conexiones salientes con Azure Load Balancer — https://learn.microsoft.com/en-us/azure/load-balancer/load-balancer-outbound-connections
• Qué es Azure NAT Gateway https://learn.microsoft.com/en-us/azure/nat-gateway/nat-overview
• Anuncio oficial de retirada https://azure.microsoft.com/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/