Azure Functions Flex Consumption: TLS end-to-end

Azure Functions Flex Consumption supporta ora in disponibilità generale i certificati TLS con ambito della singola app e la crittografia end-to-end. La novità, annunciata da Microsoft il 14 settembre 2026, interessa soprattutto le aziende che pubblicano API serverless su domini personalizzati, devono autenticarsi verso servizi esterni con un certificato client o vogliono ridurre i tratti di rete in cui il traffico viene gestito in chiaro dopo la terminazione TLS.

Non è però un interruttore da attivare senza progetto. Certificati, associazioni ai domini, accesso dal codice, rinnovi e dipendenze applicative devono essere inventariati e collaudati. Questa guida spiega cosa cambia in Azure Functions Flex Consumption, quali scenari diventano più semplici e quali controlli inserire prima della produzione.

Che cosa ha annunciato Microsoft

Il piano Flex Consumption per Azure Functions è un’offerta serverless Linux a consumo che combina scalabilità dinamica, scelta della memoria per istanza, integrazione con reti virtuali e opzioni di concorrenza per istanza. Microsoft lo indica come piano consigliato per i nuovi workload serverless basati su Consumption.

Il 14 settembre 2026 Microsoft ha portato in disponibilità generale due capacità collegate:

certificati TLS site-scoped, associati alla singola Function App nel piano Flex Consumption;
crittografia TLS end-to-end del traffico attraverso l’infrastruttura della Function App.

Il supporto ai certificati site-scoped era stato presentato in anteprima pubblica durante Build 2026. La disponibilità generale è quindi rilevante per i team che aspettavano uno stato più maturo prima di adottare la funzione nei servizi di produzione.

Certificati site-scoped: perché sono utili

“Site-scoped” significa che il certificato appartiene all’ambito della specifica Function App. Il modello è adatto a un piano serverless, nel quale non esiste un App Service Plan dedicato da usare come contenitore condiviso dei certificati. L’isolamento per app rende più chiara l’attribuzione della risorsa, ma non elimina la necessità di una gestione centralizzata del ciclo di vita.

Domini personalizzati e HTTPS

Il caso più immediato è una API esposta come api.azienda.it. Il dominio predefinito *.azurewebsites.net usa già un certificato amministrato dalla piattaforma; il nuovo supporto è utile quando l’azienda vuole presentare un proprio nome DNS e il relativo certificato. Come per App Service, il team deve verificare proprietà del dominio, binding TLS, catena di certificazione e rinnovo.

Certificati letti dall’applicazione

Alcuni workload non usano un certificato soltanto per ricevere HTTPS. Una funzione può dover presentare un certificato client a una API partner, firmare un documento o accedere a un sistema che richiede autenticazione basata su certificato. Microsoft documenta per App Service il caricamento di certificati PFX e l’accesso controllato dal codice; la nuova capacità porta questo modello anche a Flex Consumption.

La chiave privata resta un materiale sensibile. L’accesso deve essere limitato alla sola app che ne ha bisogno, registrato e inserito in un processo di rotazione. Se il certificato è distribuito tramite Azure Key Vault, conviene privilegiare identità gestite e permessi minimi, evitando segreti statici nelle impostazioni applicative.

Autenticazione reciproca TLS

Un altro scenario è il mutual TLS, nel quale anche il client presenta un certificato. È utile per integrazioni business-to-business, webhook ad alta criticità e canali machine-to-machine, ma non sostituisce automaticamente l’autorizzazione applicativa. Occorre validare emittente, scadenza, revoca e identità rappresentata dal certificato, quindi applicare i permessi coerenti alla richiesta.

Che cosa significa TLS end-to-end

In molte piattaforme cloud il TLS pubblico termina su un front-end gestito, che inoltra poi la richiesta al runtime. La protezione end-to-end estende la cifratura anche lungo il percorso interno verso l’applicazione. Per i workload che trattano dati riservati o devono documentare una difesa in profondità, ridurre i segmenti non cifrati semplifica l’analisi del rischio.

È importante non trasformare questa funzione in una promessa assoluta. TLS protegge i dati in transito, ma non corregge vulnerabilità nel codice, autorizzazioni eccessive, log contenenti dati personali o dipendenze compromesse. Il beneficio reale arriva quando la configurazione è combinata con identità gestite, segreti protetti, logging controllato, patching e segmentazione di rete.

Cosa cambia rispetto a prima

Esigenza	Prima	Con la disponibilità generale
HTTPS sul dominio predefinito	Già gestito dalla piattaforma	Nessun vantaggio diretto: resta gestito da Azure
Dominio personalizzato	Supporto più limitato nel modello Flex	Certificato associabile alla singola Function App
Certificato usato dal codice	Possibili architetture alternative o maggiore complessità	Scenario supportato tramite certificato site-scoped
Traffico interno verso il runtime	TLS terminato sul front-end	Possibilità di mantenere TLS lungo il percorso della funzione
Stato del servizio	Anteprima pubblica da Build 2026	Disponibilità generale dal 14 settembre 2026

Quando conviene adottare la nuova funzione

L’adozione è particolarmente sensata quando una Function App espone API con un dominio aziendale, integra partner tramite certificato client oppure rientra in un perimetro con requisiti stringenti sui dati in transito. È utile anche nelle migrazioni da App Service o da ambienti tradizionali nei quali i certificati erano già parte del contratto tecnico.

Se invece l’app usa soltanto l’hostname Azure, non carica certificati nel codice e tratta dati a basso rischio, il beneficio può essere limitato. In quel caso è più importante misurare la maturità complessiva del servizio: autenticazione, autorizzazione, dipendenze, osservabilità, costi e gestione degli errori.

Per confrontare il modello con altre scelte serverless, può essere utile l’approfondimento EP Consulting su AWS Lambda, Managed Instances, container e batch. Per i controlli crittografici a livello DNS si può invece consultare l’articolo su Cloudflare DNSSEC post-quantum.

Checklist prima di passare in produzione

Censire domini e certificati. Registrare proprietario, emittente, scadenza, ambiente, Function App e finalità di ogni certificato.
Separare gli usi. Non riutilizzare senza necessità lo stesso certificato per binding HTTPS, autenticazione client e firma.
Verificare il piano. La funzione riguarda Azure Functions Flex Consumption; controllare runtime, regione e configurazione effettiva dell’app.
Automatizzare il rinnovo. Definire alert prima della scadenza e una procedura testata di sostituzione senza interruzioni.
Proteggere le chiavi private. Limitare accesso dal codice, usare identità gestite dove possibile e non copiare PFX nei repository.
Provare il binding. Testare DNS, catena completa, hostname, versioni TLS e comportamento dei client più vecchi.
Collaudare mTLS. Verificare rifiuto dei certificati scaduti, non attendibili o revocati e non solo il percorso positivo.
Attivare end-to-end TLS in staging. Misurare latenza, errori e compatibilità prima di replicare la configurazione in produzione.
Controllare rete e scala. Se si usa l’integrazione VNet, verificare subnet, route, DNS privato, gateway e capacità sotto carico.
Preparare il rollback. Conservare configurazione precedente, criteri di uscita e responsabilità operative.

Rete, scalabilità e certificati vanno testati insieme

Flex Consumption può scalare dinamicamente fino a 1.000 istanze secondo la documentazione Microsoft. La scalabilità non rende però illimitate le risorse di rete circostanti. Con l’integrazione VNet, più app possono usare gateway condivisi della subnet; applicazioni numerose o con traffico intenso possono aumentare latenza e timeout. Un test che verifica solo il certificato con poche richieste non dimostra quindi il comportamento del sistema sotto picco.

La prova dovrebbe includere handshake TLS, apertura e riuso delle connessioni, dipendenze in uscita, timeout e rotazione del certificato mentre la funzione scala. È opportuno osservare separatamente errori di certificazione, risoluzione DNS, connessione e applicazione: aggregarli in un unico indicatore rende più lenta la diagnosi.

Errori da evitare

considerare il certificato un sostituto dell’autenticazione e dell’autorizzazione;
caricare la chiave privata in codice, repository o pipeline senza protezione;
dimenticare ambienti di test, slot o integrazioni partner nel piano di rinnovo;
abilitare mTLS senza una procedura per revoca e sostituzione dei certificati client;
confondere la disponibilità generale della funzione con la compatibilità automatica di ogni applicazione;
migrare un workload dal piano Consumption senza verificare differenze di rete, runtime, costo e scala.

FAQ su Azure Functions Flex Consumption e TLS

La novità serve anche per il dominio azurewebsites.net?

Il dominio predefinito è già protetto da un certificato gestito dalla piattaforma. I certificati site-scoped sono soprattutto rilevanti per domini personalizzati e scenari nei quali il certificato deve essere usato dall’applicazione.

La disponibilità generale significa che posso attivarla senza test?

No. Lo stato GA indica supporto per l’uso di produzione, ma binding, catena, client, DNS, rotazione e impatto sulle dipendenze restano responsabilità da verificare.

TLS end-to-end protegge anche i dati nei log?

No. Protegge il traffico in transito lungo il percorso configurato. Log, storage, telemetria e dati elaborati richiedono controlli separati.

Un certificato client sostituisce OAuth o le autorizzazioni?

Non necessariamente. Può autenticare il client o il canale, ma l’app deve ancora stabilire quali operazioni siano consentite a quell’identità.

È necessario migrare subito da un altro piano Azure Functions?

No. La migrazione va valutata sul workload. Microsoft fornisce una guida specifica dal piano Consumption a Flex Consumption; compatibilità, rete, prestazioni e costi devono essere verificati prima del passaggio.

Conclusione

La disponibilità generale dei certificati site-scoped e del TLS end-to-end colma un limite importante per chi vuole usare Flex Consumption in API e integrazioni aziendali. Il vantaggio non è soltanto “avere HTTPS”, già presente sul dominio Azure, ma poter gestire domini personalizzati e scenari basati su certificato mantenendo il modello serverless.

La scelta corretta parte da inventario, classificazione dei dati, prova in staging e automazione dei rinnovi. EP Consulting può affiancare l’azienda nella revisione di architettura, rete, identità e continuità operativa: scopri il servizio di consulenza IT.