Microsoft AZ-900: Architettura e Infrastruttura Globale di Azure — 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.

L’architettura globale di Azure è progettata per fornire servizi cloud resilienti, performanti e conformi su larga scala. Comprendere la disposizione fisica di aree geografiche, regioni e zone di disponibilità, insieme alla gerarchia logica di gruppi di gestione, sottoscrizioni, gruppi di risorse e risorse, è fondamentale per una progettazione e una governance affidabili. Il piano di controllo fornito da Azure Resource Manager, combinato con i modelli dichiarativi, consente implementazioni coerenti e ripetibili in linea con le policy aziendali e i requisiti di sicurezza. Le decisioni di progettazione in questo ambito influenzano direttamente gli obiettivi di disponibilità, gli obblighi di residenza dei dati e l’esperienza utente a livello mondiale. La selezione del modello di ridondanza corretto, il calcolo degli SLA compositi e la scelta di servizi di routing globale come Azure Front Door, Traffic Manager e Azure CDN sono elementi centrali per raggiungere gli obiettivi di continuità operativa, conformità e prestazioni.

Aree geografiche, Regioni, Zone di disponibilità e Coppie di regioni

Le aree geografiche di Azure sono insiemi definiti di regioni che preservano la residenza dei dati e i confini di conformità. Esempi includono Stati Uniti, Europa, Regno Unito, Australia e Canada, oltre a cloud sovrani con modelli di conformità e connettività distinti. I carichi di lavoro che devono rimanere all’interno di una data giurisdizione dovrebbero essere distribuiti in regioni appartenenti all’area geografica di destinazione per garantire l’allineamento normativo e la residenza dei dati. Una regione è un insieme di data center distribuiti all’interno di un perimetro definito dalla latenza e connessi tramite una rete dedicata a bassa latenza. Non tutti i servizi o le funzionalità sono disponibili in ogni regione, quindi la capacità e la disponibilità delle funzionalità dovrebbero essere verificate nelle prime fasi della pianificazione. Le regioni che supportano le Zone di disponibilità forniscono tre o più zone di data center fisicamente separate con alimentazione, raffreddamento e reti indipendenti. I servizi con ridondanza della zona (ZRS) e un’architettura distribuita tra le zone proteggono dai guasti a livello di data center, mantenendo al contempo un accesso a bassa latenza all’interno della regione. Ogni regione di Azure è abbinata a un’altra regione all’interno della stessa area geografica per formare una coppia di regioni (ad esempio, Europa settentrionale con Europa occidentale, Stati Uniti orientali con Stati Uniti occidentali). Le coppie di regioni consentono il ripristino prioritario durante interruzioni su vasta scala, aggiornamenti scaglionati della piattaforma e la replica dei dati per determinati servizi. Le opzioni con ridondanza geografica di Azure Storage (GRS/GZRS) replicano i dati in modo asincrono nella regione abbinata; quando è richiesto l’accesso in lettura al secondario, si utilizzano RA-GRS o RA-GZRS per consentire le letture dall’endpoint secondario durante un’interruzione o un failover pianificato. Per i carichi di lavoro mission-critical che richiedono sia alta disponibilità all’interno della regione sia disaster recovery tra regioni, combinare la ridondanza della zona con la replica tramite coppia di regioni. Il bilanciamento tra latenza, resilienza e conformità porta a un modello comune: distribuire i carichi di lavoro attivi tra le zone in una regione primaria e proteggersi dai disastri regionali replicando i dati e fornendo percorsi di failover verso la regione abbinata. Verificare regolarmente i runbook di failover e il comportamento del routing DNS o front-end per garantire che gli obiettivi di ripristino siano soddisfatti.

• Area geografica (Geography)
  • Ambito: Confine multi-regionale
  • Vantaggio chiave: Residenza dei dati e conformità
  • Uso tipico: Allineamento normativo (es. dati UE)
• Regione (Region)
  • Ambito: Singola area metropolitana
  • Vantaggio chiave: Accesso ai servizi a bassa latenza
  • Uso tipico: Posizione di deployment primaria
• Zona di disponibilità (Availability Zone)
  • Ambito: Data center distinti all’interno di una regione
  • Vantaggio chiave: Isolamento dei guasti a livello di data center
  • Uso tipico: Alta disponibilità all’interno della regione
• Coppia di regioni (Region Pair)
  • Ambito: Due regioni nella stessa area geografica
  • Vantaggio chiave: Ripristino e aggiornamenti coordinati
  • Uso tipico: Disaster recovery tra regioni

Organizzazione e Governance delle Risorse: Gruppi di Gestione, Sottoscrizioni, Gruppi di Risorse e Risorse

La gerarchia di gestione di Azure permette di controllare policy, accessi e costi su larga scala. I gruppi di gestione si trovano al di sopra delle sottoscrizioni e consentono di applicare Azure Policy e il controllo degli accessi in base al ruolo (RBAC) in modo centralizzato, con un’ereditarietà che si propaga ai gruppi di gestione e alle sottoscrizioni figli. Questo è il costrutto ideale per segmentare l’infrastruttura per divisioni aziendali, livelli di ambiente (produzione, non-produzione) o confini normativi, mantenendo al contempo dei guardrail uniformi. Le sottoscrizioni rappresentano il confine amministrativo, di fatturazione e di quota. Sono adatte per isolare i costi e gli accessi per business unit, ambienti o applicazioni. Utilizzare un design coerente per le sottoscrizioni per separare la produzione dalla non-produzione e per imporre limiti e budget. Per le organizzazioni con più divisioni e un’amministrazione decentralizzata, assegnare a ciascuna divisione una o più sottoscrizioni e collocarle sotto gruppi di gestione specifici per la divisione, al fine di ottenere un’ereditarietà pulita delle policy e dell’RBAC. I gruppi di risorse sono contenitori logici per risorse che condividono un ciclo di vita. Permettono deployment atomici, un tagging coerente e operazioni sul ciclo di vita come la cancellazione o il blocco. Raggruppare le risorse che vengono distribuite, aggiornate e ritirate insieme, come un livello web e i suoi componenti di monitoraggio. Utilizzare i tag per gestire gli attributi di chargeback/showback, proprietà, ambiente e conformità tra risorse e gruppi. I blocchi (ReadOnly, CanNotDelete) aggiungono una protezione contro la cancellazione accidentale a livello di risorsa o di gruppo. Le risorse sono le istanze dei servizi distribuiti (VM, piani di App Service, account di archiviazione). Gli ambiti RBAC (gruppo di gestione, sottoscrizione, gruppo di risorse, risorsa) consentono di concedere l’accesso con privilegi minimi esattamente dove è necessario. Per i deployment multi-divisione, mantenere un singolo tenant di Microsoft Entra ID a meno che non vi sia un forte requisito di conformità o autonomia che richieda più tenant; le sottoscrizioni e i gruppi di gestione forniscono in genere una separazione sufficiente con un sovraccarico amministrativo molto inferiore.

• Gruppo di Gestione (Management Group)
  • Scopo primario: Governance a livello di organizzazione
  • Controlli applicati: RBAC, Policy, Blueprints (tramite Policy + template)
  • Pattern comuni: Segmentazione per divisione/normativa
• Sottoscrizione (Subscription)
  • Scopo primario: Confine di fatturazione e quota
  • Controlli applicati: Budget, RBAC, Policy
  • Pattern comuni: Isolamento per BU o per ambiente
• Gruppo di Risorse (Resource Group)
  • Scopo primario: Confine del ciclo di vita
  • Controlli applicati: Blocchi, Tag, RBAC
  • Pattern comuni: Per applicazione o unità di carico di lavoro
• Risorsa (Resource)
  • Scopo primario: Istanza del servizio
  • Controlli applicati: RBAC a livello di istanza, Tag
  • Pattern comuni: Componenti di servizio individuali

Azure Resource Manager e Template

Azure Resource Manager (ARM) è il piano di controllo per distribuire, aggiornare ed eliminare le risorse di Azure attraverso un’API coerente e un modello basato sui ruoli. ARM fornisce operazioni idempotenti, gestione delle dipendenze, tagging e applicazione delle policy al momento del deployment, consentendo di integrare la governance della piattaforma in ogni modifica. I template ARM dichiarativi descrivono lo stato desiderato del proprio ambiente in formato JSON e supportano parametri, variabili, condizioni e template collegati modulari. Permettono deployment ripetibili e versionati tra ambienti e sottoscrizioni. Per un’esperienza di authoring più snella, Bicep offre una sintassi concisa che viene convertita (transpilata) in template ARM, mantenendo lo stesso motore di deployment e gli stessi vantaggi. Archiviare i template nel controllo del codice sorgente, impacchettarli come specifiche di template (template specs) per la condivisione e integrarli nelle pipeline di CI/CD per garantire modifiche all’infrastruttura auditabili e prive di deviazioni (drift-free). I valori sensibili come le password di amministratore o le stringhe di connessione non dovrebbero mai essere inseriti direttamente nei template. Utilizzare parametri di tipo secureString/secureObject con riferimenti a Key Vault, in modo che ARM recuperi i segreti al momento del deployment senza esporli nei log. Combinare i template con le identità gestite (managed identities) per eliminare le credenziali cablate (hardcoded) nell’automazione. Questo approccio riduce il rischio preservando al contempo la piena automazione per i deployment su larga scala e multi-sottoscrizione.

• Deployment idempotenti
  • Supporto ARM/Template: Sì
  • Risultato: Modifiche sicure e ripetibili
• Applicazione delle policy al deployment
  • Supporto ARM/Template: Sì
  • Risultato: Guardrail integrati nelle pipeline
• Composizione modulare
  • Supporto ARM/Template: Moduli collegati / Moduli Bicep
  • Risultato: Riusabilità e standardizzazione
• Gestione dei segreti
  • Supporto ARM/Template: Riferimenti a Key Vault
  • Risultato: Nessun segreto nel codice o nei log

Disponibilità, SLA, SLA compositi e ciclo di vita del servizio

Azure pubblica accordi sul livello di servizio (SLA) con penali finanziarie per i servizi in disponibilità generale (GA). Per le macchine virtuali, la disponibilità dipende dalla topologia di deployment: una singola VM con archiviazione Premium SSD ha un SLA del 99,9%; due o più VM in un set di disponibilità hanno un SLA del 99,95%; e due o più VM distribuite tra zone di disponibilità raggiungono un SLA del 99,99%. I servizi di piattaforma (ad esempio, Azure SQL Database o App Service) hanno i propri SLA, che possono variare in base al livello di servizio (tier) o all’opzione di ridondanza. Allineare l’architettura all’SLA target selezionando il modello di ridondanza e i livelli di servizio appropriati. Quando una soluzione dipende da più servizi, l’SLA composito è il prodotto degli SLA individuali se tutti i componenti sono necessari per il funzionamento dell’app. Ad esempio, se un’app web (99,95%) dipende da un database (99,99%), la disponibilità composita è circa 0,9995 × 0,9999 = 99,94%. Aumentare la ridondanza a qualsiasi livello — come distribuire tra più zone, aggiungere più istanze dietro un bilanciatore del carico o utilizzare archivi dati geo-ridondanti — migliora la disponibilità effettiva. Al contrario, l’aggiunta di dipendenze seriali riduce l’SLA composito e dovrebbe essere giustificata da un chiaro valore funzionale. Lo stato del ciclo di vita del servizio influisce sulle garanzie di affidabilità. Le funzionalità in anteprima pubblica (public preview) sono offerte per raccogliere feedback e possono essere limitate a determinate aree geografiche o presentare lacune funzionali; in genere non hanno un SLA e non sono raccomandate per i percorsi critici di produzione. Le funzionalità in disponibilità generale (GA) sono pronte per la produzione e coperte da un SLA. Le roadmap e le pianificazioni di rilascio per area geografica dovrebbero essere monitorate per evitare di fare affidamento involontariamente su funzionalità in anteprima nei progetti di produzione, specialmente in ambienti sensibili alla conformità. Gli obiettivi di ripristino di emergenza (disaster recovery) come RPO e RTO completano gli SLA e guidano le scelte progettuali come la replica tra zone o tra aree geografiche, la frequenza dei backup e l’orchestrazione del failover. Validare regolarmente le procedure di failover per garantire che le prestazioni di ripristino misurate siano in linea con gli obiettivi di business e che anche le dipendenze relative a DNS, certificati e identità vengano ripristinate come previsto.

• Singola VM (Premium SSD)
  • SLA indicativo: 99,9%
  • Note: Utilizzare per carichi di lavoro non critici o app tolleranti
• 2+ VM in un Set di Disponibilità (Availability Set)
  • SLA indicativo: 99,95%
  • Note: Protegge da guasti a livello di rack/dominio di errore (fault domain)
• 2+ VM distribuite tra Zone di Disponibilità (Availability Zones)
  • SLA indicativo: 99,99%
  • Note: Protegge da guasti a livello di data center
• Funzionalità in Anteprima Pubblica (Public Preview)
  • SLA indicativo: Nessun SLA con penali finanziarie
  • Note: Da valutare; evitare sui percorsi critici
• Funzionalità in GA (dipendente dal livello di servizio)
  • SLA indicativo: Coperto da SLA
  • Note: Verificare gli SLA specifici per livello di servizio e area geografica

Routing globale e distribuzione di contenuti: Azure Front Door, Traffic Manager e Azure CDN

L’esperienza utente globale dipende da un routing intelligente, dalla prossimità ai contenuti e da un failover rapido. Azure Front Door è un reverse proxy globale di Livello 7 basato su anycast con Web Application Firewall (WAF), terminazione TLS, routing basato su URL/percorso, affinità di sessione e probe di integrità dall’edge. Accelera i contenuti dinamici tramite split-TCP e ottimizzazioni del protocollo e fornisce un failover quasi istantaneo tra le origini. Front Door è ideale per applicazioni web e API multi-regione attive-attive o attive-passive in cui sono necessarie sia prestazioni che sicurezza centralizzata all’edge. Azure Traffic Manager è un servizio di distribuzione del traffico basato su DNS che indirizza i client verso l’endpoint migliore utilizzando policy come priorità, ponderata, prestazioni (latenza), geografica, subnet o multivalore. Poiché opera a livello di DNS, supporta endpoint non-HTTP (ad es. servizi TCP) e scenari ibridi, ma la velocità di failover è limitata dal TTL del DNS e dalla cache del client. Traffic Manager non funge da proxy per il traffico né accelera i contenuti; risponde semplicemente alle richieste DNS con l’endpoint scelto. Azure CDN memorizza nella cache i contenuti statici presso i punti di presenza (PoP) dell’edge per ridurre la latenza e alleggerire il carico delle origini. È particolarmente adatto per asset statici di grandi dimensioni come immagini, video, script e download. Sebbene la CDN riduca i round trip per i contenuti memorizzabili nella cache, non è un bilanciatore del carico globale consapevole dello stato di integrità per le origini dinamiche; va combinata con Front Door o Traffic Manager per il failover tra più origini o per la logica di routing dinamico. Molte architetture posizionano la CDN per la cache degli asset statici e Front Door per il traffico dinamico e la sicurezza di fronte alla stessa applicazione.

• Azure Front Door (Std/Prm)
  • Livello/Meccanismo: Proxy anycast di Livello 7
  • Casi d’uso principali: Bilanciamento del carico globale, sicurezza all’edge, accelerazione
  • Metodi di routing: Priorità, ponderato; regole basate su percorso/host
  • Probe di integrità: Probe dai PoP dell’edge
  • Velocità di failover: Secondi (quasi istantaneo)
  • Accelerazione dinamica: Sì
  • Caching statico: Sì (basato su regole)
  • WAF disponibile: Sì (integrato)
  • Pattern tipico: Front Door di fronte ad app web/API multi-regione
• Azure Traffic Manager
  • Livello/Meccanismo: Policy basata su DNS
  • Casi d’uso principali: Routing DNS tra aree geografiche; endpoint non-HTTP
  • Metodi di routing: Priorità, ponderato, prestazioni, geografico, subnet, multivalore
  • Probe di integrità: Probe globali degli endpoint
  • Velocità di failover: Legata al TTL (da decine di secondi a minuti)
  • Accelerazione dinamica: No
  • Caching statico: No
  • WAF disponibile: N/D
  • Pattern tipico: Indirizzamento DNS per servizi HTTP e non-HTTP
• Azure CDN
  • Livello/Meccanismo: Rete di caching all’edge
  • Casi d’uso principali: Offload di contenuti statici e riduzione della latenza
  • Metodi di routing: N/D (regole di cache)
  • Probe di integrità: N/D (failover opzionale del gruppo di origini)
  • Velocità di failover: N/D (basato sulla cache)
  • Accelerazione dinamica: No (oltre la cache)
  • Caching statico: Sì
  • WAF disponibile: Tramite Front Door Premium o un WAF separato
  • Pattern tipico: CDN per gli asset + Front Door/Traffic Manager per le origini

Problema Pratico: Progettare una Piattaforma Web Altamente Disponibile, Conforme e Performante a Livello Globale per IronPeak Manufacturing

Scenario: IronPeak Manufacturing opera in Europa e Nord America e sta consolidando i portali per clienti e partner su Azure. La piattaforma deve garantire una disponibilità del 99,99% per il web tier, mantenere i dati dei clienti UE all’interno dell’Unione Europea, fornire un failover rapido tra le region e assicurare tempi di caricamento delle pagine veloci in tutto il mondo. Il team desidera implementare deployment completamente automatizzati, senza segreti in chiaro nel codice o nei log.

Sfida: Ottenere un’alta disponibilità all’interno della region e un disaster recovery tra region diverse, garantendo la residenza dei dati nell’UE, un’accelerazione globale e il failover per il traffico dinamico, e deployment ripetibili e sicuri tra le varie sottoscrizioni.

Approccio Raccomandato:

1. Selezionare la geography Europa e distribuire il carico di lavoro primario in una region con Availability Zones (ad esempio, West Europe), utilizzando due o più istanze di VM scale set o istanze di App Service distribuite tra le zone.
2. Abilitare il disaster recovery tra region verso la region associata (North Europe) utilizzando la replica nativa dei servizi: usare RA-GZRS per lo Storage e la geo-replica per i database dove disponibile; configurare runbook di failover automatizzati.
3. Posizionare Azure Front Door Standard/Premium di fronte all’applicazione per la terminazione HTTPS globale, il WAF, gli health probe agli edge, il failover basato sulla priorità tra West Europe (primaria) e North Europe (secondaria) e le regole per il routing basato sul percorso (path-based routing).
4. Mettere in cache gli asset statici (immagini, script, download) utilizzando Azure CDN integrato con le stesse origini per ridurre la latenza e scaricare il traffico; convalidare le regole di cache e i valori TTL.
5. Definire management group per le divisioni UE e NA; collocare le sottoscrizioni di produzione e non produzione sotto ciascuno di essi, applicando Azure Policy per la residenza dei dati, il tagging e le location consentite.
6. Implementare template ARM/Bicep archiviati nel controllo del codice sorgente e pubblicati come template spec; parametrizzare region, SKU e scalabilità; fare riferimento ai segreti da Azure Key Vault utilizzando le managed identity per i deployment.
7. Impostare gli SLA e testare la disponibilità composita: due istanze distribuite su zone dietro a Front Door puntano a un obiettivo del 99,99% per l’app tier; convalidare trimestralmente le esercitazioni di failover end-to-end, il DNS, i certificati e le dipendenze di identità.
8. Strumentare la piattaforma con Application Insights e Azure Monitor; configurare gli health probe e gli avvisi di Front Door; ottimizzare le policy di autoscale e di caching in base alla telemetria.

Logica di Azure: Questo design mantiene i dati UE all’interno della geography Europa, fornendo al contempo isolamento dai guasti all’interno della region tramite le Availability Zones e disaster recovery tra region verso la region associata. Azure Front Door offre accelerazione globale e failover basato sullo stato di integrità (health-aware) per il traffico dinamico, mentre Azure CDN scarica i contenuti statici per migliorare le prestazioni. I template ARM/Bicep con riferimenti a Key Vault consentono deployment ripetibili e sicuri tra sottoscrizioni e region. Le topologie scelte si allineano agli SLA pubblicati per raggiungere l’obiettivo del 99,99% per il web tier, e le policy a livello di management group e sottoscrizione impongono la governance con un sovraccarico operativo minimo.

← Concetti di Cloud · Tutti i domini · Calcolo e Servizi App →

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

Sfoglia Microsoft →