In una frase
Una region è un’area geografica (es. West Europe), un’availability zone (AZ) è un datacenter fisicamente indipendente dentro una region.
Region
Un raggruppamento di datacenter collegati tra loro da una rete a bassa latenza. Ogni region ha un nome programmatico, quello che scrivi negli script e nei template (westeurope, eastus2, italynorth), e i servizi Azure vengono deploy-ati “in una region”.
Motivazioni per scegliere una region:
- Latenza al target d’utenza (utenti italiani → Italy North, il datacenter di Milano, oppure West Europe)
- Compliance / data residency (GDPR → dati in EU, HIPAA → US)
- Prezzo (alcune region costano meno di altre per lo stesso SKU)
- Feature availability (non tutti i servizi sono in tutte le region — es. servizi in preview arrivano prima a East US)
Availability Zone
Un datacenter (o gruppo di datacenter contigui) fisicamente separato dalle altre AZ della stessa region:
- Alimentazione elettrica indipendente
- Raffreddamento indipendente
- Connettività di rete indipendente
Se una AZ ha un incendio o un guasto elettrico, le altre AZ della stessa region continuano a operare.
NON tutte le region hanno le AZ. Oggi ce l’ha la maggior parte delle region del cloud pubblico, ma le scoperte non sono poche: sono soprattutto le region più vecchie o ad accesso riservato — West US, Canada East, UK West, South India, Australia Southeast — e lì il multi-zone semplicemente non è un’opzione. La proporzione cambia ogni volta che Microsoft abilita le zone in una region nuova, quindi non impararla a memoria: guarda la colonna «Availability zone support» nell’elenco ufficiale delle region.
Servizi zone-redundant (e ZRS)
Un servizio che automaticamente distribuisce le sue istanze/repliche su multiple AZ della stessa region. Esempi:
- Storage Account con replica ZRS: copie scritte in modo sincrono su tre o più AZ della stessa region
- Azure SQL Database con
Zone Redundant = true - Azure App Service Plan Premium v3 con Zone Redundancy
Attenzione a cosa ti dà davvero, perché la zone redundancy non fa salire automaticamente lo SLA di ogni servizio. Sullo storage Microsoft dichiara per ZRS la stessa disponibilità di LRS — almeno 99,9% in lettura e in scrittura: a cambiare sono la durabilità (da 11 a 12 nove) e il fatto che continui a leggere e scrivere anche con una zona giù. Il 99,99% in lettura lo ottieni solo con RA-GRS o RA-GZRS. Sulle VM la differenza invece c’è: due o più macchine in un availability set, cioè dentro un solo datacenter, valgono 99,95%, e la soglia più alta Microsoft la riconosce alle istanze distribuite su più AZ. Morale: prima di scrivere una percentuale in un documento di progetto, leggila nella SLA del servizio specifico — Azure SQL e App Service hanno la loro, non si deduce per analogia con lo storage.
Quando usare cosa
| Scenario | Configurazione |
|---|---|
| MVP che accetta qualche ora di downtime l’anno | LRS in una single region — almeno 99,9%, cioè fino a circa 8,8 ore l’anno |
| App production che deve sopravvivere alla caduta di un datacenter | ZRS nella region primaria + copia geo-ridondante (GZRS o GRS) — ma solo dove la region ha una pair: a Italy North non c’è |
| Mission-critical con RTO minuti | Active-active multi-region con Front Door + database geo-replication |
| Compliance dati UE | Region in EU (Italy North per tenere i dati in Italia, West Europe, North Europe, France Central, Germany West Central, Spain Central) |
Paired region
Molte region Azure sono accoppiate (paired) a un’altra region della stessa geografia (es. North Europe ↔ West Europe), ma non tutte. Dove la coppia esiste, Microsoft la usa per:
- Rollout ordinato di update platform (mai contemporanei sulla paired)
- Failover automatico di alcuni servizi (Azure Storage GRS scrive sia in primary che in paired)
Dove la coppia esiste non puoi cambiarla — è fissa — e quando pianifichi DR multi-region è la scelta più naturale per la replica.
Ma molte region non hanno nessuna paired region. Microsoft lo scrive esplicitamente: le region più recenti usano le Availability Zone come ridondanza primaria e restano nonpaired. In Europa sono senza coppia Italy North (Milano), Spain Central, Poland Central, Austria East, Belgium Central e Denmark East.
La conseguenza è pratica, non teorica: GZRS richiede che la region abbia sia le AZ sia una pair, quindi su una region nonpaired non è un’opzione. Se tieni i dati a Milano, la ridondanza dentro la region sono le AZ (ZRS), mentre la seconda region te la scegli e te la gestisci tu — Azure Site Recovery, geo-replica del database, backup cross-region. Prima di disegnare l’architettura, controlla nell’elenco ufficiale delle region se quella che hai scelto ha una pair.
Trappole tipiche del test AZ-900
- “Ogni region ha sempre 3 AZ” → FALSO. Esistono region senza nessuna AZ; dove ci sono, la region ne mette a disposizione tre e i servizi zone-redundant come ZRS distribuiscono le repliche su tre o più zone.
- “AZ sono datacenter nella stessa sala server” → FALSO. Sono fisicamente separati (spesso km di distanza).
- “Region paired sono in continenti diversi” → FALSO. Solitamente stessa geografia (eccezione: Brazil South ↔ South Central US).
- “Ogni region ha una paired region” → FALSO. Molte region recenti, Italy North compresa, non ne hanno nessuna e si affidano alle AZ.
- “GRS replica in 3 region” → FALSO. GRS = 2 region (primary + paired).
Approfondimenti Azure infrastructure
Region, Availability Zone e paired region sono concetti chiave nel blueprint AZ-900 (dominio “Azure architecture and services”, 35-40% dell’esame) e tornano in modo più operativo in AZ-104 e AZ-305. Se stai preparando una cert Azure, ecco i percorsi più naturali dopo aver interiorizzato questi fondamentali di infrastruttura.
Per una panoramica strutturata dei servizi core Azure e di come si distribuiscono su region e AZ, vedi la guida ai servizi core di Azure per AZ-900.