Azure App Service Plan spiegati: come i livelli di prezzo regolano funzionalità e risorse

By Mirko Peters · 2026-10-21

Scopri come i piani di Azure App Service e i relativi livelli di prezzo regolano le funzionalità disponibili, gestiscono le risorse di calcolo e incidono sullo scaling per web app e API.

Automatically translated with AI from the original post. Read the English original

Scopri come i piani di Azure App Service determinano le tue risorse cloud, i costi e i limiti funzionali critici. Impara a evitare le trappole più comuni, come il sovraccarico dei piani condivisi, la scarsa comprensione delle quote di CPU e uno scaling inefficace di web app e API, che può causare interruzioni impreviste in produzione o bollette cloud fuori controllo.

Punti chiave

• Un piano di Azure App Service è un insieme di risorse di calcolo che definisce sistema operativo, area geografica, dimensione della macchina, numero di istanze e livello di prezzo.
• I livelli di prezzo funzionano come limiti alle funzionalità e non come semplici aggiornamenti di dimensione: domini personalizzati, certificati SSL, slot di distribuzione e scaling automatico sono disponibili solo a partire da livelli specifici.
• Tutte le app distribuite nello stesso piano di App Service condividono esattamente lo stesso pool di calcolo e vengono scalate insieme, nello stesso momento.
• I livelli Free e Shared impongono rigidi limiti giornalieri di minuti di CPU e non includono funzionalità essenziali come "Always On", quindi sono adatti solo a semplici prove.
• I carichi di lavoro di produzione richiedono i livelli Basic o superiori per ottenere macchine dedicate, supporto per i domini personalizzati e protezione dai timeout per inattività dell'applicazione.

Anatomia di un piano di App Service

Quando inizi a distribuire web application e API REST nel cloud Microsoft, il primo oggetto che crei è un piano di App Service. Molti sviluppatori ritengono erroneamente di acquistare semplicemente l'hosting per una singola web app. In realtà, il piano è il prodotto principale che stai acquistando. Funziona come un pool condiviso di macchine virtuali che determina contemporaneamente cinque decisioni fondamentali: il sistema operativo, l'area geografica in cui risiede il codice, la dimensione fisica delle macchine, il numero di istanze attive e il livello di prezzo.

Poiché più app possono risiedere in un unico piano, ogni applicazione, ogni processo in background, ogni log diagnostico e ogni slot di distribuzione attinge allo stesso identico pool di risorse. L'isolamento del calcolo avviene rigorosamente a livello di piano, non di singola app. Se inserisci tre microservizi o portali interni diversi in un unico piano, un picco di traffico su una sola app consumerà CPU e memoria condivise con le altre. Di conseguenza, se il tuo carico di lavoro di produzione inizia a generare timeout, la causa radice raramente è un bug nel codice: di solito significa che hai saturato il piano di App Service senza accorgertene.

Livelli di prezzo come limiti alle funzionalità

Molti principianti del cloud considerano la scala dei prezzi di Azure App Service, che va da Free e Shared fino a Basic, Standard, Premium e Isolated, come una semplice guida al dimensionamento in cui si paga di più per una macchina più veloce. Microsoft, però, considera questi livelli soprattutto come limiti alle funzionalità. Salire di livello non significa solo assegnare più memoria RAM o potenza di elaborazione: sblocca concretamente le capacità di cui la tua architettura ha bisogno per funzionare in modo professionale.

Ad esempio, il piano Gratuito limita l'uso a una sola app per piano, restringe l'utilizzo a 60 minuti di CPU al giorno, assegna un gigabyte di memoria e blocca del tutto i nomi di dominio personalizzati. La tua applicazione è costretta a risiedere su un indirizzo predefinito azurewebsites.net. Inoltre, funzionalità come gli slot di distribuzione, la scalabilità automatica e l'impostazione critica 'Sempre attivo', che impedisce alle web app inattive di arrestarsi e di subire avvii a freddo, sono bloccate nei livelli superiori della gerarchia dei piani.

Capire le trappole dei piani Gratuito e Condiviso

I piani Gratuito e Condiviso sono esplicitamente progettati come prove su strada, non come ambienti di produzione funzionali. Sebbene 60 o 240 minuti di tempo CPU giornaliero possano sembrare generosi per un prototipo, una pagina web molto utilizzata o un flusso di Power Automate aggressivo che invia richieste alla tua API REST può esaurire quel budget nel giro di poche ore. Inoltre, questi livelli base non supportano la scalabilità orizzontale su più istanze, quindi un'elevata concorrenza causerà subito throttling e richieste non riuscite.

Passare ai piani di calcolo dedicati

Per creare qualcosa di solido per un cliente o un team interno, il piano Basic rappresenta il minimo funzionale assoluto. Basic introduce macchine virtuali dedicate, l'integrazione di domini personalizzati, certificati TLS/SSL gestiti e l'opzione di configurazione 'Sempre attivo'. Salendo ulteriormente nei piani Standard e Premium, sbloccherai funzionalità aziendali avanzate come gli slot di distribuzione per rilasci senza tempi di inattività e le regole di scalabilità orizzontale automatica.

Scalare verticalmente vs. scalare orizzontalmente

Gestire le prestazioni e i picchi di traffico richiede di capire la differenza fondamentale tra scalare verticalmente e scalare orizzontalmente in Azure App Service. Confondere questi due concetti è una fonte frequente di confusione architetturale e di bollette cloud gonfiate.

Scalare verticalmente significa crescita verticale: passare il piano di App Service a una dimensione di macchina più grande o a un livello di prezzo superiore, per ottenere più potenza di elaborazione grezza e funzionalità di piattaforma aggiuntive. Scalare orizzontalmente significa crescita orizzontale: aggiungere altre copie identiche delle istanze di macchina virtuale dietro lo stesso endpoint, in modo che le richieste HTTP in arrivo vengano distribuite uniformemente su un pool più ampio.

Mentre i piani base consentono regolazioni manuali del numero di istanze, la scalabilità automatica basata su percentuali di CPU o su pianificazioni temporali inizia dal piano Standard. Ogni istanza aggiuntiva che attivi rappresenta un'altra macchina fisica che esegue il tuo codice, con un impatto diretto sulla spesa mensile. Per approfondire la gestione dei carichi di lavoro cloud e la scelta delle configurazioni giuste, non perdere l'episodio completo con approfondimenti di esperti e indicazioni pratiche.

Conclusione

Padroneggiare Azure App Service significa andare oltre la semplicità del caricamento del codice e comprendere la logica economica di piani e livelli. Riconoscendo che il piano determina la contesa delle risorse, l'accesso alle funzionalità e i limiti di scalabilità, puoi progettare architetture cloud resilienti che scalano con equilibrio senza costi imprevisti. Che tu stia ospitando uno strumento interno, un back-end per app mobili o API per Power Platform, scegliere il livello giusto fin dall'inizio fa risparmiare ore di refactoring in seguito. Ascolta l'episodio completo del M365 FM Podcast per scoprire la nostra discussione completa su come evitare le trappole dei principianti, gestire gli slot di distribuzione e ottimizzare il tuo ambiente cloud Microsoft.

Domande frequenti

Che cos'è un piano di Azure App Service?

Un piano di Azure App Service definisce l'insieme di risorse di calcolo fisiche, sistema operativo, area e limiti di scalabilità utilizzati da una o più web app o API. Funge da confine di fatturazione e di risorse per le tue distribuzioni cloud.

Perché le funzionalità sono vincolate ai livelli di prezzo?

Microsoft struttura i livelli di App Service per separare gli ambienti di prova occasionali dai carichi di lavoro di produzione aziendali. Funzionalità come domini personalizzati, slot di distribuzione e scalabilità automatica richiedono un'infrastruttura dedicata e un carico di gestione presenti solo nei livelli a pagamento.

Più app possono condividere lo stesso piano di App Service?

Sì, puoi ospitare più web app e API all'interno di un unico piano di App Service. Tuttavia, tutte le app di quel piano condividono le risorse di CPU e memoria sottostanti e scalano insieme contemporaneamente.

Qual è la differenza tra scalare verticalmente e scalare orizzontalmente?

Il ridimensionamento verticale (scale up) prevede il passaggio a una macchina più grande o a un piano tariffario superiore per ottenere più potenza e funzionalità, mentre il ridimensionamento orizzontale (scale out) aggiunge altre istanze identiche della tua app per gestire volumi di traffico più elevati.