Opzioni di hosting di Funzioni di Azure

Articolo
2025-02-25

Quando si crea un'app per le funzioni in Azure, è necessario scegliere un'opzione di hosting per l'app. Azure offre le opzioni di hosting seguenti per il codice della funzione:

Opzione Hosting	Servizio	Disponibilità	Supporto dei contenitori
Piano A consumo Flex	Funzioni di Azure	Disponibilità Generale	Nessuno
Piano Premium	Funzioni di Azure	Disponibilità generale	Linux
Piano dedicato	Funzioni di Azure	Disponibilità generale	Linux
App contenitore	App contenitore di Azure	Disponibilità generale	Linux
Piano a consumo	Funzioni di Azure	Disponibilità generale	Nessuno

Le opzioni di hosting di Funzioni di Azure sono facilitate dall'infrastruttura del Servizio app di Azure nelle macchine virtuali Linux e Windows. L'opzione di hosting scelta determina i comportamenti seguenti:

Come viene ridimensionata l'app per le funzioni.
Le risorse disponibili per ogni istanza dell'app per le funzioni.
Il supporto per funzionalità avanzate, ad esempio la connettività della rete virtuale di Azure.
Supporto per i contenitori Linux.

Il piano scelto influisce anche sui costi per l'esecuzione del codice della funzione. Per altre informazioni, vedereFatturazione.

Questo articolo fornisce un confronto dettagliato tra le varie opzioni di hosting. Per altre informazioni sull'esecuzione e la gestione del codice della funzione nei contenitori Linux, vedere Supporto dei contenitori Linux in Funzioni di Azure.

Panoramica dei piani

Di seguito è riportato un riepilogo dei vantaggi delle varie opzioni per l'hosting di Funzioni di Azure:

Opzione	Vantaggi
Piano A consumo Flex	Ottenere una scalabilità orizzontale rapida con scelte di calcolo, rete virtuale e fatturazione con pagamento in base al consumo. Nel piano A consumo Flex, le istanze dell'host Funzioni vengono aggiunte e rimosse dinamicamente in base alla concorrenza configurata per istanza e al numero di eventi in ingresso. ✔ Ridurre l'avvio a freddo specificando una o più istanze con provisioning preliminare (sempre pronto). ✔ Supporto della rete virtuale per una maggiore sicurezza. ✔ Pagamento quando le funzioni sono in esecuzione. ✔ Ridimensionamento automatico, anche durante periodi di carico elevato.
Piano Premium	Ridimensionamento automatico in base alla domanda usando ruoli di lavoro preriscaldati senza ritardo dopo l’inattività, esecuzione su istanze più potenti e connessioni alle reti virtuali. Prendere in considerazione il piano Premium di Funzioni di Azure nelle situazioni seguenti: ✔ Le app per le funzioni vengono eseguite in modo continuo o quasi continuo. ✔ Si desidera un maggiore controllo delle istanze e si desidera distribuire più app per le funzioni nello stesso piano con ridimensionamento guidato dagli eventi. ✔ Si dispone di un numero elevato di esecuzioni di piccole dimensioni e di una fattura di esecuzione elevata, ma di pochi GB al secondo nel piano A consumo. ✔ Occorrono più opzioni di CPU o memoria rispetto a quelle fornite dai piani a consumo. ✔ Il codice deve essere eseguito più a lungo del tempo di esecuzione massimo consentito nel piano A consumo. ✔ È necessaria la connettività alle reti virtuali. ✔ Si desidera fornire un'immagine Linux personalizzata in cui eseguire le funzioni.
Piano dedicato	Eseguire le funzioni all'interno di un piano di servizio app a tariffe del piano di servizio app regolari. Ideale per gli scenari a esecuzione prolungata in cui non si può usare Durable Functions. Prendere in considerazione un piano di servizio app nelle situazioni seguenti: ✔ Sono presenti macchine virtuali esistenti e sottoutilizzate che eseguono già altre istanze del Servizio app. ✔ È necessario avere una fatturazione completamente prevedibile oppure è necessario ridimensionare manualmente le istanze. ✔ Si desiderano eseguire più app Web e app per le funzioni nello stesso piano ✔ È necessario accedere a scelte di dimensioni di calcolo maggiori. ✔ Isolamento dell’ambiente di calcolo completo e accesso di rete sicuro fornito da un ambiente del servizio app (ASE). ✔ Utilizzo molto elevato della memoria ed elevata scalabilità (ASE).
App contenitore	Creare e distribuire app per le funzioni in contenitori in un ambiente completamente gestito ospitato da App contenitore di Azure. Usare il modello di programmazione di Funzioni di Azure per creare app per le funzioni native del cloud, serverless e basate su eventi. Eseguire le proprie funzioni insieme ad altri microservizi, API, siti Web e flussi di lavoro come programmi ospitati in contenitori. Prendere in considerazione l'hosting delle funzioni in App contenitore nelle situazioni seguenti: ✔ Si desidera creare pacchetti di librerie personalizzate con il codice della funzione per supportare app line-of-business. ✔ È necessario eseguire la migrazione dell'esecuzione del codice dalle app locali o legacy ai microservizi nativi del cloud in esecuzione nei contenitori. ✔ Quando si desidera evitare il sovraccarico e la complessità della gestione dei cluster di Kubernetes e del calcolo dedicato. ✔ Le funzioni richiedono potenza di elaborazione di fascia alta tramite risorse di calcolo GPU dedicate.
Piano a consumo	Pagamento delle risorse di calcolo solo quando le funzioni sono in esecuzione (con pagamento in base al consumo) con scalabilità automatica. Quando si usa un piano a consumo, le istanze dell'host di Funzioni di Azure vengono aggiunte e rimosse in modo dinamico in base al numero di eventi in ingresso. ✔ Piano di hosting predefinito che fornisce un vero hosting serverless. ✔ Pagamento solo quando le funzioni sono in esecuzione. ✔ Ridimensionamento automatico, anche durante periodi di carico elevato.

Le tabelle rimanenti di questo articolo confrontano le opzioni di hosting in base a diverse funzionalità e comportamenti.

Supporto dei sistemi operativi

Questa tabella illustra il supporto del sistema operativo per le opzioni di hosting.

Servizi di hosting	Distribuzione di Linux¹	Distribuzione di Windows²
Piano A consumo Flex	✅ Solo codice ❌ Contenitore (non supportato)	❌ Non supportato
Piano Premium	✅ Solo codice ✅ Contenitore	✅ Solo codice
Piano dedicato	✅ Solo codice ✅ Contenitore	✅ Solo codice
App contenitore	✅ Solo contenitore	❌ Non supportato
Piano a consumo	✅ Solo codice ❌ Contenitore (non supportato)	✅ Solo codice

Linux è l'unico sistema operativo supportato per lo stack di runtime Python.
Le distribuzioni di Windows sono solo codice. Funzioni attualmente non supporta contenitori Windows.

Durata del timeout dell'app per le funzioni

La durata di timeout per le funzioni in un'app per le functionTimeout funzioni è definita dalla proprietà nel file di progetto host.json . Questa proprietà si applica in modo specifico alle esecuzioni di funzioni. Dopo l'avvio dell'esecuzione della funzione, la funzione deve restituire/rispondere entro la durata di timeout. Per evitare timeout, è importante scrivere funzioni affidabili. Per altre informazioni, vedere Migliorare le prestazioni e l'affidabilità di Funzioni di Azure.

La tabella seguente mostra i valori predefiniti e massimi (in minuti) per piani specifici:

Piano	Valore predefinito	Massimo¹
Piano A consumo Flex	30	Senza vincoli²
Piano Premium	30⁴	Senza vincoli²
Piano dedicato	30⁴	Senza vincoli³
App contenitore	30	Senza vincoli⁵
Piano a consumo	5	10

Indipendentemente dall'impostazione di timeout dell'app per le funzioni, 230 secondi è la quantità massima di tempo che una funzione attivata tramite HTTP può richiedere per rispondere a una richiesta. Ciò è dovuto al timeout di inattività predefinito di Azure Load Balancer. Per tempi di elaborazione più lunghi, provare a usare lo schema asincrono di Durable Functions oppure rinviare il processo effettivo e restituire una risposta immediata.
Non è applicata alcuna durata massima di timeout di esecuzione. Tuttavia, il periodo di tolleranza previsto per l'esecuzione di una funzione è di 60 minuti durante la riduzione per i piani a consumo Flex e Premium e un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
Richiede l'impostazione del piano di servizio app su Always On. È previsto un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
Il timeout predefinito per la versione 1.x del runtime host di Funzioni non è associato.
Quando il numero minimo di repliche è impostato su zero, il timeout predefinito dipende dai trigger specifici usati nell'app.

Supporto di versioni in lingue diverse

Per informazioni dettagliate sul supporto corrente dello stack di linguaggi nativi in Funzioni, vedere Linguaggi supportati in Funzioni di Azure.

Ridimensiona

Nella tabella seguente vengono confrontati i comportamenti di ridimensionamento dei vari piani di hosting.
Le istanze massime vengono fornite in base a un'app per ogni funzione (consumo) o per piano (Premium/Dedicato), a meno che non diversamente indicato.

Piano	Aumentare il numero di istanze	Numero massimo di istanze
Piano A consumo Flex	Ridimensionamento per funzione. Le decisioni di ridimensionamento guidate dagli eventi vengono calcolate in base a ogni funzione, che offre un modo più deterministico per ridimensionare le funzioni nell'app. Ad eccezione di HTTP, archiviazione BLOB (Griglia di eventi) e Durable Functions, tutti gli altri tipi di trigger di funzione nell'app vengono ridimensionati su istanze indipendenti. Tutti i trigger HTTP nell'app vengono ridimensionati insieme come gruppo nelle stesse istanze, come tutti i trigger di archiviazione BLOB (Griglia di eventi). Tutti i trigger di Durable Functions condividono anche le istanze e si ridimensionano insieme.	1000¹
Piano Premium	Basato sugli eventi. Aumento automatico del numero di istanze anche in periodo di carico elevato. L'infrastruttura di Funzioni di Azure ridimensiona le risorse di CPU e memoria aggiungendo altre istanze dell'host di Funzioni, in base al numero di eventi su cui vengono attivate le funzioni.	Windows: 100⁶ Linux: 20-100^2,6
Piano dedicato	Scalabilità automatica/manuale	10-30³ 100 (ASE)
App contenitore	Basato sugli eventi. Aumento automatico del numero di istanze anche in periodo di carico elevato. L'infrastruttura di Funzioni di Azure ridimensiona le risorse di CPU e memoria aggiungendo altre istanze dell'host di Funzioni, in base al numero di eventi su cui vengono attivate le funzioni.	300-1000⁴
Piano a consumo	Basato sugli eventi. Aumenta automaticamente il numero di istanze, anche durante periodi di carico elevato. L'infrastruttura di Funzioni ridimensiona le risorse di CPU e memoria aggiungendo altre istanze dell'host di Funzioni in base al numero di eventi di trigger in ingresso.	Windows: 200 Linux: 100⁵

Il piano a consumo flessibile prevede una quota di sottoscrizione a livello di area che limita l'utilizzo totale della memoria di tutte le istanze in una determinata area. Per ulteriori informazioni, vedere Quote di memoria della sottoscrizione regionale. I piani Flex Consumption supportano attualmente solo Linux.
In alcune aree, le app Linux in un piano Premium possono aumentare fino a 100 istanze. Per altre informazioni, vedere l'articolo Piano Premium.
Per i limiti specifici per le varie opzioni del piano di servizio app, vedere Limiti del piano di servizio app.
In App contenitore, il valore predefinito è 10 istanze, ma è possibile impostare il numero massimo di repliche, che ha un massimo complessivo di 1000. Questa impostazione viene rispettata purché sia disponibile una quota di core sufficiente. Per altre informazioni, vedere Quote per le applicazioni contenitore di Azure. Quando si crea l'app per le funzioni dal portale di Azure, sono limitate a 300 istanze.
Durante lo scale-out, attualmente è previsto un limite di 500 istanze per ogni sottoscrizione per ogni ora per le app Linux in un piano A consumo.
Per i trigger HTTP con restrizioni dell'endpoint privato, la scalabilità orizzontale è limitata al massimo a 20 istanze.

Comportamento di avvio a freddo

Piano	Dettagli
Piano A consumo Flex	Supporta istanze sempre pronte per ridurre il ritardo durante il provisioning di nuove istanze.
Piano Premium	Supporta istanze sempre pronte per evitare l'avvio a freddo, consentendo di gestire una o più istanze a caldo perpetuamente.
Piano dedicato	Quando l’esecuzione avviene in un piano Dedicato, l'host di Funzioni può essere eseguito continuamente su un numero prestabilito di istanze, per cui l'avvio a freddo non rappresenta in realtà un problema.
App contenitore	Dipende dal numero minimo di repliche: • Se impostato su zero: le app possono essere ridimensionate a zero quando sono inattive e alcune richieste potrebbero avere più latenze all'avvio. • Se impostato su uno o più: il processo host viene eseguito in modo continuo, il che significa che l'avvio a freddo non è un problema.
Piano a consumo	Le app possono essere ridimensionate a zero quando sono inattive, ovvero alcune richieste potrebbero avere più latenze all'avvio. Il piano a consumo include alcune ottimizzazioni che contribuiscono a ridurre il tempo di avvio a freddo, incluso il pull da funzioni segnaposto preriscaldate che già dispongono dell'host e dei processi del linguaggio in esecuzione.

Limiti del servizio

Conto risorse	Piano A consumo Flex	Piano Premium	Piano Dedicato/ambiente del servizio app	App contenitore	Piano a consumo
Durata di timeout predefinita (min)	30	30	30¹	30¹⁶	5
Durata massima del timeout (min)	non associato⁹	non associato⁹	Senza limiti²	senza limiti¹⁷	10
Numero massimo di connessioni in uscita (per istanza)	illimitato	illimitato	illimitato	illimitato	600 attive (1200 totali)
Dimensioni massime della richiesta (MB)³	210	210	210	210	210
Lunghezza massima della stringa di query³	4096	4096	4096	4096	4096
Lunghezza massima dell'URL della richiesta³	8192	8192	8192	8192	8192
Unità di calcolo di Azure per istanza	210-840	100-840/210-250¹⁰	variabile	100	variabile
Dimensioni massime della memoria (GB per istanza)	4¹⁴	3,5-14	1.75-256/8-256	variabile	1,5
Numero massimo di istanze (Windows \| Linux)¹⁵	n/a \| 1000	20-100	10-30 (100 ASE)¹¹	300-1000¹⁸	200 \| 100
App per le funzioni per piano¹³	1	100	Senza limiti⁴	Senza limiti⁴	100
Piani del servizio app	n/d	100 per gruppo di risorse	100 per gruppo di risorse	n/d	100 per area
Slot di distribuzione per app¹²	n/d	3	1-20¹¹	non supportato	2
Archiviazione (temporanea)⁵	0,8 GB	21-140 GB	11-140 GB	n/d	0,5 GB
Archiviazione (persistente)	0 GB⁷	250 GB	10-1000 GB¹¹	n/d	1 GB^6,7
Domini personalizzati per applicazione	500	500	500	non supportato	500⁷
Supporto TSL/SSL del dominio personalizzato	SNI SSL non associato e una connessione SSL IP inclusa	SNI SSL non associato e una connessione SSL IP inclusa	SNI SSL non associato e una connessione SSL IP inclusa	non supportato	Connessione SNI SSL senza limiti inclusa

Note sui limiti del servizio:

Per impostazione predefinita, il timeout per il runtime di Funzioni 1.x in un piano di servizio app non è associato.
Richiede l'impostazione del piano di servizio app su Always On. Pagamento con tariffe standard. È previsto un periodo di tolleranza di 10 minuti durante gli aggiornamenti della piattaforma.
Questi limiti sono impostati nell'host.
Il numero effettivo di app per le funzioni che è possibile ospitare dipende dall'attività delle app, dalle dimensioni delle istanze del computer e dall'uso delle risorse corrispondente.
Il limite di archiviazione corrisponde alle dimensioni totali del contenuto nello spazio di archiviazione temporanea in tutte le app nello stesso piano di servizio app. Per i piani a consumo in Linux, lo spazio di archiviazione è attualmente di 1,5 GB.
Il piano a consumo usa una condivisione file di Azure per l'archiviazione persistente. Quando si specifica una condivisione file di Azure personalizzata, i limiti di dimensione della condivisione specifici dipendono dall'account di archiviazione impostato per WEBSITE_CONTENTAZUREFILECONNECTIONSTRING.
In Linux è necessario montare in modo esplicito la condivisione File di Azure.
Quando l'app per le funzioni è ospitata in un piano A consumo, è supportata solo l'opzione CNAME. Per le app per le funzioni in un piano Premium o in un piano di servizio app, è possibile eseguire il mapping di un dominio personalizzato usando un record CNAME o A.
Non è applicata alcuna durata massima di timeout di esecuzione. Tuttavia, il periodo di tolleranza previsto per l'esecuzione di una funzione è di 60 minuti durante la riduzione e 10 minuti durante gli aggiornamenti della piattaforma.
I ruoli di lavoro ospitano app di clienti I lavoratori sono disponibili in tre dimensioni fisse: una vCPU/3,5 GB di RAM; due vCPU/7 GB di RAM; quattro vCPU/14 GB di RAM.
Per informazioni dettagliate, vedere Limiti del servizio app.
Inclusione dello slot di produzione.
Attualmente è previsto un limite di 5.000 app per le funzioni in una determinata sottoscrizione.
Le dimensioni dell'istanza del piano a consumo flessibile sono attualmente definite come 512 MB, 2.048 MB o 4.096 MB. Per altre informazioni, vedere memoria dell'istanza.
Per informazioni dettagliate, consultare Scala nell'articolo "Confronto tra hosting".
Quando il numero minimo di repliche è impostato su zero, il timeout predefinito dipende dai trigger specifici usati nell'app.
Quando il numero minimo di repliche è impostato su uno o più.

Funzionalità di rete

Funzionalità	Piano A consumo Flex	Piano a consumo	Piano Premium	Piano Dedicato/ambiente del servizio app	App^{contenitore 1}
Restrizioni IP in ingresso	✔	✔	✔	✔	✔
Endpoint privati in ingresso	✔		✔	✔
Integrazione della rete virtuale	✔		✔^{numero arabo}	✔³	✔
Restrizioni IP in uscita	✔		✔	✔	✔

Per altre informazioni, vedere Reti nell'ambiente App contenitore di Azure.
Quando si lavora con i trigger di rete virtuale, è necessario tenere presenti considerazioni speciali.
Solo il piano dedicato/ambiente del servizio app supporta l'integrazione della rete virtuale richiesta dal gateway.

Fatturazione

Piano	Dettagli
Piano A consumo Flex	La fatturazione si basa sul numero di esecuzioni, sulla memoria delle istanze quando eseguono funzioni attivamente, oltre al costo di tutte le istanze sempre pronte. Per altre informazioni, vedere Fatturazione nel piano A consumo Flex.
Piano Premium	Il piano Premium si basa sul numero di secondi di core e sulla memoria usati nelle istanze necessarie e preriscaldate. Almeno un'istanza per piano deve essere sempre mantenuta calda. Questo piano fornisce i prezzi più prevedibili.
Piano dedicato	Per le app per le funzioni in un piano di servizio app si paga lo stesso importo che si pagherebbe per altre risorse del servizio app, ad esempio le app Web. Per un ambiente del servizio app è disponibile una tariffa mensile fissa che si paga per l'infrastruttura e non cambia con le dimensioni dell'ambiente. È previsto anche un costo per vCPU del piano di servizio app. Tutte le app ospitate in un ambiente del servizio app fanno parte di uno SKU di prezzi isolato. Per altre informazioni, vedere l'articolo sulla panoramica dell'ambiente del servizio app.
App contenitore	La fatturazione in App contenitore di Azure si basa sul tipo di piano. Per altre informazioni, vedere Fatturazione in App contenitore di Azure.
Piano a consumo	Pagamento solo per il periodo in cui le funzioni sono in esecuzione. La fatturazione si basa sul numero di esecuzioni, il tempo di esecuzione e la memoria usata.

Per un confronto diretto dei costi tra piani di hosting dinamici (A consumo, A consumo Flex e Premium), vedere la pagina dei prezzi di Funzioni di Azure. Per i prezzi delle varie opzioni del piano Dedicato, vedere la pagina dei prezzi del servizio app. Per i prezzi dell'hosting delle app contenitore, vedere Prezzi di App contenitore di Azure.

Limitazioni per la creazione di nuove app per le funzioni in un gruppo di risorse esistente

In alcuni casi, quando si tenta di creare un nuovo piano di hosting per la propria app per le funzioni in un gruppo di risorse esistente, è possibile che venga visualizzato uno degli errori seguenti:

Il piano tariffario non è consentito in questo gruppo di risorse
< > SKU_name i ruoli di lavoro non sono disponibili nel gruppo <di risorse resource_group_name>

Ciò può verificarsi quando vengono soddisfatte le condizioni seguenti:

Si crea un'app per le funzioni in un gruppo di risorse esistente che non ha mai contenuto un'altra app per le funzioni o un'app Web. Ad esempio, le app a consumo per Linux non sono supportate nello stesso gruppo di risorse dei piani Linux Dedicati o Linux Premium.
La nuova app per le funzioni viene creata nella stessa area dell'app precedente.
L'app precedente è in qualche modo incompatibile con la nuova app. Questo errore può verificarsi tra SKU, sistemi operativi o a causa di altre funzionalità a livello di piattaforma, ad esempio il supporto della zona di disponibilità.

Il motivo è dovuto alla modalità di mapping dei piani di app per le funzioni e app Web a pool di risorse diversi durante la creazione. Sku diversi richiedono un set diverso di funzionalità dell'infrastruttura. Quando si crea un'app in un gruppo di risorse, tale gruppo di risorse viene mappato e assegnato a un pool specifico di risorse. Se si tenta di creare un altro piano in tale gruppo di risorse e il pool mappato non dispone delle risorse necessarie, si verifica questo errore.

Quando si verifica questo errore, creare, invece, l'app per le funzioni e il piano di hosting in un nuovo gruppo di risorse.

Condividi tramite