Microsoft Azure: come ripristinare la connettività delle VM senza IP pubblico dopo il ritiro del “Default Outbound Access”

Microsoft ha annunciato che, a partire dal 30 settembre 2025, il Default Outbound Access per le macchine virtuali in Azure verrà ritirato. In altre parole, le nuove VM non disporranno più automaticamente di un indirizzo IP pubblico implicito per accedere a Internet.

Questa modifica, che può sembrare secondaria, avrà in realtà un impatto concreto su molte configurazioni, soprattutto su quelle VM che oggi comunicano con l’esterno senza un IP pubblico assegnato.

In questo articolo vedremo cosa cambia, perché Microsoft ha scelto questa strada e come potete ripristinare o mantenere la connettività in uscita per le vostre VM in modo sicuro e controllato.

Cosa significa “Default Outbound Access”

Quando create una macchina virtuale in Azure senza assegnarle un IP pubblico o senza specificare un meccanismo di uscita, la piattaforma assegna automaticamente un indirizzo IP gestito internamente. Questo indirizzo consente alla VM di iniziare connessioni verso Internet o verso endpoint pubblici Microsoft (ad esempio per gli aggiornamenti di sistema o per i servizi dell’Azure Agent).

Questo comportamento, chiamato Default Outbound Access, è sempre stato comodo ma anche piuttosto opaco: l’indirizzo pubblico non era visibile, non era controllabile e poteva cambiare in qualsiasi momento.

Con la nuova policy, Microsoft disattiverà progressivamente questa modalità “implicita”. Le motivazioni sono legate alla sicurezza e alla coerenza con il modello secure by default: ogni risorsa deve dichiarare esplicitamente come comunica con l’esterno, in linea con i principi di Zero Trust.

Cosa cambia a partire dal 30 settembre 2025

Dal 30 settembre 2025 le nuove VM create in subnet che non dispongono di un metodo di egress esplicito non avranno più connettività verso Internet.

Le VM esistenti, invece, continueranno a funzionare come prima, a condizione che rimangano all’interno della stessa rete virtuale. Tuttavia, Microsoft raccomanda di migrare comunque a soluzioni esplicite: questo vi permetterà di mantenere il controllo sull’indirizzo IP sorgente, garantire stabilità e prevenire interruzioni future.

Inoltre, a partire dal 31 marzo 2026, tutte le nuove Virtual Network verranno create con l’impostazione defaultOutboundAccessEnabled = false per impostazione predefinita. In pratica, i subnet saranno completamente “privati” e non avranno più la possibilità di utilizzare l’IP implicito.

Figura 1: Come e quando viene consentito il default outbound access

Come ripristinare la connettività in uscita

Per mantenere la connettività Internet delle vostre VM senza assegnare un IP pubblico diretto, dovrete configurare un metodo esplicito di uscita.
Le opzioni principali sono tre:

  • Public IP assegnato direttamente alla VM: è la soluzione più semplice, ma espone la macchina e non è consigliata in ambienti di produzione.
  • Standard Load Balancer con regole outbound: centralizza l’uscita per più VM, ma richiede una configurazione accurata.
  • NAT Gateway, che rappresenta la scelta ideale nella maggior parte dei casi, grazie alla semplicità di gestione, all’alta disponibilità e alla scalabilità.

Figura 2: Opzioni esplicite per consentire il traffico in uscita

Come configurare un NAT Gateway per le vostre VM

Molti ambienti moderni scelgono il NAT Gateway perché consente di mantenere le VM completamente private e allo stesso tempo garantisce loro la possibilità di uscire verso Internet con un indirizzo pubblico dedicato e stabile.

Per creare e configurare un NAT Gateway potete utilizzare il portale di Azure, seguendo la procedura guidata che consente di associare al gateway uno o più indirizzi IP pubblici e di collegarlo al subnet che ospita le vostre macchine virtuali.

Trovate una descrizione completa, con immagini e passaggi dettagliati, nell’articolo  Azure NAT Gateway – Gestione del traffico in uscita dalle VM eseguite in Azure – ICT Power

Una volta completata la configurazione e associato il NAT Gateway al subnet corretto, sarà sufficiente arrestare e riavviare le VM per applicare la nuova rotta di uscita verso Internet. Da quel momento, tutto il traffico in uscita passerà attraverso il NAT Gateway, utilizzando l’indirizzo IP pubblico configurato, senza che le VM abbiano bisogno di un IP pubblico individuale.

Figura 3: NAT Gateway in Azure

Alcune attenzioni utili

Se le vostre VM accedono a Windows Update, ai repository Linux o a servizi di monitoraggio e backup, assicuratevi che le destinazioni siano raggiungibili attraverso il NAT Gateway o il firewall che avete configurato. Un errore di configurazione potrebbe impedire l’accesso a servizi essenziali o bloccare gli aggiornamenti automatici.

In ambienti ibridi o collegati tramite VPN, è fondamentale verificare le rotte di rete, per evitare che il traffico verso Internet venga instradato in modo errato o rimbalzi su percorsi non previsti.

Ricordate che l’utilizzo di un NAT Gateway o di altre soluzioni di egress controllato comporta un costo aggiuntivo, sia per la risorsa sia per il traffico in uscita. Si tratta però di costi prevedibili e trasparenti, che offrono in cambio un controllo completo sul comportamento della rete e una maggiore sicurezza operativa per le vostre VM.

Conclusioni

Il ritiro del Default Outbound Access è un passo importante verso un Azure più sicuro e coerente con i principi del cloud moderno. Significa dire addio a una funzionalità “magica” ma imprevedibile, e passare a un modello più esplicito e controllato, in cui siete voi a decidere come e con quale indirizzo le vostre macchine comunicano con l’esterno.

Vi consiglio di pianificare fin d’ora la migrazione verso NAT Gateway o un’altra modalità di egress, in modo da garantire continuità operativa alle vostre VM.