Microsoft AZ-900: Concetti di Cloud — Guida allo studio

By Laurynas Brazys · 23 July 2026 · #microsoft #az-900 #certification #exam-prep #study-guide

Fa parte della Microsoft Azure AZ-900 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Il cloud computing fornisce risorse IT a consumo su Internet con provisioning rapido, portata globale e resilienza integrata. Il passaggio da un’infrastruttura on-premise ad Azure modifica sia le scelte tecnologiche sia i modelli operativi: la pianificazione della capacità lascia il posto alla scalabilità elastica, gli acquisti in conto capitale si trasformano in spesa operativa e la manutenzione dell’hardware diventa una responsabilità della piattaforma. Comprendere questi concetti è essenziale per selezionare i servizi giusti, progettare per l’alta disponibilità e controllare i costi.

Caratteristiche principali del cloud: scalabilità, elasticità, agilità e resilienza

La scalabilità è la capacità di un carico di lavoro di gestire un aumento della domanda aggiungendo risorse. In Azure assume due forme: la scalabilità verticale (scale-up), scegliendo VM di dimensioni maggiori o piani di App Service superiori, e la scalabilità orizzontale (scale-out), aggiungendo più istanze tramite Virtual Machine Scale Sets (VMSS), pool di nodi di Azure Kubernetes Service (AKS) o l’autoscale di App Service. La scalabilità nella direzione opposta riduce la capacità e i costi quando la domanda diminuisce. Progettare livelli stateless ed esternalizzare lo stato (ad esempio, su Azure Cache for Redis o Azure SQL Database) rende la scalabilità orizzontale prevedibile e veloce. L’elasticità è la scalabilità automatizzata e basata su policy che allinea continuamente la capacità al carico. Le regole di autoscale di Azure Monitor, il cluster autoscaler di AKS e le opzioni serverless come Azure Functions o i piani Consumption/Elastic Premium espandono e contraggono le risorse quasi in tempo reale. Le architetture elastiche minimizzano la capacità inutilizzata e sono adatte a carichi di lavoro con picchi o stagionali, allineando la spesa in modo preciso all’utilizzo. L’agilità è la velocità con cui i team implementano le modifiche. Il deployment di risorse Azure tramite template Bicep o ARM, pipeline di GitHub Actions o Azure DevOps e astrazioni di risorse come App Service o AKS consentono rilasci frequenti e a basso rischio. Il provisioning self-service tramite RBAC e policy di controllo (guardrail) riduce i tempi di attesa mantenendo la governance. L’agilità è il prodotto sia della piattaforma sia delle pratiche organizzative; più la piattaforma astrae le attività onerose e non differenzianti, più velocemente i team possono muoversi. La tolleranza ai guasti e il disaster recovery affrontano diversi ambiti di guasto. La tolleranza ai guasti mitiga i guasti di componenti e datacenter all’interno di una regione utilizzando i Set di disponibilità (distribuendo le VM su domini di errore/aggiornamento), le Zone di disponibilità (datacenter fisicamente separati all’interno di una regione), i load balancer e percorsi dati ridondanti. Il disaster recovery prepara a interruzioni a livello di regione con la replica tra regioni (storage GRS/RA-GRS, replica geografica attiva di Azure SQL, scritture multi-regione di Cosmos DB) e strumenti di ripristino come Azure Site Recovery. Definite chiari obiettivi RTO/RPO e testate il failover per garantire che il progetto soddisfi gli obiettivi di continuità operativa.

Modelli di servizio e responsabilità condivisa

I modelli di servizio cloud determinano cosa gestisci tu rispetto a cosa gestisce Azure. L’Infrastructure as a Service (IaaS) espone i componenti di base per elaborazione (compute), archiviazione (storage) e rete (networking). Tu controlli il sistema operativo guest, il runtime e le applicazioni: l’ideale quando hai bisogno di immagini personalizzate, middleware specializzato o pieno controllo. La Platform as a Service (PaaS) astrae il sistema operativo e gran parte del middleware, fornendo runtime gestiti, database e servizi di integrazione, in modo che i team possano concentrarsi su codice e dati. Il Software as a Service (SaaS) fornisce applicazioni complete, fruibili tramite browser o API, con configurazione minima e nessun obbligo di hosting dell’applicazione. Il modello di responsabilità condivisa chiarisce i confini operativi. In IaaS, Azure gestisce il datacenter fisico, gli host e l’hypervisor; tu ti occupi di patching e hardening del SO, aggiornamenti delle applicazioni, identità e accessi e governance dei dati. In PaaS, Azure gestisce anche il SO e il middleware della piattaforma; tu gestisci il codice dell’applicazione, la configurazione e i dati. In SaaS, Azure (o il fornitore SaaS) gestisce l’intero stack; tu gestisci utenti, accessi, classificazione dei dati e configurazione dell’utilizzo. In tutti i modelli, i clienti mantengono la responsabilità per l’identità, le autorizzazioni, la sicurezza degli endpoint e le policy di protezione dei dati. La scelta del modello giusto influisce sugli obiettivi di disponibilità e sui costi. Il deployment di macchine virtuali Azure è un’attività IaaS; le API web su Azure App Service o i container su AKS riflettono il modello PaaS; Microsoft 365 e Dynamics 365 sono SaaS. Prediligi PaaS e SaaS quando possibile per accelerare il delivery e ridurre l’onere operativo, riservando l’IaaS ai carichi di lavoro che richiedono il controllo a livello di sistema operativo o che hanno dipendenze da sistemi legacy.

• IaaS
  • Servizi Azure tipici: Azure Virtual Machines, VM Scale Sets, Azure Disks, Virtual Network
  • Cosa gestisci: SO guest, patch, runtime, app, dati, backup, AV/EDR
  • Quando sceglierlo: Pieno controllo del SO, middleware personalizzato, lift-and-shift
• PaaS
  • Servizi Azure tipici: Azure App Service, Azure SQL Database/Managed Instance, AKS, Azure Functions, Azure Integration Services
  • Cosa gestisci: Codice/configurazione, schema, dati, identità e accessi
  • Quando sceglierlo: Delivery più rapido, scalabilità/HA integrati, operatività ridotta
• SaaS
  • Servizi Azure tipici: Microsoft 365, Dynamics 365, Power BI, Azure DevOps Services
  • Cosa gestisci: Utenti, ruoli, utilizzo/configurazione dei dati
  • Quando sceglierlo: App complete con gestione minima

Modelli di deployment e ambito di scalabilità

Il cloud pubblico distribuisce i workload in data center di proprietà di Microsoft, condivisi tra più tenant con isolamento logico. Offre il catalogo più ampio, una portata globale, un provisioning rapido e un modello puramente pay-as-you-go. Il cloud privato dedica l’infrastruttura a una singola organizzazione, spesso per motivi normativi o di sovranità dei dati, e può essere eseguito su stack convalidati da Azure come Azure Stack Hub o Azure Stack HCI. Il cloud ibrido connette l’ambiente on-premise e Azure con identità, policy e networking coerenti, consentendo migrazioni graduali e la localizzazione dei dati, sfruttando al contempo l’elasticità del cloud dove opportuno. La scalabilità globale rispetto a quella locale riguarda l’ambito dei miglioramenti in termini di disponibilità e prestazioni. La scalabilità locale mantiene il traffico all’interno di una region, utilizzando Zone di disponibilità, VM Scale Sets, Application Gateway e Azure Load Balancer per aggiungere istanze e isolare i guasti dei data center. La scalabilità globale distribuisce il traffico tra più region utilizzando Azure Front Door (bilanciamento del carico globale moderno di livello 7 con anycast e WAF), Azure Traffic Manager (bilanciamento del carico basato su DNS) e servizi dati con replica geografica come la geo-replica di Azure SQL o la distribuzione multi-region di Cosmos DB. Le architetture multi-region active/active migliorano la latenza e la resilienza, ma richiedono un’attenta pianificazione della coerenza dei dati e dei costi. La scelta di un modello di deployment inizia spesso da vincoli di conformità e connettività ed evolve con il ciclo di vita dell’applicazione. Le nuove applicazioni web greenfield vengono spesso implementate su PaaS nel cloud pubblico per ottenere velocità e scalabilità. I sistemi line-of-business complessi con dipendenze possono iniziare in modalità ibrida — mantenendo alcuni servizi on-premise mentre i front-end e i tier stateless vengono spostati su Azure — prima di completare la transizione man mano che le dipendenze vengono modernizzate.

• Pubblico
  • Proprietà/Posizione: Region di proprietà di Microsoft
  • Accesso tipico: Internet/VPN/ExpressRoute
  • Casi d’uso: Scalabilità elastica, portata globale, innovazione rapida
  • Esempi Azure: La maggior parte dei servizi Azure, Azure Front Door, Azure App Service
• Privato
  • Proprietà/Posizione: Infrastruttura dedicata al cliente (on-premise o in hosting)
  • Accesso tipico: Reti private
  • Casi d’uso: Sovranità, workload isolati, conformità rigorosa
  • Esempi Azure: Azure Stack Hub, Azure Stack HCI, AKS on HCI
• Ibrido
  • Proprietà/Posizione: Misto di on-premise e Azure
  • Accesso tipico: VPN site-to-site o ExpressRoute
  • Casi d’uso: Migrazione graduale, localizzazione dei dati, integrazione di sistemi legacy
  • Esempi Azure: Azure VPN Gateway, ExpressRoute, Azure Arc

Modelli di costo: CapEx e OpEx a confronto, prezzi a consumo, pay-as-you-go e capacità riservata

L’approvvigionamento on-premise è tipicamente una spesa in conto capitale (CapEx): grandi acquisti iniziali di server, storage e apparati di rete ammortizzati nel corso degli anni. Azure ribalta questo modello in una spesa operativa (OpEx): i servizi sono misurati e fatturati in base al consumo effettivo — secondi di CPU, GB-mese, transazioni — spostando la spesa al momento in cui il valore viene realizzato. Questo modello di prezzi a consumo riduce il sovradimensionamento e lega i costi ai modelli di utilizzo. Il modello pay-as-you-go massimizza la flessibilità: è possibile avviare e arrestare le risorse a piacimento senza alcun impegno a termine. Per i workload a regime, Azure offre sconti basati sulla prenotazione come le Reserved Virtual Machine Instances, la capacità riservata di Azure SQL Database, le prenotazioni di RU/s di Cosmos DB e la capacità riservata di Storage. Impegni di uno o tre anni possono generare risparmi significativi, consentendo opzionalmente la flessibilità sulle dimensioni delle istanze e un ambito condiviso tra le sottoscrizioni. Le opzioni complementari includono gli Azure Savings Plans for Compute, che applicano tariffe scontate a tutti i servizi di calcolo idonei, e le Spot VM per workload interrompibili di tipo batch a sconti molto elevati. Un’efficace governance dei costi abbina il modello commerciale corretto a controlli di tipo ingegneristico. L’Autoscale riduce la capacità inutilizzata; i tier serverless eliminano l’infrastruttura quando è inattiva; l’Azure Hybrid Benefit applica le licenze esistenti di Windows Server e SQL Server; i prezzi per Dev/Test riducono la spesa per gli ambienti non di produzione. Azure Cost Management + Billing fornisce budget, rilevamento delle anomalie e allocazione dei costi per un’ottimizzazione continua.

• Pay-as-you-go
  • Impegno: Nessuno
  • Sconto tipico vs PAYG: 0%
  • Flessibilità: Massima flessibilità; avvio/arresto in qualsiasi momento
  • Ideale per: Workload imprevedibili o di breve durata
• Reserved VM Instances / Capacità riservata
  • Impegno: 1 o 3 anni
  • Sconto tipico vs PAYG: Fino a ~72% (con Azure Hybrid Benefit)
  • Flessibilità: L’ambito può essere condiviso; cambio consentito; penali per recesso anticipato
  • Ideale per: Calcolo 24x7 a regime, database, Cosmos DB
• Savings Plan for Compute
  • Impegno: Impegno di spesa di 1 o 3 anni
  • Sconto tipico vs PAYG: Fino a ~65%
  • Flessibilità: Si applica a VM, AKS, Functions Premium, App Service
  • Ideale per: Calcolo misto con tipi di istanza variabili
• Spot VM
  • Impegno: Nessuno (dipendente dalla capacità)
  • Sconto tipico vs PAYG: Fino a ~90%
  • Flessibilità: Possono essere revocate; nessuno SLA
  • Ideale per: Lavori batch, stateless, CI, rendering

Problema pratico: PeakGear Retail: scalabilità stagionale con controllo dei costi e resilienza

Scenario: PeakGear Retail gestisce un sito di e-commerce con picchi di traffico prevedibili a fine mese e durante le festività. L’azienda vuole migrare da VM on-premise ad Azure, ridurre le spese in conto capitale (CAPEX), mantenere un obiettivo di disponibilità del 99,99% per il livello web e implementare un piano di disaster recovery con un RTO di quattro ore e un RPO di 15 minuti. L’identità deve integrarsi con gli utenti esistenti tramite Microsoft Entra ID.

Sfida: Progettare un’architettura e un modello di costo su Azure che offra una scalabilità elastica per i picchi di traffico, tolleranza ai guasti a livello di zona, disaster recovery tra aree geografiche e semplicità operativa, minimizzando al contempo i costi durante i periodi di non picco.

Approccio consigliato:

1. Distribuire l’API web e lo storefront su Azure App Service (PaaS) utilizzando i piani Premium v3 per ottenere scalabilità automatica integrata, patching della piattaforma gestito e opzioni di ridondanza di zona.
2. Posizionare due o più istanze di App Service dietro Azure Front Door Standard/Premium per un punto di ingresso anycast globale, terminazione SSL, WAF e routing basato sul percorso; abilitare i probe di integrità e l’affinità di sessione secondo necessità.
3. Utilizzare Azure SQL Database Business Critical con ridondanza di zona nell’area geografica primaria; configurare la replica geografica attiva verso un’area geografica secondaria abbinata, puntando a un RPO di 15 minuti.
4. Archiviare i contenuti statici in Azure Storage con RA-GRS; utilizzare Azure CDN from Microsoft come frontend per scaricare la larghezza di banda e migliorare la latenza.
5. Implementare regole di scalabilità automatica basate su CPU, richieste e profondità della coda per aumentare il numero di istanze (scale out) durante i picchi e ridurlo (scale in) durante i periodi di calma; per i processi in background, utilizzare i piani Azure Functions Consumption o Elastic Premium.
6. Ottenere una disponibilità del 99,99% per il livello web abilitando la ridondanza di zona (multi-zona) per il piano di App Service o distribuendo le istanze tra le Zone di Disponibilità dove supportato.
7. Adottare inizialmente il modello pay-as-you-go per maggiore flessibilità; per la capacità di base stabile identificata dopo 30 giorni, acquistare una Reserved Instance da 1 anno per i piani di App Service (tramite Savings Plan for Compute che copre App Service) e capacità riservata per SQL Database per ridurre i costi di gestione correnti.
8. Integrare Microsoft Entra ID per l’accesso di utenti e amministratori; applicare il principio del privilegio minimo con i ruoli predefiniti e l’accesso condizionale; proteggere i segreti in Azure Key Vault, a cui fanno riferimento App Service e le pipeline di distribuzione.
9. Definire e testare i runbook di DR: eseguire il failover di SQL sul secondario, aggiornare le priorità dell’origine di Front Door per attivare l’area geografica secondaria e convalidare lo stato di salute dell’applicazione entro un RTO di quattro ore.
10. Implementare Azure Monitor e Log Analytics per centralizzare metriche, tracce e log; configurare avvisi e dashboard; impostare budget e avvisi per anomalie in Azure Cost Management per ottimizzare continuamente la spesa.

Logica di Azure: I servizi PaaS (App Service e Azure SQL Database) massimizzano l’agilità e delegano la manutenzione del sistema operativo e della piattaforma secondo il modello di responsabilità condivisa, abilitando al contempo la scalabilità automatica per l’elasticità. L’implementazione con ridondanza di zona e la replica multi-regione forniscono tolleranza ai guasti all’interno di un’area geografica e disaster recovery tra aree geografiche, rispettando gli RPO/RTO dichiarati. Front Door fornisce un ingresso globale, routing basato sullo stato di integrità e protezione WAF. Iniziare con il modello pay-as-you-go preserva la flessibilità durante la migrazione; impegnarsi con capacità riservata o un Savings Plan per la baseline misurata riduce i costi per l’utilizzo costante, mentre la scalabilità automatica riduce la spesa durante i periodi di bassa attività. Microsoft Entra ID centralizza l’identità e il controllo degli accessi, e Azure Monitor con Cost Management mantiene la visibilità operativa e finanziaria.

Tutti i domini · Architettura e Infrastruttura Globale di Azure →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Microsoft →