Azure App Service è la PaaS di Azure per ospitare web app, API e mobile backend senza gestire il sistema operativo o l’infrastruttura sottostante. Come amministratore devi padroneggiare tre decisioni chiave: quale App Service Plan scegliere, come scalare in modo efficiente e come rilasciare nuove versioni senza downtime.

Il App Service Plan definisce il compute

Un App Service Plan è l’insieme di risorse di calcolo (le VM gestite sottostanti) su cui girano una o più app. Punto centrale: tutte le app nello stesso piano condividono CPU, RAM e istanze. Se collochi dieci app in un piano Standard a una istanza, competono per le stesse risorse; scalare il piano scala tutte le app insieme. Per isolare un’app “rumorosa” la sposti su un piano dedicato.

I tier a confronto

  • Free / Shared (F1, D1): compute condiviso multi-tenant, quote CPU giornaliere, niente custom domain su Free, niente SLA, niente slot né autoscale. Solo dev/test.
  • Basic (B1–B3): compute dedicato, custom domain + TLS, scale-out manuale fino a 3 istanze, ma niente autoscale né deployment slot.
  • Standard (S1–S3): aggiunge deployment slot (5), autoscale e backup. È il primo tier davvero “production-ready”.
  • Premium v3 (P0v3–P3mv3): più CPU/RAM, fino a 30 istanze, slot fino a 20, supporto per availability zones (zone-redundancy) e miglior rapporto prezzo/prestazioni. Consigliato per carichi produttivi seri.
  • Isolated v2: gira in un App Service Environment (ASE) dentro la tua VNet, per isolamento di rete e compliance.

A esame la scelta è quasi sempre: “serve autoscale o slot? → almeno Standard”; “servono availability zone / alta scala? → Premium v3”.

Scale-up vs scale-out

  • Scale-up (verticale): cambi tier o size del piano per avere più CPU/RAM per istanza. Serve quando la singola richiesta è pesante o servono feature del tier superiore.
  • Scale-out (orizzontale): aumenti il numero di istanze che eseguono l’app in parallelo, dietro il load balancer integrato. Serve per gestire più traffico concorrente e per l’alta disponibilità.

Autoscale

Da Standard in su configuri l’autoscale con regole basate su metriche (CPU %, memoria, queue length) oppure su schedule. Definisci istanze minime, massime e default. Best practice: regola per metrica per adattarti al carico e imposta un minimo ≥ 2 per resilienza. Ricorda che l’autoscale agisce solo sul conteggio istanze (scale-out), mai sulla size.

Deployment slot e swap

I deployment slot (Standard+) sono istanze aggiuntive della stessa app con hostname proprio (es. app-staging). Distribuisci la nuova versione su staging, la validi con traffico reale controllato (traffic routing a percentuale) e poi esegui lo swap con production.

Lo swap è a zero downtime: lo slot di staging viene pre-riscaldato (warm-up) e poi le istanze vengono scambiate a livello di routing, senza ricopiare i file. Se qualcosa va storto, un swap back riporta immediatamente alla versione precedente: è la tua strategia di rollback.

Attenzione cruciale: durante lo swap anche le app settings e le connection string vengono scambiate, a meno che non le marchi come deployment slot setting (“slot-specific” / sticky). Le impostazioni sticky restano ancorate allo slot; tutto il resto segue l’app.

Custom domain, TLS e VNet integration

  • Custom domain: da Basic in su mappi un tuo dominio con record CNAME/A più verifica (TXT/asuid).
  • TLS/SSL: carichi un certificato oppure usi un App Service Managed Certificate gratuito; puoi forzare HTTPS e imporre la versione minima di TLS.
  • VNet integration: permette all’app di raggiungere risorse private nella tua VNet (database, storage con private endpoint) per il traffico in uscita. Per esporre l’app in ingresso su rete privata usi invece i private endpoint.

Trappole tipiche d’esame

  • Due app nello stesso piano, una consuma tutta la CPU → spostala in un App Service Plan separato; scalare il piano non isola il carico.
  • Serve rilascio a zero-downtime con rollback rapido → deployment slot + swap (e swap back per il rollback), disponibile da Standard in su.
  • Dopo lo swap la app di staging punta ancora al DB di produzione → la connection string non era marcata come deployment slot setting (sticky).
  • Serve solo più traffico concorrente, non più feature → scale-out (più istanze / autoscale), non scale-up.
  • Richiesti availability zones e alta scala → Premium v3; Basic non offre né autoscale né slot.