Microsoft Azure: cos’è, come funziona, servizi, costi e quando usarlo

Microsoft Azure è la piattaforma di cloud computing di Microsoft. Permette di creare e utilizzare risorse di calcolo, storage, database, reti, container, servizi applicativi, strumenti di gestione e soluzioni di intelligenza artificiale senza dover possedere direttamente tutta l’infrastruttura fisica sottostante. La stessa Microsoft definisce Azure come una piattaforma di cloud computing, non come un singolo prodotto o server.

Definirlo semplicemente “hosting Microsoft” o “un server nel cloud” sarebbe però riduttivo. Una macchina virtuale è soltanto una delle risorse che puoi creare in Azure. La piattaforma serve soprattutto a combinare servizi diversi intorno a un workload, scegliendo ogni volta quanta infrastruttura vuoi amministrare direttamente e quanta gestione vuoi trasferire a Microsoft.

Questa distinzione è importante anche per capire prezzi e sicurezza. Una macchina virtuale, una web app gestita, un cluster Kubernetes e una funzione serverless possono eseguire codice, ma lasciano al cliente responsabilità operative molto diverse.

Il modo più utile per leggere Azure è quindi questo:

workload → livello di gestione desiderato → servizi necessari → responsabilità → costi

Partendo da questo modello diventa molto più semplice orientarsi in una piattaforma altrimenti enorme.

Cos’è Microsoft Azure, senza confonderlo con un hosting o Microsoft 365

Prima di entrare nei singoli servizi conviene chiarire il perimetro dell’entità. Azure utilizza infrastrutture fisiche Microsoft, ma ciò che il cliente acquista e configura è un insieme di servizi cloud. Per questo non coincide né con un semplice hosting né con la suite Microsoft 365.

Azure è una piattaforma, non un singolo server o data center

Azure appartiene al modello generale del cloud computing: le risorse informatiche vengono rese disponibili attraverso una piattaforma e possono essere create, configurate, ridimensionate o eliminate senza acquistare ogni volta nuovo hardware.

Un server virtuale può far parte di Azure, ma Azure non coincide con quel server.

Allo stesso modo non coincide con un data center. Il data center è il livello fisico: edifici, alimentazione, raffreddamento, rete, sistemi di sicurezza e hardware. Azure è invece la piattaforma attraverso cui Microsoft trasforma questa infrastruttura in servizi utilizzabili dai clienti. Nella propria documentazione Microsoft chiarisce esplicitamente che Azure non è un data center, anche se i suoi servizi vengono eseguiti nella rete globale dei data center Microsoft.

Questo significa che due progetti ospitati su Azure possono avere architetture completamente differenti.

Un progetto può consistere in una sola macchina virtuale. Un altro può non utilizzare alcuna VM amministrata direttamente dal cliente e combinare una piattaforma applicativa gestita, database, object storage, autenticazione e funzioni serverless.

Se incontri ancora il nome Windows Azure in documentazione o articoli datati, si tratta del precedente nome della piattaforma: Microsoft lo ha sostituito con Microsoft Azure per riflettere un cloud non limitato all’ecosistema Windows. Il cambio di denominazione da Windows Azure a Microsoft Azure è stato annunciato direttamente dal team Microsoft Azure.

Azure, Microsoft Cloud e Microsoft 365: le differenze

Un’altra fonte frequente di confusione è l’uso della parola “Microsoft” accanto a prodotti cloud molto diversi.

Microsoft 365 è quindi un servizio che utilizzi come prodotto finito. Con Azure, invece, puoi costruire e gestire l’infrastruttura e i servizi sui quali funzionano le tue applicazioni.

La differenza pratica è importante: se vuoi fornire email e strumenti di collaborazione ai dipendenti, probabilmente stai valutando Microsoft 365. Se devi distribuire il backend di un’applicazione, creare una rete privata, eseguire macchine virtuali o utilizzare un database gestito, stai entrando nel territorio di Azure.

Come funziona Azure: risorse, regioni e livelli di gestione

Azure diventa più comprensibile quando smetti di guardarlo come un elenco di prodotti e inizi a osservare come vengono organizzate le risorse. La piattaforma combina una gerarchia amministrativa, una distribuzione geografica e diversi livelli di astrazione: questi tre elementi determinano come progetti, governi e paghi un workload.

Subscription, resource group e risorse: la struttura di base

Una subscription è uno dei principali confini amministrativi e di fatturazione di Azure. Al suo interno vengono create le risorse utilizzate dai workload.

I resource group permettono invece di raggruppare risorse correlate. Microsoft raccomanda di usarli tenendo conto anche del loro ciclo di vita: componenti che vengono distribuiti, aggiornati o rimossi insieme possono essere organizzati nello stesso gruppo. Nelle organizzazioni più articolate entrano poi in gioco management group e più subscription per separare ambienti, responsabilità e governance. La guida Microsoft sull’organizzazione delle risorse Azure collega esplicitamente questa struttura a governance, gestione e attribuzione dei costi.

Un modello semplificato può essere rappresentato così:

subscription → resource group → risorse

Dentro un resource group potresti trovare, per esempio, una web app, un database, uno storage account e componenti di rete utilizzati dalla stessa applicazione.

Questa organizzazione non è soltanto estetica. Incide su permessi, automazione, policy, tracciamento dei costi e gestione del ciclo di vita.

Se un ambiente cresce senza convenzioni chiare, il problema raramente è “Azure ha troppi servizi”. Più spesso manca una struttura coerente per capire chi possiede una risorsa, a quale applicazione appartiene, in quale ambiente si trova e quanto sta costando.

Regioni e availability zones: cosa significa Italy North

Le risorse Azure vengono distribuite in regioni geografiche. La scelta della regione può incidere su latenza, disponibilità dei servizi, requisiti di residenza dei dati, architettura e prezzo.

Per l’Italia è disponibile la regione Italy North, localizzata a Milano. Nell’elenco ufficiale delle regioni Azure, Microsoft indica per Italy North il supporto a tre availability zones.

Una availability zone rappresenta un dominio fisicamente separato all’interno di una regione, con infrastrutture indipendenti per elementi come alimentazione, rete e raffreddamento.

Questo permette di progettare workload capaci di resistere alla perdita di una singola zona.

C’è però un caveat importante: la presenza delle availability zones nella regione non significa che ogni singolo servizio Azure supporti automaticamente la distribuzione zonale in quella regione. La stessa documentazione Microsoft invita a verificare il supporto per il servizio specifico.

Scegliere “Milano” nella console, quindi, non conclude la progettazione di affidabilità. Devi ancora verificare quali servizi utilizzi, come vengono distribuiti e quale comportamento hanno in caso di guasto.

IaaS, PaaS e servizi gestiti: quanta infrastruttura resta a tuo carico

Azure non appartiene a un unico modello di servizio.

Con una macchina virtuale sei vicino al modello IaaS: Microsoft gestisce data center, hardware e virtualizzazione, mentre tu mantieni un controllo significativo sul sistema operativo, sul software installato e sulla configurazione del workload.

Con servizi come Azure App Service ti sposti invece verso il PaaS: non devi amministrare direttamente le VM e il sistema operativo che eseguono l’applicazione, ma continui a essere responsabile del codice, dei dati e di molte configurazioni.

Con servizi ancora più astratti puoi ridurre ulteriormente il lavoro infrastrutturale.

Il punto non è stabilire se “più gestito è sempre meglio”. Ogni livello comporta uno scambio:

La scelta corretta dipende dal workload.

Se devi installare software legacy con requisiti specifici sul sistema operativo, una VM può essere naturale. Se devi pubblicare una normale web application, gestire direttamente l’OS potrebbe essere lavoro inutile.

A cosa serve Azure: dai server virtuali alle applicazioni cloud-native

I servizi Azure coprono famiglie molto diverse: compute, container, storage, database, networking, identity, sicurezza, analytics, gestione, sviluppo e intelligenza artificiale. Il catalogo ufficiale dei prodotti Azure rende evidente l’ampiezza della piattaforma, ma per scegliere non conviene partire dal numero di servizi disponibili.

Per orientarsi è più utile partire dal problema.

Questi prodotti non sono obbligatoriamente utilizzati insieme. Un workload piccolo può aver bisogno di pochi componenti; un sistema distribuito può combinarne molti.

Compute e applicazioni: Virtual Machines, App Service e Functions

Azure Virtual Machines è il servizio più intuitivo per chi arriva dai server tradizionali.

Scegli una configurazione di CPU e memoria, un sistema operativo e altri parametri, quindi ottieni una VM sulla quale mantieni un livello di controllo significativo.

Questo modello è flessibile, ma porta con sé attività che non scompaiono soltanto perché il server è nel cloud: patch, configurazioni, sicurezza del sistema operativo, applicazioni, monitoring e gestione della capacità restano problemi reali.

Azure App Service sposta invece l’attenzione verso l’applicazione. La piattaforma gestisce molto più dello stack sottostante e consente di distribuire web app e API senza amministrare direttamente le VM.

Azure Functions aumenta ulteriormente l’astrazione: il focus diventa l’esecuzione di funzioni in risposta a eventi e richieste, senza mantenere un server applicativo persistente nel modo tradizionale.

La domanda da farti non è quindi “qual è il servizio più moderno?”, ma quale livello di controllo richiede realmente la mia applicazione?

Storage e database: Blob Storage, Azure SQL e Cosmos DB

I dati richiedono servizi diversi in base alla loro struttura e al modo in cui vengono utilizzati.

Azure Blob Storage è pensato per object storage: file, asset, documenti, backup e altri dati non strutturati possono essere conservati come oggetti invece che all’interno di un filesystem tradizionale esposto da un server.

Azure SQL porta invece il modello database relazionale dentro un servizio gestito. Rispetto all’installazione manuale di SQL Server sopra una macchina virtuale, una parte maggiore del lavoro di piattaforma viene trasferita al provider.

Azure Cosmos DB risponde a scenari differenti, soprattutto quando servono modelli dati e caratteristiche proprie di un database distribuito.

Il criterio corretto non è scegliere il servizio con più funzionalità. Parti da struttura dei dati, pattern di lettura e scrittura, consistenza richiesta, latenza, scalabilità, backup, disponibilità e costo.

Anche qui il servizio più gestito riduce alcune responsabilità, ma non decide al posto tuo come modellare, proteggere e governare i dati.

Container e Kubernetes: AKS e Container Apps

Azure offre più modi per eseguire applicazioni containerizzate.

Azure Kubernetes Service, o AKS, fornisce Kubernetes gestito. Il provider assorbe una parte importante della gestione del cluster, ma Kubernetes rimane visibile al team: deployment, pod, service, ingress, configurazioni, resource limits e molte altre primitive continuano a far parte del modello operativo.

Azure Container Apps offre un livello di astrazione maggiore. Puoi distribuire workload containerizzati senza amministrare direttamente un cluster Kubernetes nello stesso modo.

Questa distinzione riflette bene ciò che abbiamo approfondito nella guida al CaaS: container non significa automaticamente “devo gestire Kubernetes”.

Se Kubernetes è un requisito reale, AKS è una possibilità naturale da valutare. Se il container è soltanto il formato con cui vuoi distribuire una web app, un’API o un worker, un servizio più astratto può ridurre molto lavoro operativo.

Dati e AI: Microsoft Fabric, Microsoft Foundry e il naming attuale

L’area dati e AI è una delle parti di Microsoft Cloud in cui il naming può creare più confusione.

Per le applicazioni e gli agenti di intelligenza artificiale, la denominazione corrente della piattaforma è Microsoft Foundry. Microsoft documenta l’evoluzione da Azure AI Studio ad Azure AI Foundry e poi a Microsoft Foundry nella propria guida alla migrazione dal portale Foundry classico. Anche il portafoglio precedentemente indicato come Azure AI Services viene ricondotto alla nomenclatura Foundry Tools.

Questo dettaglio conta quando cerchi documentazione o confronti tutorial: due guide che usano nomi differenti possono riferirsi a fasi diverse della stessa piattaforma.

Sul fronte dei dati, l’ecosistema comprende database, servizi analytics e integrazioni con Microsoft Fabric.

Non significa che un progetto Azure debba utilizzare l’intero stack Microsoft. Il vantaggio del cloud è proprio poter scegliere solo i componenti che risolvono il problema reale.

Se devi semplicemente eseguire un database per una piccola applicazione, introdurre una piattaforma dati completa sarebbe probabilmente un eccesso di architettura.

Networking, identità, sicurezza e gestione

Compute e database attirano gran parte dell’attenzione, ma un workload reale deve anche comunicare, essere protetto e poter essere osservato.

Azure Virtual Network permette di definire reti e segmentazione per le risorse. Microsoft Entra ID interviene sul piano delle identità. Servizi dedicati possono gestire segreti, policy, protezione e monitoring.

Azure Monitor raccoglie invece segnali utili a osservare infrastruttura e applicazioni.

Questi componenti diventano particolarmente importanti quando un progetto cresce.

Una VM che funziona correttamente non basta a costruire un sistema affidabile. Devi sapere chi può accedervi, quali porte sono raggiungibili, dove vengono conservate le credenziali, come vengono registrati gli eventi e come scopri che qualcosa sta andando male.

È qui che Azure smette definitivamente di assomigliare a un semplice piano hosting.

Quanto costa Azure: pay-as-you-go, account gratuito e costi reali

Parlare di costi Azure come se esistesse un unico listino mensile sarebbe fuorviante. I servizi hanno metriche, configurazioni e modelli tariffari diversi, quindi una stima sensata deve partire dall’architettura prevista e dal consumo atteso.

Gran parte dei servizi viene fatturata in funzione di configurazione e consumo. Il costo finale può dipendere da regione, dimensionamento, sistema operativo, tier, ore di utilizzo, capacità, operazioni, storage, traffico e servizi collegati. La documentazione del calcolatore dei prezzi di Azure mostra proprio come regione, dimensione, sistema operativo, piano tariffario e quantità di utilizzo concorrano alla stima.

Azure gratis: cosa offre l’account gratuito

Microsoft mette a disposizione un account Azure gratuito per i nuovi clienti.

L’offerta Azure per i nuovi account comprende attualmente un credito di 200 USD utilizzabile entro 30 giorni, quote gratuite di alcuni servizi per un periodo limitato e quote mensili di altri servizi disponibili gratuitamente entro determinate soglie.

La parola importante è quote.

“Servizio gratuito” non significa necessariamente utilizzo illimitato. Una risorsa può essere gratuita fino a una determinata quantità e iniziare a generare costi oltre quella soglia.

Le condizioni commerciali possono inoltre cambiare. Prima di aprire un account o basare un laboratorio su una specifica quota gratuita, controlla quindi sempre le condizioni mostrate da Microsoft in quel momento.

Cosa determina il costo: servizio, dimensionamento, regione, traffico e utilizzo

Il modello cloud trasforma molte spese infrastrutturali in voci di consumo.

Per una semplice applicazione potresti avere contemporaneamente:

• capacità compute;
• database;
• storage;
• backup;
• indirizzi IP o componenti di rete;
• traffico in uscita;
• logging e monitoring;
• servizi aggiuntivi.

Il problema è che ogni componente può avere una metrica di fatturazione diversa.

Una VM può dipendere da dimensione e ore di esecuzione. Uno storage può dipendere da capacità, tier e operazioni. Un database gestito può avere un proprio modello di capacità. Il traffico può introdurre altre voci.

È per questo che pay-as-you-go non significa automaticamente spendere meno.

Una macchina sovradimensionata lasciata attiva senza necessità rimane inefficiente anche se viene pagata a consumo. Un ambiente di test dimenticato, log conservati senza criterio o risorse duplicate possono trasformare la flessibilità del cloud in spreco.

Il vero vantaggio del modello a consumo emerge quando esiste anche governance del consumo.

Pricing Calculator, Cost Management, prenotazioni e piani di risparmio

Prima di distribuire un workload conviene costruire almeno una stima con Azure Pricing Calculator.

Il calcolatore consente di combinare più prodotti, configurarne i parametri e stimare il consumo previsto. Per alcuni servizi permette inoltre di valutare formule differenti dal puro pagamento a consumo, come istanze riservate o piani di risparmio quando disponibili.

Una stima rimane però una stima.

In produzione il costo dipenderà dal consumo reale, dalle configurazioni effettive e dal comportamento del workload. Per questo la gestione economica non termina quando hai approvato l’architettura: budget, alert, tag, report e controllo delle risorse inutilizzate diventano parte dell’operatività.

Il modo corretto di confrontare Azure con un’altra soluzione non è quindi:

“quanto costa una VM?”

È più vicino a:

compute + dati + storage + rete + osservabilità + backup + supporto + lavoro operativo + rischio

Solo a quel punto il confronto economico inizia ad avere senso.

Sicurezza e affidabilità: cosa gestisce Microsoft e cosa resta a te

Sicurezza e affidabilità in Azure seguono lo stesso principio visto per i livelli di servizio: spostare un workload nel cloud trasferisce alcune responsabilità al provider, ma non elimina quelle del cliente. Capire dove passa questo confine è essenziale per evitare configurazioni insicure e aspettative sbagliate sulla resilienza.

Il modello di responsabilità condivisa cambia tra IaaS, PaaS e SaaS

Usare Azure non significa trasferire a Microsoft tutta la responsabilità sulla sicurezza.

Microsoft protegge l’infrastruttura fisica del cloud: data center, rete fisica, host e livelli della piattaforma che dipendono dal servizio scelto.

Il cliente continua però a essere responsabile di elementi importanti. Nel proprio modello di responsabilità condivisa, Microsoft mantiene dati, identità, utenti, accessi e diverse configurazioni tra le aree che restano sotto responsabilità del cliente anche quando si utilizzano servizi cloud.

La divisione cambia con il modello.

Con una VM devi quindi occuparti anche del sistema operativo guest.

Con un PaaS Microsoft gestisce più componenti sottostanti, ma una password debole, un ruolo assegnato male, un database esposto o una configurazione applicativa insicura non diventano automaticamente un problema del provider.

La domanda da farti è sempre: quale parte dello stack controllo ancora io?

Backup, alta disponibilità e disaster recovery non sono automatici

Un altro errore frequente è considerare “nel cloud” sinonimo di “protetto da qualsiasi guasto”.

Sono concetti differenti.

Alta disponibilità cerca di mantenere il servizio operativo quando un componente fallisce.

Backup permette di recuperare dati o stato da una copia conservata secondo una policy.

Disaster recovery definisce come ripristinare il servizio dopo un evento grave che compromette una parte significativa dell’ambiente.

Le availability zones possono aiutare a costruire architetture più resilienti, ma non sostituiscono automaticamente il backup. Microsoft chiarisce nella documentazione sulla responsabilità condivisa per l’affidabilità che Azure mette a disposizione capacità come zone, distribuzione multiregione e strategie di backup, mentre spetta al cliente scegliere e configurare quelle appropriate al proprio workload.

Una configurazione “highly available” può quindi replicare perfettamente anche un errore applicativo o una cancellazione indesiderata.

Per questo disponibilità, protezione dei dati e ripristino devono essere progettati come problemi correlati ma distinti.

Quando Azure ha senso e quando valutare un’alternativa

Azure non è la scelta migliore perché è grande, perché appartiene a Microsoft o perché offre moltissimi servizi. Il criterio corretto è verificare se la piattaforma riduce problemi reali del workload senza introdurre un livello di costo e complessità sproporzionato.

Diventa una buona scelta quando le sue caratteristiche risolvono requisiti concreti del workload meglio delle alternative.

Stack Microsoft, cloud ibrido e servizi gestiti: quando Azure entra naturalmente in shortlist

Azure merita una valutazione seria quando il progetto utilizza già in modo significativo tecnologie e identità Microsoft oppure quando alcuni servizi gestiti della piattaforma riducono realmente il lavoro che il team dovrebbe svolgere autonomamente.

Esempi tipici sono applicazioni .NET, ambienti Windows Server, workload SQL Server, integrazioni con Microsoft Entra ID o progetti che devono collegare risorse cloud e infrastruttura esistente.

Anche la presenza di Italy North può essere rilevante quando localizzazione, latenza o architettura richiedono risorse in Italia, fermo restando che disponibilità e caratteristiche devono essere verificate per ogni servizio concreto.

Lo stesso ragionamento vale per PaaS, database gestiti, container e serverless: Azure crea valore se questi servizi eliminano lavoro operativo senza introdurre vincoli peggiori del problema che stai cercando di risolvere.

Quando complessità, competenze o modello di costo possono renderlo eccessivo

Non ogni sito o applicazione ha bisogno di un hyperscaler.

Se devi pubblicare un normale sito aziendale, un progetto WordPress o una piccola applicazione con requisiti standard, una soluzione gestita più verticale può essere molto più semplice.

Azure introduce concetti come subscription, resource group, identità, networking, monitoraggio, policy, billing e numerosi modelli di servizio.

Questa flessibilità è un vantaggio soltanto quando viene utilizzata.

Se il progetto richiede una sola applicazione e un database standard, costruire una complessa architettura cloud può significare aumentare competenze necessarie, superficie operativa e tempo di gestione senza ottenere un beneficio equivalente.

Lo stesso vale per il team.

Adottare Kubernetes, infrastruttura distribuita o decine di servizi perché “sono cloud-native” non rende automaticamente un progetto migliore. La complessità tecnica deve essere giustificata da disponibilità, scala, deployment, sicurezza, organizzazione o altri requisiti reali.

Azure, AWS e Google Cloud: confrontare il workload, non il logo

Se devi scegliere fra Azure, AWS e Google Cloud, evita di partire da una classifica generale.

I provider evolvono continuamente e un vantaggio astratto conta poco se non riguarda il tuo workload.

Costruisci invece una matrice di requisiti:

Questa analisi può portarti ad Azure, AWS, Google Cloud o a una piattaforma più semplice.

Il risultato corretto non è il provider con più servizi. È quello che soddisfa meglio i requisiti con un livello di costo, complessità e rischio accettabile.

Conclusione

Microsoft Azure è molto più comprensibile quando smetti di considerarlo un catalogo di prodotti e inizi a ragionare in termini di workload, livello di gestione e responsabilità.

Se hai bisogno di controllo infrastrutturale puoi lavorare vicino al modello IaaS. Se vuoi concentrarti sull’applicazione puoi spostarti verso PaaS, container gestiti o serverless. Database, storage, networking, identity, monitoring e AI entrano soltanto quando il problema li richiede.

Lo stesso criterio dovrebbe guidare costi e sicurezza. Pagare a consumo non rende automaticamente un’architettura economica, e utilizzare un cloud pubblico non trasferisce automaticamente al provider la responsabilità su dati, identità, configurazioni, backup e comportamento dell’applicazione.

Prima di scegliere un servizio Azure, quindi, scrivi i requisiti del workload: cosa deve eseguire, quali dati utilizza, dove deve essere disponibile, quale livello di controllo serve, quali competenze possiede il team e quanto puoi spendere.

A quel punto il catalogo Azure smette di essere un elenco enorme di nomi e diventa ciò che dovrebbe essere: un insieme di componenti da usare solo quando risolvono un problema concreto.