Scaling automatico di App Service

In App Service il piano (App Service Plan) definisce la capacità: lo scale up cambia lo SKU (più CPU/RAM, feature come slot o VNet integration), lo scale out aggiunge istanze che condividono lo stesso codice dietro il load balancer integrato. L’autoscale agisce solo sullo scale out ed è disponibile dai tier Standard in su.

Una regola di autoscale si costruisce con tre elementi:

  • Metrica e soglia: es. CpuPercentage > 70 valutata su una time aggregation (Average) e una duration (10 minuti). Si definiscono regole separate per scale-out (increase count) e scale-in (decrease count).
  • Cooldown: intervallo dopo un’azione in cui non se ne innescano altre, per evitare flapping.
  • Instance limits: minimo, massimo e default.

Oltre alle metriche puoi usare regole schedule-based (profili ricorrenti): tipico lo scenario “più istanze nei giorni lavorativi 8–18, meno di notte/weekend”. Best practice: la soglia di scale-in deve essere nettamente inferiore a quella di scale-out (isteresi) e conviene scalare out in fretta, in con calma per non degradare l’esperienza sotto carico.

VNet integration vs Private Endpoint

Sono spesso confusi ma risolvono direzioni di traffico opposte.

VNet integration — traffico in USCITA

Permette all’app di raggiungere risorse private dentro (o raggiungibili da) una VNet: un database su private endpoint, una cache, un servizio interno, un firewall/NAT per l’egress. È la scelta quando l’app deve chiamare qualcosa di privato. Non rende privato l’ingresso all’app.

Private Endpoint — traffico in INGRESSO

Assegna all’app un IP privato nella VNet tramite una NIC dedicata, così i client la raggiungono senza passare da Internet. È la scelta quando vuoi che l’app sia accessibile solo dalla rete privata; tipicamente si disabilita l’accesso pubblico.

Regola mnemonica: integration = uscita, private endpoint = ingresso. I due si combinano (app raggiungibile privatamente e capace di chiamare backend privati).

Easy Auth (App Service Authentication)

Easy Auth è autenticazione gestita dalla piattaforma, eseguita da un modulo/middleware che gira fuori dal tuo codice, prima che la richiesta lo raggiunga. Con unauthenticatedClientAction = RedirectToLoginPage le richieste non autenticate vengono dirottate al provider (Microsoft Entra ID, Google, ecc.); con Return401/AllowAnonymous la richiesta prosegue e decidi tu.

Cosa fa il modulo:

  • Gestisce il flusso OIDC/OAuth, valida i token e mantiene un token store.
  • Inietta l’identità in header (X-MS-CLIENT-PRINCIPAL*) leggibili dal codice.
  • Espone /.auth/me (claim dell’utente), /.auth/login/<provider> e /.auth/logout.

Quando conviene rispetto a MSAL nel codice: quando vuoi proteggere l’app senza scrivere logica di autenticazione, per API interne, siti server-rendered o quando ti basta “chi è l’utente”. MSAL resta necessario quando l’app deve acquisire token per chiamare API downstream con controllo fine su scope/consent, gestire flussi custom, cache token per-utente o logica multi-tenant articolata. I due approcci possono coesistere.

Punto chiave: Easy Auth fa authentication (verifica l’identità), non authorization applicativa fine-grained. Con Entra ID puoi limitare chi accede (assegnazione utenti/gruppi all’app enterprise), ma decidere cosa può fare un ruolo su una singola risorsa resta responsabilità del tuo codice, leggendo i claim (es. roles) dal principal iniettato.

Trappole tipiche d’esame

  • Scenario: l’app deve leggere un database Azure SQL esposto solo via private endpoint. → Serve VNet integration sull’app (traffico in uscita), non un private endpoint sull’app.
  • Scenario: vuoi che l’app sia raggiungibile solo dalla rete aziendale, non da Internet. → Private Endpoint + disabilita l’accesso pubblico; VNet integration da sola non basta.
  • Scenario: “Easy Auth abilitato quindi l’app è messa in sicurezza a livello di ruoli”. → Falso: Easy Auth autentica, ma l’autorizzazione fine-grained (chi può fare cosa) va implementata nel codice sui claim.
  • Scenario: picchi prevedibili ogni lunedì mattina. → Regola di autoscale schedule-based (profilo ricorrente), non solo soglia su CPU.
  • Scenario: l’app deve chiamare Microsoft Graph a nome dell’utente con scope specifici. → MSAL (acquisizione token e consent), non il semplice login di Easy Auth.
  • Scenario: autoscale che oscilla continuamente. → Verifica cooldown e distanza fra soglie di scale-out e scale-in (isteresi).