Microsoft AZ-305: Well-Architected Framework e principi di progettazione — Guida allo studio

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

Panoramica

L’Azure Well-Architected Framework (WAF) è un insieme di principi prescrittivi che guidano la progettazione, la creazione e la gestione di carichi di lavoro affidabili, sicuri, efficienti in termini di costi, eccellenti dal punto di vista operativo e performanti su Azure. Allineare le soluzioni ai cinque pilastri — affidabilità, sicurezza, ottimizzazione dei costi, eccellenza operativa ed efficienza delle prestazioni — garantisce che le decisioni architetturali siano il risultato di compromessi espliciti, basati sulle priorità di business, sulla tolleranza al rischio e su vincoli come la sovranità dei dati e il budget. Per ottenere coerenza su larga scala sono necessarie landing zone, una governance basata su policy e l’automazione come approccio predefinito. Le architetture moderne enfatizzano il disaccoppiamento, la comunicazione basata su eventi e pattern come CQRS, Strangler Fig e microservizi, implementati con servizi nativi di Azure e osservabilità integrata, per adattarsi sia a cambiamenti rapidi sia a una conformità rigorosa.

I cinque pilastri: Affidabilità, Sicurezza, Costi, Eccellenza Operativa, Prestazioni

L’affidabilità garantisce che i carichi di lavoro continuino a rispettare gli SLA di business in caso di guasto e durante le modifiche. Progettare per domini di errore (fault domain) e domini di aggiornamento (update domain) distribuendo tra Zone di Disponibilità (Availability Zone) o coppie di region, scegliendo servizi gestiti con alta disponibilità (HA) integrata e implementando pattern di resilienza. Testare la recuperabilità con il chaos engineering e le esercitazioni di disaster recovery. Per i dati stateful, scegliere servizi con funzionalità di RPO/RTO, ad esempio Azure SQL Database Active Geo-Replication o le scritture multi-region di Cosmos DB, abbinati a backup automatizzati e runbook testati.

La sicurezza è una difesa a più livelli (defense in depth), ancorata al principio Zero Trust. Applicare il principio del privilegio minimo (least privilege) con Azure RBAC, Privileged Identity Management (PIM) e le access review per una gestione continua dei diritti di accesso. Isolare il raggio d’impatto (blast radius) della rete utilizzando endpoint privati, NSG e Azure Firewall; integrare un Web Application Firewall (WAF) su Azure Front Door o Application Gateway. Partire dal presupposto di una violazione (Assume breach) con monitoraggio continuo tramite Defender for Cloud, rilevamento delle minacce in Sentinel e una rigorosa protezione delle identità (MFA, Conditional Access).

L’ottimizzazione dei costi bilancia il valore di business e il costo totale di proprietà (TCO). Dimensionare correttamente (right-sizing) le risorse di calcolo e i livelli di servizio in base alla telemetria; utilizzare il dimensionamento automatico (scaling) per adattarsi alla domanda e spegnere gli ambienti non di produzione. Impegnarsi con reservation e savings plan per carichi di lavoro stabili, sfruttare le Spot VM per carichi di lavoro interrompibili, organizzare lo storage e la conservazione dei dati su più livelli (tiering) e preferire il serverless dove si allinea ai profili del carico di lavoro. Imporre l’uso di tag e budget, e utilizzare Azure Policy per standardizzare i controlli dei costi.

L’eccellenza operativa enfatizza l’automazione, la ripetibilità e i cicli di apprendimento. Trattare gli ambienti come codice (Infrastructure as Code) con Bicep/ARM o Terraform, imporre la correzione delle deviazioni (drift remediation) e implementare pipeline di CI/CD coerenti. Gli insight operativi derivano da log strutturati, metriche, tracce e test sintetici, tutti collegati a sistemi di alerting e dashboard SLO, per ridurre il tempo medio di ripristino (MTTR) e guidare miglioramenti proattivi.

L’efficienza delle prestazioni garantisce che il carico di lavoro soddisfi gli obiettivi di throughput e latenza sotto carichi variabili. Progettare per la scalabilità orizzontale (scale-out), utilizzare la cache in modo aggressivo, distribuire i contenuti ai margini della rete (edge) e scegliere partizioni dei dati e repliche di lettura adatte ai pattern di accesso. Validare con test di carico realistici e ottimizzare sulla base dei risultati.

Pattern di Affidabilità e Prestazioni in Azure

I pattern di resilienza riducono la probabilità e l’impatto dei guasti, mantenendo al contempo una latenza prevedibile.

• Retry con backoff esponenziale e jitter: Utilizzare le policy di retry configurabili degli SDK di Azure o librerie come Polly (.NET) per gestire errori transitori da servizi come Storage, Service Bus o Cosmos DB. Il backoff con jitter evita il problema del “thundering herd” (folla scatenata); limitare il numero di tentativi per proteggere gli SLA e far emergere i guasti in tempo utile.

• Circuit breaker: Includere le chiamate in uscita (ad esempio, verso API esterne) in un circuit breaker per fallire rapidamente (fail fast) quando il tasso di errore supera le soglie, consentendo periodi di ripristino. Implementare a livello client con Polly o a livello di gateway utilizzando le policy di API Management (retry, timeout e cache) per evitare fallimenti a cascata.

• Bulkhead: Partizionare le risorse in modo che un “vicino rumoroso” (noisy neighbor) non esaurisca le risorse del sistema. Isolare pool di thread, repliche di container e partizioni di elaborazione dei messaggi. A livello di piattaforma, utilizzare App Service plan, node pool di AKS o code/topic di Service Bus separati per ogni bounded context per contenere i guasti.

• Monitoraggio degli endpoint di integrità (health endpoint): Esporre probe di liveness e readiness nei servizi. Gli health probe di Application Gateway/Front Door instradano il traffico solo verso le istanze integre. In AKS, i probe di Kubernetes gestiscono i riavvii dei pod e il controllo dei rollout. Combinare con i test di disponibilità di Application Insights e endpoint personalizzati “/healthz” per rilevare precocemente il degrado delle dipendenze.

I pattern di prestazione completano la resilienza:

• Strategie di caching: Utilizzare Azure Cache for Redis per dati ad accesso frequente (hot data) e per l’offload delle sessioni. Applicare l’output caching a livello di Azure Front Door o API Management per le richieste GET idempotenti. Preferire i pattern write-through o write-behind dove appropriato; invalidare per chiave o tramite evento per mantenere l’aggiornamento dei dati. A livello dati, la cache integrata di Cosmos DB riduce il consumo di RU per i carichi di lavoro con molte letture (read-heavy).

• CDN: Avvicinare gli asset statici e i contenuti dinamici agli utenti con Azure Front Door o Azure CDN, abilitando compressione, TLS e WAF. Configurare caching basato su regole, controlli di integrità dell’origine (origin health check) e geo-filtering per ottimizzare latenza e costi.

• Repliche di lettura (read replicas): Scalare i carichi di lavoro read-heavy con le repliche secondarie leggibili di Azure SQL Database (Active Geo-Replication) o le repliche con nome di Hyperscale; utilizzare le repliche di lettura di Azure Database for PostgreSQL/MySQL per analytics o reporting; abilitare le letture multi-region in Cosmos DB con un modello di coerenza (es. Session, Consistent Prefix) allineato alle esigenze di business.

• Pattern di autoscaling: Implementare la scalabilità orizzontale con Virtual Machine Scale Sets, le regole di autoscale di App Service, HPA/KEDA in AKS per la scalabilità basata su eventi e i piani Consumption/Premium di Functions. Per i dati, utilizzare l’autoscale di RU/s di Cosmos DB e l’auto-inflate di Event Hubs per gestire picchi di traffico (bursty traffic). Validare sempre le soglie di scalabilità e i periodi di cool-down per evitare oscillazioni.

Principi di progettazione per eccellenza operativa, ottimizzazione dei costi e sicurezza

Infrastruttura come codice: Standardizzare su moduli Bicep/ARM o Terraform, versionati in Git e convalidati con test di pre-distribuzione e policy-as-code. Utilizzare specifiche di template o registri Terraform per il riutilizzo. Parametrizzare per ogni ambiente e imporre l’uso di tag coerenti, blocchi delle risorse e impostazioni di diagnostica. Integrare con Azure DevOps o GitHub Actions; utilizzare distribuzioni a fasi e approvazioni per una promozione controllata.

Automazione delle distribuzioni: Privilegiare gli slot di distribuzione e le strategie blue-green e canary supportate da App Service, AKS (rollout progressivi con le strategie di Deployment) e Traffic Manager/Front Door per il routing ponderato. Automatizzare le modifiche allo schema del database con pipeline di migrazione e contratti retrocompatibili. Controllare i rollout utilizzando health probe e KPI di business.

Osservabilità: Strumentare le applicazioni con OpenTelemetry, esportare i dati in Application Insights per il tracciamento distribuito, le metriche e le mappe delle dipendenze. Abilitare Azure Monitor per le metriche della piattaforma, distribuire aree di lavoro Log Analytics e creare Workbook e dashboard per SLO e capacità. Definire regole di avviso con soglie dinamiche, integrare con sistemi ITSM e archiviare centralmente i log di attività e i log di diagnostica per audit e analisi forense.

Dimensionamento corretto e controlli dei costi: Utilizzare Azure Advisor, le metriche di utilizzo di Azure Monitor e il profiling di Application Insights per identificare gli sprechi (core inattivi, vCore sovradimensionati, RU/s sovra-allocate). Applicare Reservations/Savings Plans ai carichi di lavoro stabili (VM, SQL, Synapse), capacità riservata per lo Storage e livelli di impegno per Cosmos DB. Scegliere le Spot VM per agenti di compilazione, elaborazioni batch e training di ML con checkpointing. Bilanciare i compromessi architetturali: i servizi PaaS gestiti possono ridurre i costi operativi e migliorare l’affidabilità a fronte di costi unitari più elevati; il caching riduce i costi di data egress e di RU a scapito della complessità di invalidazione della cache; l’alta disponibilità multi-regionale aumenta la spesa ma può essere richiesta da RTO/RPO.

Principi di sicurezza in pratica:

• Difesa in profondità: Stratificare i controlli, dall’identità ai dati. Utilizzare Private Link per mantenere il traffico al di fuori della rete Internet pubblica, NSG e ASG per la microsegmentazione, Azure Firewall Premium per l’ispezione TLS e un WAF perimetrale (at the edge). Abilitare le raccomandazioni di Defender for Cloud e l’accesso just-in-time alle VM.
• Minimo privilegio: Implementare un controllo degli accessi basato sui ruoli (RBAC) granulare, con ambito a livello di gruppo di gestione/sottoscrizione/gruppo di risorse; preferire le identità gestite rispetto ai segreti; governare su larga scala con Azure Policy e le revisioni di accesso per gruppi, applicazioni aziendali e ruoli con privilegi elevati.
• Presupporre la violazione (Assume breach): Richiedere l’MFA e l’accesso condizionale (Conditional Access), monitorare con Sentinel e isolare i carichi di lavoro con landing zone e sottoscrizioni separate. Crittografare i dati a riposo (at rest) con chiavi gestite dalla piattaforma o CMK in Key Vault; utilizzare la doppia crittografia dove richiesto dalle normative. Utilizzare le SAS per l’accesso allo storage limitato nel tempo e ruotare le chiavi tramite policy.
• Classificazione dei dati: Catalogare i dati con Microsoft Purview, etichettarne la sensibilità e applicare policy DLP. Allineare la crittografia, la conservazione e l’accesso ai livelli di classificazione dei dati; registrare l’accesso ai dati PII (Personally Identifiable Information) e supportare i requisiti di privacy con funzionalità come Dynamic Data Masking e Always Encrypted, ove applicabile.

Azure Landing Zone e Pattern di Architettura Moderna

Le Azure Landing Zone rendono operativo il framework su larga scala. Organizzare una gerarchia di gruppi di gestione (radice → piattaforma → business unit) per definire l’ambito di Azure Policy, RBAC e dei budget. Le landing zone di piattaforma forniscono servizi condivisi: identità (Azure AD), connettività (hub con Azure Firewall, DDoS, DNS), gestione (Log Analytics, Automation, Update Management) e sicurezza (Defender for Cloud). Le landing zone applicative ospitano i carichi di lavoro, segmentati per ambiente e confini di conformità, con policy ereditate che impongono l’uso di tag, la diagnostica e i tipi di risorse consentiti. Adottare il design Enterprise-Scale del Cloud Adoption Framework (CAF) o gli acceleratori di landing zone basati su Terraform/Bicep per un bootstrap rapido e coerente.

I microservizi su Azure enfatizzano team disaccoppiati e servizi distribuibili in modo indipendente:

• Individuazione dei servizi (Service discovery): In AKS, usare Kubernetes DNS/CoreDNS per la risoluzione intra-cluster; potenziarla con i sidecar Dapr per l’individuazione basata su nome e i tentativi (retry). Service Fabric fornisce gestione integrata dei nomi e dello stato di integrità (health) per i servizi stateful.
• Pattern API gateway: Usare Azure API Management per centralizzare routing, versioning, autenticazione (validazione OAuth 2.0/JWT), quote e caching. Posizionare Azure Front Door davanti per l’anycast globale, l’offload SSL e il WAF; instradare per regione ed eseguire canary release in sicurezza.
• Comunicazione basata su eventi (Event-driven): Usare Azure Service Bus per comandi transazionali e ordinati con sessioni; scegliere Event Hubs per telemetria ad alta velocità (high-throughput); e Event Grid per sottoscrizioni a eventi reattive in stile push. Progettare per una consegna “at-least-once”, gestori idempotenti, gestione dei messaggi non elaborabili (poison message) e DLQ (Dead-Letter Queue).

CQRS e Event Sourcing separano i modelli di scrittura e lettura per isolare le prestazioni e la complessità. Persistere eventi di tipo “append-only” in un event store (Cosmos DB, Azure SQL, o Event Hubs con compattazione tramite storage a valle), rieseguirli (replay) per ricostruire lo stato e proiettarli in modelli di lettura ottimizzati per le query come Azure SQL Database, container di Cosmos DB o Azure Cognitive Search. Il change feed di Cosmos DB è il fulcro per le proiezioni: Azure Functions o Azure Stream Analytics possono elaborare le modifiche per aggiornare i read store quasi in tempo reale. Event Hubs funge da buffer per flussi di eventi ad alto volume, con i consumer che scalano in modo indipendente. Adottare la coerenza finale (eventual consistency) con SLA chiari e pattern di esperienza utente (es. conferma del comando seguita dalla convergenza del modello di lettura).

Il pattern Strangler Fig consente una modernizzazione incrementale. Posizionare Azure API Management di fronte al monolite per instradare endpoint specifici verso nuovi microservizi, mentre il resto continua a essere gestito dal backend legacy. Utilizzare le policy per il routing basato su header, la trasformazione delle risposte e l’autenticazione. Sincronizzare i dati con il change data capture (es. Azure Data Factory o Database CDC verso Event Hubs) e costruire nuovi modelli di lettura con Cosmos DB + change feed, ritirando gradualmente le funzionalità del monolite. Gestire il rischio con feature flag, routing canary su Front Door e un’osservabilità completa per confrontare il comportamento.

Scenario Pratico

Starbucks sta modernizzando la sua piattaforma di ordini globale, attualmente un monolite ospitato su VM in una singola regione. Deve migliorare l’affidabilità tra le regioni, ridurre la latenza per i client mobili, applicare il principio del privilegio minimo (least privilege) e Zero Trust, e migrare in modo incrementale senza interrompere l’operatività.

1. Stabilire le landing zone aziendali

• Creare una gerarchia di gruppi di gestione con landing zone di piattaforma e applicative. Applicare Azure Policy per l’uso di tag, la diagnostica, gli SKU consentiti e i private endpoint. Scegliere il riferimento CAF Enterprise-Scale per l’identità, la connettività (hub con Azure Firewall Premium, Private DNS) e la gestione (Log Analytics centralizzato). Perché: Le landing zone impongono baseline coerenti di sicurezza, networking e governance, in modo che i carichi di lavoro ereditino i controlli by design.

2. Posizionare un facade di edge e API di fronte al monolite

• Distribuire Azure Front Door (Standard/Premium) con WAF per fornire un punto di ingresso anycast globale, terminazione TLS e protezione DDoS. Posizionare Azure API Management come API gateway, integrato con Front Door, per autenticare i client (OAuth 2.0), applicare limiti di velocità (rate limit) per gruppo di consumer e trasformare richieste/risposte. Perché: Front Door riduce la latenza e protegge a livello di edge; API Management implementa il pattern API gateway, abilitando l’approccio Strangler Fig e il throttling specifico per tenant.

3. Implementare la migrazione Strangler Fig

• Utilizzare le policy di API Management per instradare endpoint selezionati (es. menu, localizzatore di negozi) verso nuovi microservizi in esecuzione su AKS in due regioni; tutte le altre rotte vanno al monolite legacy dietro un internal load balancer. Perché: Il routing incrementale evita migrazioni “big-bang” e consente ai team di migrare le funzionalità in modo indipendente.

4. Costruire microservizi con pattern resilienti e performanti

• In AKS, abilitare HPA con KEDA per l’autoscaling basato su eventi. Usare Dapr per la service discovery, i tentativi (retry) con backoff esponenziale e il circuit breaking tra i servizi. Integrare Azure Cache for Redis per le letture “calde” (hot reads) e l’offload delle sessioni. Perché: AKS e Dapr forniscono resilienza e service discovery agnostiche rispetto alla piattaforma; il caching riduce la latenza di lettura e il carico sul backend.

5. Adottare la comunicazione basata su eventi e CQRS

• Pubblicare eventi di dominio su Azure Event Hubs; persistere gli ordini in Cosmos DB con partizionamento per cliente o negozio. Utilizzare il change feed di Cosmos DB con Azure Functions per proiettare i dati su modelli di lettura in Azure SQL Database (reporting) e Azure Cognitive Search (ricerca inventario negozi). Perché: Event Hubs disaccoppia producer e consumer ad alta velocità; il change feed abilita viste materializzate quasi in tempo reale per CQRS senza impattare le prestazioni di scrittura.

6. Rafforzare la sicurezza e l’identità

• Imporre l’uso di private endpoint per i servizi dati, NSG/ASG per la segmentazione e Azure Firewall per il controllo del traffico in uscita (egress). Utilizzare managed identity per tutti i carichi di lavoro, PIM per i ruoli privilegiati e access review per le sottoscrizioni ai prodotti di API Management. Abilitare l’Accesso Condizionale (Conditional Access) e l’MFA per il personale operativo. Perché: La difesa in profondità (defense in depth) e il principio del privilegio minimo riducono il raggio d’impatto (blast radius) e il rischio legato alle credenziali; le access review mantengono l’igiene dei diritti di accesso (entitlement).

7. Progettare per l’affidabilità e l’osservabilità

• Distribuire su più Zone di Disponibilità (Availability Zone) in ogni regione, con routing active-active su Front Door e API Management multi-region. Abilitare il monitoraggio degli endpoint di integrità (health) con Front Door e le probe di AKS; configurare canary release per i nuovi servizi. Strumentare con OpenTelemetry verso Application Insights, centralizzare i log in Log Analytics e creare dashboard di SLO con alert. Implementare backup/DR per gli store stateful ed eseguire esperimenti di chaos engineering. Perché: La ridondanza zonale e regionale, il routing basato sullo stato di integrità e un’osservabilità completa mantengono gli SLA e consentono una risposta rapida agli incidenti.

8. Ottimizzare i costi continuamente

• Dimensionare correttamente (right-sizing) i node pool di AKS e i piani di App Service in base alla telemetria; applicare Reservations/Savings Plan per il calcolo costante; usare Spot VM per i batch non critici. Abilitare l’autoscaling di Cosmos DB e valutare i livelli di impegno (commitment tier). Imporre budget/tag e rivedere mensilmente le raccomandazioni di Azure Advisor. Perché: Una governance sistematica dei costi preserva le prestazioni minimizzando gli sprechi e i costi unitari.

← Migrazione e modernizzazione · Tutti i domini

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

Sfoglia Microsoft →