Perché il piano di hosting è una scelta architetturale

In Azure Functions il hosting plan determina tre cose che l’esame ama incrociare: come e quanto scala il tuo codice, quali funzionalità di rete e sicurezza hai a disposizione, e il modello di costo. Non è un dettaglio operativo da rimandare al deploy: la scelta del piano condiziona timeout, cold start, integrazione VNet e prezzo. Sapere quale piano in quale scenario è esattamente ciò che AZ-204 verifica.

I piani di hosting

Consumption plan

È il piano serverless puro: paghi solo per le esecuzioni (numero, durata, memoria) e scali fino a zero quando non c’è traffico.

  • Scale-to-zero: nessuna istanza attiva a riposo, quindi possibili cold start quando arriva il primo evento dopo un periodo di inattività.
  • Timeout limitato: default 5 minuti, massimo configurabile 10 minuti (functionTimeout in host.json).
  • Niente VNet integration nativa e nessuna istanza pre-warmed.

Ideale per API a traffico intermittente, trigger event-driven leggeri, automazioni schedulate. Non adatto a esecuzioni lunghe o a workload che devono raggiungere risorse in rete privata.

Premium plan (Elastic Premium, EP1/EP2/EP3)

Pensato per eliminare gli svantaggi del Consumption mantenendo lo scaling event-driven.

  • Istanze pre-warmed (always-ready instances): evitano il cold start tenendo worker già caldi.
  • VNet integration per raggiungere database, storage e servizi dietro private endpoint.
  • Esecuzioni lunghe: timeout configurabile fino a illimitato (default 30 min).
  • Istanze più potenti e supporto per unbounded elastic scale.

È la risposta corretta quando servono contemporaneamente scaling elastico, assenza di cold start e connettività privata.

Dedicated (App Service plan)

Le Functions girano sulle stesse VM di una web app. Utile quando hai già un App Service plan sottoutilizzato, quando servono configurazioni specifiche (VM predicibili, scaling manuale/autoscale basato su metriche) o esecuzioni continue con Always On. Lo scaling non è event-driven: dipende dalle regole di autoscale che imposti.

Flex Consumption

Il piano più recente che combina scale-to-zero e pay-per-use del Consumption con capacità enterprise:

  • VNet integration nativa,
  • controllo su istanze always-ready per mitigare i cold start,
  • concorrenza per-istanza configurabile e scaling rapido.

È la scelta moderna quando vuoi il modello serverless ma ti serve la rete privata, storicamente motivo per passare a Premium.

Come avviene lo scaling: Scale Controller e KEDA

Nei piani serverless (Consumption, Premium, Flex) non decidi tu il numero di istanze: lo fa lo Scale Controller. Monitora la sorgente degli eventi (lunghezza di una coda, lag di Event Hubs, latenza HTTP) e aggiunge o rimuove istanze in base al carico, non alla CPU. Per una coda, ad esempio, valuta quanti messaggi sono in attesa e la velocità con cui vengono processati.

Quando esegui Functions fuori da Azure, in container su Kubernetes, entra in gioco KEDA (Kubernetes Event-Driven Autoscaling): è il componente che porta lo scaling event-driven (incluso lo scale-to-zero) sui pod, usando gli stessi trigger delle Functions. Concettualmente KEDA è l’equivalente dello Scale Controller nel mondo Kubernetes.

// host.json — esecuzioni lunghe (valido su Premium/Dedicated, NON su Consumption oltre 10 min)
{ "functionTimeout": "01:00:00" }

Trappole tipiche d’esame

  • Scenario: la funzione deve accedere a un database dietro private endpoint in una VNet → risposta giusta: Premium o Flex Consumption. Il Consumption plan non supporta VNet integration: è la trappola più classica.
  • Scenario: il processo dura più di 10 minuti → risposta giusta: Premium (timeout illimitato) o Dedicated con Always On, non Consumption (cap a 10 minuti).
  • Scenario: latenza inaccettabile al primo hit dopo inattività (cold start) su un’API critica → risposta giusta: Premium con always-ready instances, non aumentare semplicemente la memoria sul Consumption.
  • Scenario: hai già un App Service plan che gira 24/7 sottoutilizzato e vuoi ospitarci le Functions senza costi extra → risposta giusta: Dedicated (App Service) plan, non un nuovo Consumption.
  • Scenario: Functions containerizzate su AKS che devono scalare in base ai messaggi in coda → risposta giusta: KEDA, non l’autoscaler basato su CPU/HPA generico.