Power Automate HTTP: da oggi nuovi IP in uscita in Europa
Da oggi, 2 novembre 2026, i flussi cloud di Power Automate ospitati in Europa possono inviare le chiamate HTTP da un insieme di indirizzi IP più ampio di prima. Se un vostro gestionale, un ERP o un’API interna accetta traffico solo da IP autorizzati, alcuni flussi rischiano di fermarsi senza preavviso.
Cosa cambia da oggi
Microsoft ha comunicato nel Message Center (avviso MC1530594) un cambio di infrastruttura per le richieste HTTP in uscita dai flussi cloud. Riguarda quattro elementi precisi: l’azione HTTP, l’azione HTTP + Swagger, l’azione HTTP Webhook e il trigger HTTP Webhook, limitatamente alle chiamate che Power Automate fa al vostro servizio per iscriversi e disiscriversi.
Dopo il cambio, queste richieste possono partire da qualsiasi indirizzo compreso in tre service tag di Azure: LogicApps, PowerPlatformInfra e PowerPlatformPlex. Un service tag è un’etichetta che raggruppa gli intervalli di IP usati da un servizio Microsoft, aggiornata da Microsoft stessa. Le date sono il 2 novembre per l’Europa e il 9 novembre per gli Stati Uniti.
Restano fuori due casi. Le azioni e i trigger dei connettori standard continuano a usare il tag AzureConnectors. E le richieste che i vostri sistemi inviano a un flusso tramite il trigger “When an HTTP request is received” non sono toccate, perché lì il traffico va nella direzione opposta.
Il sintomo, quando qualcosa non va, è riconoscibile. Il flusso fallisce con un errore 502 (Bad Gateway), va in timeout, oppure il firewall del servizio chiamato risponde 403 (Forbidden).
Cosa significa in pratica
Prendo un caso che vedo spesso in logistica. Un flusso Power Automate legge gli ordini confermati dall’e-commerce e, con un’azione HTTP, li invia all’API del WMS (il software che gestisce il magazzino) installato nel data center aziendale. Anni fa qualcuno ha aperto il firewall solo verso una lista di IP copiata a mano da una pagina Microsoft. Fino a ieri funzionava.
Da oggi una parte delle chiamate può arrivare da indirizzi che quella lista non conosce. Il risultato più insidioso non è il blocco totale, ma il blocco intermittente. Alcuni ordini passano, altri no, e il magazzino si accorge del problema solo quando un corriere arriva per un collo che nessuno ha preparato.
Lo stesso vale per un CRM on premise, un server FTP dietro un gateway, un’API di fatturazione protetta da un web application firewall. Ovunque ci sia una lista di IP ammessi davanti a un servizio chiamato con l’azione HTTP.
Cosa controllare oggi
Le indicazioni di Microsoft sono chiare e le riassumo in tre passi.
- Fate l’inventario dei flussi che usano le azioni HTTP e annotate quali servizi chiamano. Per ognuno verificate se c’è un filtro sugli IP, compresi firewall, gateway e WAF.
- Autorizzate i tre service tag. Sulle risorse Azure che li accettano direttamente (network security group, restrizioni di accesso di App Service) basta aggiungerli alla regola. Sugli altri firewall servono gli intervalli di IP, presi dal file Azure IP Ranges and Service Tags o dalla Service Tag Discovery API, e vanno tenuti aggiornati.
- Dopo ogni modifica lanciate i flussi coinvolti e controllate che vadano a buon fine.
Se la vostra configurazione segue già la documentazione ufficiale sugli indirizzi IP di Power Automate, che da tempo indica tutti e tre i tag per le azioni HTTP, non dovete fare nulla. Microsoft precisa anche di aver avvisato le organizzazioni in cui ha rilevato flussi recenti con queste azioni, quindi vale la pena cercare il messaggio nel Message Center del vostro tenant.
Il mio punto di vista
Il cambio in sé è ragionevole. Allineare le richieste HTTP ai service tag rende l’infrastruttura più gestibile per Microsoft e, a regime, anche per chi amministra la rete. Il problema è un altro. Molte aziende italiane hanno firewall configurati anni fa con liste statiche, e chi le ha impostate spesso non lavora più lì. In questi casi nessuno collega un errore 502 di stamattina a un avviso del Message Center letto da un amministratore distratto.
C’è anche un limite strutturale da tenere a mente. Gli intervalli dei service tag cambiano nel tempo. Se il vostro firewall non li legge in automatico, aggiornarli a mano oggi risolve il problema solo fino al prossimo cambio. La soluzione seria è uno script o un flusso che scarica periodicamente gli intervalli e aggiorna le regole, oppure, dove possibile, spostare l’integrazione su un connettore personalizzato o su un gateway che non dipenda dagli IP.
Il punto più utile, secondo me, è usare questa scadenza come occasione per mappare quali flussi parlano con quali sistemi. È un’informazione che quasi nessuno ha in forma scritta, e ne avevo già parlato a proposito dei flow group e delle licenze Process, dove lo stesso inventario serve a capire i costi.
Prima di tutto, guardate la cronologia delle esecuzioni
Il consiglio operativo è semplice. Stamattina aprite la cronologia delle esecuzioni dei flussi che usano le azioni HTTP e filtrate per errori 502, 403 e timeout. Se compaiono da oggi, sapete già da dove partire.
Se non sapete con certezza quali flussi della vostra azienda chiamano sistemi interni, è il momento di scoprirlo. Prenota una call di 30 minuti e facciamo insieme la mappa dei flussi HTTP, così capiamo quali integrazioni proteggere prima che si fermi un ordine.