Il ruolo dell’App Service Plan

In Azure App Service ogni web app, API o app funzione (in modello dedicato) gira dentro un App Service Plan, che rappresenta l’insieme di risorse di calcolo (VM sottostanti) allocate. Il concetto chiave, spesso frainteso all’esame, è che un piano può ospitare più app contemporaneamente: tutte le app associate allo stesso plan condividono CPU, memoria e istanze. Questo permette di risparmiare consolidando più app su un unico piano, ma significa anche che un’app “rumorosa” può consumare risorse a scapito delle altre. Se un’app ha requisiti di scaling o performance propri, va isolata su un piano dedicato.

Il tier (SKU) del piano determina non solo la potenza hardware, ma soprattutto quali funzionalità sono abilitate.

Cosa abilita ciascun tier

  • Free (F1) e Shared (D1): infrastruttura condivisa multi-tenant, quote di CPU giornaliere, niente Always On, niente scaling, niente slot, niente custom domain SSL su Free. Solo per prototipi.
  • Basic (B1–B3): calcolo dedicato, custom domain + SSL, scale-out manuale fino a 3 istanze. Nessun autoscale, nessun deployment slot.
  • Standard (S1–S3): abilita autoscale (regole su metriche), 5 deployment slot, backup automatici, VNet integration regionale, scale-out fino a 10 istanze.
  • Premium v3 (P0v3–P3v3): processori più veloci e maggiore memoria, fino a 30 istanze, 20 slot, supporto Availability Zones, opzioni memory-optimized. È il tier raccomandato per i carichi di produzione moderni.
  • Isolated v2 (ASE v3): deployment single-tenant con isolamento hardware dentro il tuo App Service Environment, network isolation completa e scalabilità molto elevata.

Scale-up vs scale-out

Sono due assi distinti e l’esame verifica spesso che tu sappia distinguerli.

  • Scale-up (verticale): cambi tier del piano (es. da B1 a P1v3) per ottenere più CPU/RAM per istanza o sbloccare funzionalità. È un’operazione sul singolo “taglio” della VM.
  • Scale-out (orizzontale): aumenti il numero di istanze che eseguono l’app. Manuale in Basic; automatico (autoscale) solo da Standard in su, tramite regole su metriche (CPU, coda, ecc.) o pianificazione oraria.

Regola pratica: per gestire picchi di traffico variabile si usa lo scale-out con autoscale; per un carico stabilmente più pesante o per abilitare feature, si fa scale-up.

Premium v3 oppure Isolated/ASE?

Entrambi offrono calcolo dedicato e alta scala, quindi va scelto in base ai requisiti di rete e isolamento:

  • Scegli Premium v3 nella grande maggioranza dei casi: buone performance, prezzo/prestazioni migliore delle vecchie Premium v2, Availability Zones, e VNet integration per il traffico in uscita verso risorse private. Resta però un ambiente multi-tenant (VM dedicate, ma infrastruttura di rete condivisa).
  • Scegli Isolated v2 / ASE v3 solo quando servono: single-tenancy e isolamento hardware totale, l’app interamente dentro la tua VNet con endpoint inbound privati, requisiti stringenti di compliance/sicurezza di rete, o scala molto elevata. In cambio paghi un costo notevolmente superiore.

In sintesi: non partire dall’ASE. Si sale a Isolated solo se Premium v3 non soddisfa un requisito di rete/isolamento specifico.

App settings e configurazione

Le app settings (variabili d’ambiente) e le connection string si impostano a livello di singola app e sovrascrivono i valori del file di configurazione (es. appsettings.json in ASP.NET Core). Sono lo strumento corretto per gestire secret e differenze tra ambienti senza rebuild. Punto importante per gli slot: le impostazioni possono essere marcate come deployment slot setting (sticky), così restano legate allo slot e non seguono lo swap — utile per mantenere stringhe di produzione separate da quelle di staging.

Trappole tipiche d’esame

  • Scenario: servono deployment slot per il blue-green deployment ma il piano è Basic → risposta: gli slot non esistono in Basic/Free; fai scale-up ad almeno Standard (5 slot) o Premium (20 slot).
  • Scenario: richiesto autoscale su metriche di CPU, piano attuale Basic → risposta: Basic supporta solo scale-out manuale; serve Standard o superiore per l’autoscale.
  • Scenario: “aumentare il numero di copie dell’app durante i picchi” → risposta: è scale-out (orizzontale), non scale-up; non cambiare tier se non serve una feature.
  • Scenario: l’app deve stare dentro la VNet con inbound privato e single-tenancy → risposta: Isolated v2 / App Service Environment (ASE v3), non Premium v3.
  • Scenario: dopo uno swap una connection string di staging finisce in produzione → risposta: marcala come slot setting (sticky) così non viene swappata.