Cambios en el acceso predeterminado de salida en Azure
Microsoft ha anunciado cambios relevantes en el comportamiento de red de Azure: después del 31 de marzo de 2026, las redes virtuales de Azure recién creadas dejarán de tener habilitado por defecto el acceso de salida predeterminado a Internet (Default Outbound Access, DOA).
Hasta ahora, muchos despliegues podían salir a Internet sin haber configurado explícitamente un mecanismo de egreso. Ese comportamiento resultaba cómodo, pero también podía ocultar dependencias de red y dificultar el control de seguridad. Con el nuevo modelo, el acceso de salida debe diseñarse y configurarse de forma explícita.
El cambio es especialmente importante para entornos como Azure Virtual Desktop (AVD), donde los hosts de sesión pueden necesitar conectividad saliente para integrarse con servicios de Azure, aplicar actualizaciones, activar Windows o acceder a dependencias externas.
Resumen rápido: si creas nuevas VNets después del 31 de marzo de 2026, no debes asumir que las máquinas virtuales tendrán salida a Internet automáticamente. Planifica un método explícito de salida, como Azure NAT Gateway, Azure Firewall u otra arquitectura de egreso controlado.
Qué es el acceso de salida predeterminado
El acceso de salida predeterminado es un comportamiento heredado de Azure que permitía que recursos dentro de una red virtual, como máquinas virtuales, pudieran iniciar conexiones salientes hacia Internet sin que el administrador hubiera configurado una ruta de egreso específica.
En la práctica, esto podía permitir que una VM sin IP pública propia, sin NAT Gateway, sin Azure Firewall y sin una regla de salida explícita en un balanceador, siguiera teniendo conectividad saliente mediante infraestructura administrada por Azure.
Ese acceso era útil para escenarios básicos, pero tenía varias limitaciones desde el punto de vista operativo:
- No era una arquitectura de egreso explícitamente diseñada.
- Podía generar dependencias no documentadas.
- Ofrecía menos control sobre la IP pública de salida.
- No era la opción más adecuada para entornos con requisitos de auditoría, seguridad o cumplimiento.
Qué cambia a partir del 31 de marzo de 2026
Después del 31 de marzo de 2026, las nuevas redes virtuales de Azure no tendrán habilitado el acceso de salida predeterminado de la misma forma que antes. Microsoft está orientando el comportamiento hacia un modelo más privado y explícito, donde las subredes pueden operar sin salida directa a Internet salvo que se configure un mecanismo adecuado.
Según la comunicación de Microsoft para clientes de Azure Virtual Desktop, las VNets existentes no deberían verse afectadas por este cambio y continuarán usando el método de conectividad que ya tengan configurado. El impacto principal está en nuevas redes virtuales y en despliegues que dependan de conectividad saliente implícita.
Importante: no conviene tratar este cambio como un simple ajuste de plataforma. Es una señal clara de que la conectividad saliente debe formar parte del diseño de red desde el inicio.
Impacto en Azure Virtual Desktop
En Azure Virtual Desktop, los hosts de sesión suelen requerir conectividad saliente para distintas operaciones, por ejemplo:
- Registro y comunicación con servicios de Azure Virtual Desktop.
- Actualizaciones del sistema operativo y componentes.
- Activación de Windows.
- Descarga de paquetes, agentes o dependencias autorizadas.
- Acceso a servicios corporativos o SaaS, según el diseño del entorno.
Si se crean hosts de sesión en una VNet nueva sin conectividad saliente explícita, pueden aparecer fallos durante el despliegue o problemas posteriores de operación y mantenimiento.
Para entornos AVD nuevos, la recomendación práctica es revisar el diseño de red antes de desplegar los hosts:
- Determinar qué subredes necesitan salida a Internet.
- Definir qué tráfico debe permitirse y hacia qué destinos.
- Elegir el mecanismo de egreso adecuado.
- Registrar y monitorizar la conectividad saliente.
- Validar el despliegue en un entorno de pruebas antes de producción.
Opciones habituales para configurar la salida a Internet
Azure ofrece varias formas de proporcionar conectividad saliente. La elección depende del nivel de control, seguridad, escalabilidad y coste que necesite cada arquitectura.
1. Azure NAT Gateway
Azure NAT Gateway es una opción recomendada para proporcionar salida a Internet desde una subred de forma explícita y escalable. Se asocia a una o varias subredes y utiliza una o varias direcciones IP públicas, o prefijos de IP pública, para realizar la traducción de direcciones de salida.
Es una buena opción cuando necesitas:
- Salida a Internet predecible desde cargas de trabajo privadas.
- Control de las IPs públicas usadas para el egreso.
- Evitar asignar IP pública directamente a cada VM.
- Una configuración sencilla para subredes con muchas instancias.
Aspectos a tener en cuenta:
- NAT Gateway proporciona conectividad saliente; no expone automáticamente servicios entrantes.
- Debe asociarse a las subredes que necesiten esa salida.
- Conviene revisar límites, costes y requisitos de IP pública antes de adoptarlo en producción.
Para muchos despliegues de máquinas virtuales y hosts de sesión, NAT Gateway será la opción más directa cuando solo se necesita salida controlada a Internet sin inspección avanzada del tráfico.
2. Azure Firewall
Azure Firewall permite centralizar y controlar el tráfico de red, incluyendo tráfico saliente. Es más adecuado cuando necesitas inspección, reglas de aplicación, filtrado, registros y una política de seguridad más avanzada.
Puede ser la opción adecuada si necesitas:
- Control granular por FQDN, aplicación o red.
- Registro centralizado de tráfico permitido y denegado.
- Integración con una arquitectura hub-and-spoke.
- Aplicación consistente de políticas de seguridad entre varias VNets.
Aspectos a considerar:
- Requiere un diseño de rutas adecuado, normalmente mediante tablas de rutas definidas por el usuario.
- Tiene un coste superior a opciones más simples como NAT Gateway.
- Debe dimensionarse y gobernarse como componente crítico de red.
En arquitecturas empresariales, Azure Firewall suele encajar mejor cuando la salida a Internet debe pasar por un punto de inspección y control común.
3. Direcciones IP públicas en recursos concretos
Otra posibilidad es asignar IP pública directamente a determinados recursos, como una máquina virtual o un balanceador. Esto puede ser válido en casos puntuales, pero no suele ser la primera opción para entornos grandes o con requisitos estrictos de seguridad.
Puede tener sentido cuando:
- El recurso necesita exposición pública directa.
- El patrón de conectividad es simple y acotado.
- Se trata de un entorno de laboratorio o una carga muy específica.
Riesgos y limitaciones:
- Aumenta la superficie de exposición si no se gobierna correctamente.
- Puede dificultar la gestión en despliegues con muchas máquinas.
- No sustituye a una estrategia de filtrado, segmentación y monitorización.
Para producción, especialmente en entornos corporativos, suele ser preferible separar claramente la necesidad de entrada y salida, y no asignar IPs públicas a recursos privados salvo que exista una razón justificada.
4. Conectividad privada y reducción de dependencias de Internet
No todo tráfico saliente tiene por qué ir a Internet. En muchos diseños, parte de las dependencias pueden resolverse mediante conectividad privada, por ejemplo usando servicios de Azure accesibles mediante red privada cuando el servicio lo permita.
Este enfoque ayuda a:
- Reducir exposición a Internet.
- Mejorar el control de rutas.
- Alinear el diseño con modelos de red privada.
- Limitar el tráfico saliente solo a lo estrictamente necesario.
Aun así, algunas cargas seguirán necesitando salida controlada a Internet para actualizaciones, repositorios, servicios externos o integraciones SaaS. Por eso conviene revisar dependencia por dependencia.
Qué revisar antes de crear nuevas VNets
Para evitar problemas después del cambio, es recomendable incorporar estas comprobaciones en los diseños de red y en las plantillas de despliegue:
1. Inventario de dependencias salientes
Identifica qué necesita salir a Internet y por qué. No basta con validar que “la VM tiene Internet”; conviene documentar:
- Servicios de Azure requeridos.
- Endpoints externos.
- Repositorios de paquetes.
- Servicios de actualización.
- Servicios SaaS corporativos.
- Dependencias de autenticación o gestión.
2. Método de egreso explícito
Define si la salida se hará mediante:
- NAT Gateway.
- Azure Firewall.
- Una NVA o dispositivo de red de terceros.
- Balanceador con reglas de salida, si aplica al diseño.
- IP pública en casos concretos y justificados.
La clave es que el método sea explícito, gobernado y reproducible.
3. Rutas y segmentación
Revisa las tablas de rutas, la segmentación por subredes y los grupos de seguridad de red. Un diseño habitual es separar:
- Subredes con salida controlada.
- Subredes privadas sin salida directa.
- Subredes dedicadas a componentes de inspección o seguridad.
- Subredes de gestión o servicios compartidos.
4. Observabilidad
La conectividad saliente debe poder auditarse. Dependiendo de la solución elegida, revisa la disponibilidad de:
- Logs de firewall.
- Métricas de NAT Gateway.
- Network Watcher.
- Flow logs, si aplican al escenario.
- Alertas de conectividad o consumo anómalo.
5. Automatización
Si usas Bicep, ARM, Terraform, Azure CLI o pipelines de despliegue, revisa que las plantillas no dependan del acceso saliente implícito. El cambio puede afectar a módulos reutilizables que creaban VNets y subredes sin declarar explícitamente el mecanismo de egreso.
Recomendaciones prácticas
Para arquitectos y equipos de plataforma, estas son las acciones más importantes:
- No depender del acceso de salida predeterminado en nuevos diseños.
- Actualizar patrones de landing zones y plantillas para incluir conectividad saliente explícita cuando sea necesaria.
- Usar NAT Gateway cuando se necesite salida simple, escalable y predecible desde subredes privadas.
- Usar Azure Firewall o una solución equivalente cuando se requiera inspección, filtrado avanzado y registro centralizado.
- Evitar IPs públicas innecesarias en máquinas virtuales.
- Probar despliegues de Azure Virtual Desktop en VNets nuevas antes de llevarlos a producción.
- Documentar las dependencias de salida para no descubrirlas durante una incidencia.
Conclusión
El cambio en el acceso de salida predeterminado de Azure refuerza una práctica que ya era recomendable: diseñar la conectividad saliente de forma explícita, segura y observable.
Para entornos nuevos, especialmente si incluyen Azure Virtual Desktop, máquinas virtuales o cargas que necesitan actualizaciones y servicios externos, ya no es prudente asumir que la VNet proporcionará salida a Internet automáticamente. La arquitectura debe declarar cómo se produce esa salida, qué destinos están permitidos y cómo se audita el tráfico.
La transición puede requerir ajustes en plantillas, landing zones y procedimientos de despliegue, pero también ofrece una oportunidad para mejorar el control de red, reducir exposición innecesaria y alinear los entornos de Azure con principios de seguridad más estrictos.
Fuente consultada
- Microsoft Community Hub: Azure’s Default Outbound Access Changes: Guidance for Azure Virtual Desktop Customers