Microsoft Azure: nuevas subnets privadas por defecto y cambios en la salida a Internet

Microsoft Azure incorporó un cambio relevante en el comportamiento por defecto de nuevas redes virtuales y subnets. A partir de las versiones de API posteriores al 31 de marzo de 2026, las nuevas VNETs pasan a crearse con subnets privadas por defecto, lo que modifica la forma en que las máquinas virtuales acceden a Internet.

El punto central es claro: las VMs nuevas ya no deberían asumir salida automática a Internet, si no existe un método de conectividad outbound explícitamente configurado.

Este cambio puede generar impacto operativo en nuevos despliegues, especialmente cuando los equipos cloud, infraestructura o DevOps trabajan con templates, automatizaciones o pipelines que dependen de conectividad saliente sin declararla de forma explícita.

Por eso, dentro de las actualizaciones de Microsoft Azure, esta no debería leerse como una novedad menor. Es una señal concreta de hacia dónde evoluciona la administración cloud: menos comportamientos implícitos, más control sobre la conectividad y mayor trazabilidad del tráfico saliente.

Qué cambió en Microsoft Azure

Hasta ahora, cuando una máquina virtual se desplegaba sin un método explícito de conectividad outbound. Ese comportamiento se conoce como default outbound access y permitía que ciertos recursos alcanzaran Internet o endpoints públicos de Microsoft sin una configuración adicional definida por el cliente.

Este modelo antiguo presentaba limitaciones como:

• Inseguridad: El tráfico saliente no se podía auditar ni filtrar fácilmente.
• Agotamiento de puertos: Sufría bloqueos constantes por agotamiento de puertos SNAT bajo cargas altas.
• Falta de control: Las empresas no podían replicar la misma IP para listas blancas externas.

Con las versiones de API posteriores al 31 de marzo de 2026, la propiedad defaultOutboundAccess para las subnets de nuevas redes virtuales se establece en false de forma predeterminada. Esto hace que esas subnets sean privadas por defecto e impide la generación automática de direcciones IP salientes predeterminadas para las máquinas virtuales ubicadas en ellas.

En términos operativos, el cambio obliga a revisar un supuesto habitual: crear una VM no implica necesariamente que esa VM pueda salir a Internet.

Esto no significa que las VMs nuevas no puedan conectarse a Internet. Significa que, si necesitan hacerlo, la salida debe estar diseñada y configurada de manera explícita.

A quién afecta este cambio y a quién no

Uno de los puntos más importantes es evitar una lectura alarmista. Este cambio no rompe de forma inmediata los entornos existentes.

Según Microsoft, no se realizan cambios sobre redes virtuales existentes. Eso significa que las máquinas virtuales ya desplegadas y las nuevas VMs creadas dentro de esas VNETs pueden seguir generando direcciones IP salientes predeterminadas, salvo que las subnets sean modificadas manualmente para volverse privadas.

En términos prácticos, este cambio :

• No afecta automáticamente a VNETs existentes.
• No afecta automáticamente a VMs existentes.
• No cambia el comportamiento de nuevas VMs creadas dentro de VNETs existentes, salvo modificación manual de la subnet.
• Sí aplica a nuevas VNETs/subnets creadas bajo el nuevo comportamiento por defecto.
• Sí puede impactar despliegues nuevos que asumían salida automática a Internet.

Este último punto es el más relevante para equipos de infraestructura, cloud, seguridad y DevOps.

Muchas organizaciones tienen procesos de despliegue construidos sobre supuestos que funcionan “porque siempre funcionaron”. Pero cuando la plataforma cambia un comportamiento por defecto, esos supuestos pueden convertirse en puntos de falla.

Por qué puede generar impacto operativo

El impacto no aparece por el cambio en sí, sino por no contemplarlo.

Una VM nueva sin salida a Internet puede afectar tareas básicas de operación: descargar actualizaciones, instalar paquetes, conectarse a repositorios, consumir APIs externas o comunicarse con determinados servicios SaaS.

Microsoft señala que algunos servicios no funcionan en una VM ubicada en una subnet privada sin un método explícito de conectividad outbound. Entre los ejemplos menciona Windows Activation y Windows Updates.

Esto puede generar fricción en escenarios como:

• Despliegues de nuevas máquinas virtuales.
• Ejecución de scripts de configuración inicial.
• Pipelines de CI/CD.
• Conexión con repositorios externos.
• Actualizaciones de sistemas operativos.
• Instalación de agentes de monitoreo, backup o seguridad.
• Integraciones con APIs o servicios de terceros.

En organizaciones con ambientes híbridos o múltiples equipos gestionando infraestructura, estos problemas pueden ser difíciles de diagnosticar. La VM se crea correctamente. La red existe. La subnet está disponible. Pero ciertos procesos fallan porque el acceso outbound ya no está disponible de forma automática.

Por eso, la revisión no debería limitarse al área de networking. También involucra arquitectura cloud, seguridad, operación, automatización y gobierno tecnológico.

Qué recomienda Microsoft para mantener conectividad

La recomendación principal es pasar de un modelo implícito a un método explícito de salida.

Microsoft menciona distintas alternativas: Azure NAT Gateway, reglas outbound de Azure Load Balancer, una IP pública asociada directamente a la VM o un firewall/NVA con rutas definidas por el usuario. Sin embargo, para la mayoría de los escenarios, Microsoft recomienda asociar una instancia de Azure NAT Gateway a la subnet de la máquina virtual.

Azure NAT Gateway permite que los recursos privados dentro de una subnet tengan conectividad outbound hacia Internet sin habilitar conexiones entrantes no solicitadas desde Internet. Además, proporciona conectividad saliente a nivel de subnet y permite trabajar con IPs públicas controladas por la organización.

Desde una mirada empresarial, esto aporta tres beneficios relevantes:

• mayor control sobre cómo las VMs se conectan a endpoints públicos;
• uso de recursos de IP trazables y administrados por la organización;
• menor dependencia de IPs salientes predeterminadas que pueden cambiar.

La decisión técnica, sin embargo, no debería tomarse de forma aislada. La salida a Internet debe definirse según criticidad del workload, políticas de seguridad, modelo operativo y requerimientos de trazabilidad.

Qué deberían revisar los equipos IT antes de nuevos despliegues

Para evitar sorpresas, este cambio debería incorporarse al proceso de revisión de arquitectura cloud.

No alcanza con saber que Microsoft Azure modificó un comportamiento por defecto. Es necesario identificar dónde ese comportamiento estaba siendo asumido por la operación.

Los equipos IT deberían revisar:

• revisión de arquitectura Azure;
• análisis de VNETs, subnets y conectividad outbound;
• identificación de workloads que dependen de salida a Internet;
• evaluación de templates, automatizaciones y pipelines;
• definición de un baseline de conectividad para nuevos despliegues;
• implementación de Azure NAT Gateway u otros métodos según necesidad;
• integración con criterios de seguridad, continuidad y operación.

La revisión debería responder una pregunta concreta: ¿la conectividad outbound está declarada explícitamente o sigue dependiendo de un comportamiento por defecto?

El objetivo no es habilitar Internet para todo. Es definir qué necesita salida, por qué la necesita, desde dónde sale y bajo qué controles.

Algunos ejemplos de conectividad de salida explícita para máquinas virtuales son:

• Implementado en una subred asociada a una puerta de enlace NAT.
• Implementado en el grupo de back-end de un equilibrador de carga estándar con reglas de salida definidas.
• Implementado en el grupo de back-end de un equilibrador de carga público básico.
• Máquinas virtuales con direcciones IP públicas asociadas explícitamente a ellas.

Esa diferencia separa una configuración funcional de una arquitectura gobernada.

Cómo puede acompañar Wezen en este tipo de actualizaciones de Microsoft Azure

Las actualizaciones de Microsoft Azure no solo incorporan nuevas funcionalidades. También pueden modificar comportamientos operativos que los equipos ya tenían incorporados en sus procesos de despliegue.

Por eso, el valor no está únicamente en conocer el cambio. Está en entender cómo impacta en la arquitectura real de cada organización.

Desde una mirada estratégica, Wezen puede acompañar a las empresas en la revisión de su infraestructura cloud para identificar dependencias, validar configuraciones y definir patrones de conectividad más seguros y gobernados.

La clave es anticiparse. Porque un cambio de plataforma no siempre genera impacto por sí mismo. El riesgo aparece cuando la infraestructura no está preparada para absorberlo.

Preguntas frecuentes sobre el cambio en Microsoft Azure

¿Qué cambia en Microsoft Azure desde marzo de 2026?

Las nuevas VNETs pasan a utilizar subnets privadas por defecto, por lo que las VMs ya no tendrán salida automática a Internet sin un método explícito.

¿El cambio afecta VNETs o VMs existentes?

No. Microsoft indica que no modifica automáticamente redes virtuales existentes ni VMs ya desplegadas.

¿Qué pasa si una VM nueva necesita acceso a Internet?

Debe configurarse conectividad outbound explícita, por ejemplo mediante Azure NAT Gateway, Load Balancer outbound rules o IP pública directa.

¿Por qué Microsoft recomienda Azure NAT Gateway?

Porque permite salida controlada a nivel de subnet, con IPs administradas por la organización y sin habilitar conexiones entrantes no solicitadas.

¿Qué deberían revisar los equipos IT?

Templates, pipelines, versiones de API, dependencias externas, actualizaciones, agentes y patrones de conectividad outbound para nuevos despliegues.

Anticiparse a los cambios de Microsoft Azure también es parte de la estrategia cloud

Este cambio en Microsoft Azure no debe leerse como una urgencia aislada. Es parte de una tendencia más amplia: entornos cloud más seguros, explícitos y gobernados.

Anticiparse a las actualizaciones de Microsoft Azure permite mantener control operativo, reducir riesgos y construir una infraestructura cloud más preparada para crecer.

Evalúa si tu infraestructura en Azure está preparada para este cambio. Escríbenos.

Imagen: generada por IA (DALL·E 3 – GPT-4o), OpenAI, 2026.

Fuentes consultadas:

• Microsoft. (2026). Actualizaciones de Azure: Default outbound access for VMs in Azure will be retired. Microsoft Azure. URL
• Microsoft. (2026). Acceso saliente predeterminado en Azure. Microsoft Learn. URL
• Microsoft. (2026). What is Azure NAT Gateway? Microsoft Learn. URL