In AZ-305 il design dello storage parte sempre dalla stessa domanda: che forma hanno i dati e chi li consuma? Per dati non strutturati e semi-strutturati la scelta si gioca tra tre servizi con profili di costo, protocollo e performance molto diversi. Sbagliare il servizio o la redundancy è uno degli errori più penalizzati nello scenario d’esame.
Scegliere il servizio: Blob, Files o NetApp Files
Azure Blob Storage è la scelta di default per oggetti non strutturati e semi-strutturati: immagini, log, backup, JSON/Parquet di un data lake, media. Con l’account StorageV2 + hierarchical namespace diventa Azure Data Lake Storage Gen2, ideale per analytics (Synapse, Databricks, Microsoft Fabric). Accesso via HTTPS/REST o SDK, non via file share nativo.
Azure Files serve quando l’applicazione richiede un file system condiviso con semantica SMB/NFS e path UNC: lift-and-shift di app legacy, home directory, share aziendali. Due tier di performance: standard (HDD) e premium (SSD, FileStorage account). Supporta Azure File Sync per fare tiering verso il cloud mantenendo cache on-premises.
Azure NetApp Files (ANF) è il servizio bare-metal per workload enterprise ad altissime IOPS e bassa latenza: SAP HANA, HPC, database Oracle, EDA, VDI su larga scala. Costa molto di più ma offre latenza sub-millisecondo e feature NetApp (snapshot istantanei, cross-region replication).
Regola di design: se il requisito è “oggetti + accesso HTTP/analytics” → Blob/ADLS Gen2; se è “SMB/NFS share per app” → Azure Files; se è “latenza estrema o migrazione NetApp/SAP” → ANF. Non proporre ANF per semplici share di file o per storage di oggetti: è overengineering costoso.
Access tier di Blob e lifecycle management
I tier ottimizzano il costo secondo la frequenza d’accesso, bilanciando costo di storage contro costo di transazione/accesso:
- Hot — storage caro, accesso economico. Dati usati di frequente.
- Cool — storage più basso, accesso più caro. Minimo 30 giorni.
- Cold — ancora più economico dello storage; minimo 90 giorni. Utile per dati raramente letti ma ancora online.
- Archive — costo di storage minimo, ma offline: per leggere serve una rehydration (a Hot/Cool) che richiede ore. Minimo 180 giorni.
Il lifecycle management automatizza le transizioni con regole basate su ultima modifica/accesso: es. Hot → Cool dopo 30 giorni, → Archive dopo 90, delete dopo 365. È la leva primaria di cost optimization (pilastro Cost Optimization del Azure Well-Architected Framework) e va sempre proposta quando lo scenario cita “dati che diventano freddi nel tempo”.
Scegliere la redundancy
La redundancy governa durabilità e disaster recovery, con impatto diretto sul costo:
| Opzione | Copie | Protegge da | Note |
|---|---|---|---|
| LRS | 3 in un datacenter | Guasto disco/rack | No resilienza di zona/regione |
| ZRS | 3 su 3 availability zone | Perdita di una zona | HA regionale |
| GRS | LRS primaria + LRS in regione pairata | Disastro regionale | Secondaria non leggibile |
| GZRS | ZRS primaria + LRS secondaria | Zona e regione | Massima resilienza |
| RA-GRS / RA-GZRS | come sopra + endpoint di lettura | Come sopra | Lettura dalla secondaria |
Logica di scelta: HA di zona senza costo cross-region → ZRS; DR cross-region con failover → GRS/GZRS; necessità di leggere la copia secondaria (reporting, offload di lettura) → varianti RA-. Il failover geo è manuale (o pianificato) e comporta perdita dei dati non ancora replicati in modo asincrono (RPO > 0): non equivale a un backup e non protegge da cancellazioni logiche — per quello servono soft delete, versioning e point-in-time restore.
Il trade-off costo / performance / durabilità
Ogni scelta è un bilanciamento tra i pilastri Reliability e Cost Optimization: alzare la redundancy o mantenere tutto in Hot aumenta durabilità/performance ma anche la spesa. La disciplina architetturale è dimensionare al requisito reale, non al caso peggiore immaginato.
Trappole tipiche d’esame
- Dati in Archive letti occasionalmente → NON lasciarli in Archive se serve accesso rapido: la rehydration costa e richiede ore. Se sono letti qualche volta l’anno, valuta Cold (online) invece di Archive.
- Requisito “resilienza a una zona, stessa regione, costo contenuto” → scegli ZRS, non GRS/GZRS: la geo-redundancy è sovradimensionata e più cara senza aggiungere valore.
- Requisito “leggere i dati di backup dalla regione secondaria per reporting” → serve RA-GRS/RA-GZRS; GRS/GZRS semplici non espongono un endpoint di lettura.
- App legacy con path UNC / SMB da migrare → Azure Files (premium se serve bassa latenza), non Blob: Blob non offre semantica di file share nativa.
- “Protezione da cancellazione accidentale” → la redundancy NON basta: attiva soft delete + versioning + point-in-time restore, poiché GRS replica anche le delete.