Le 4 tipologie di Storage Account

Azure Storage è un solo servizio con 4 sub-servizi distinti. All’esame ti chiedono quale usare per uno scenario:

Blob Storage — file arbitrari (unstructured)

Cos’è: object storage per file di qualsiasi tipo (immagini, video, backup, log, dati di analytics).

Quando usarlo:

  • Backup di database o file system
  • Immagini/video di un’app web (via CDN)
  • Data lake per analytics (Parquet, JSON)
  • Static website hosting

Tier di prezzo:

  • Hot — accesso frequente (ogni giorno). Costo storage alto, retrieval gratis.
  • Cool — accesso occasionale (settimanale/mensile). Costo storage medio, retrieval $$.
  • Cold — accesso raro (ogni 90+ giorni). Costo storage basso, retrieval $$$.
  • Archive — accesso quasi mai (ogni anno o più). Costo storage minimo (circa 1/50 di Hot), retrieval molto costoso più fino a 15h di attesa per rehydration.

File Storage — SMB/NFS file share

Cos’è: file share condivisi accessibili via SMB (Windows) o NFS (Linux).

Quando usarlo:

  • Migrazione di file server on-premises (lift-and-shift)
  • Cartelle condivise per app multi-instance (es. media library per un cluster App Service)
  • Backup di file system tradizionali

Non usarlo per: file singoli di grosse dimensioni (Blob è più economico). O per uso database (usa Azure SQL o Cosmos).

Queue Storage — messaggi FIFO

Cos’è: coda FIFO di messaggi (max 64KB ciascuno) per comunicazione asincrona tra applicazioni.

Quando usarlo:

  • Disaccoppiamento producer/consumer (web app produce job, worker li consuma)
  • Retry con Dead-Letter Queue
  • Rate limiting di elaborazioni pesanti

Non usarlo per: message di grandi dimensioni (>64KB, usa Service Bus) o messaggi con topic/pub-sub complessi (Service Bus).

Table Storage — key-value NoSQL

Cos’è: database NoSQL schemaless key-value/wide-column. Non transazionale, non SQL.

Quando usarlo:

  • Log di eventi con partition key temporale
  • Dataset schemaless con query per chiave primaria
  • Storage economico per applicazioni semplici

Non usarlo per: applicazioni con query complesse (usa Cosmos DB) o transazioni ACID (usa Azure SQL).

Ridondanza (importante!)

Ogni Storage Account ha una replication strategy che decide dove i dati vengono copiati:

  • LRS (Locally Redundant Storage) — 3 copie nel stesso datacenter. Più economico.
  • ZRS (Zone-Redundant Storage) — 3 copie in 3 availability zones della stessa region.
  • GRS (Geo-Redundant Storage) — LRS in primary region + copia sync in paired region.
  • GZRS (Geo-Zone-Redundant) — ZRS + copia in paired region. Più caro, ma copre tutto.

Domanda tipica: “Devo essere in grado di leggere i dati anche se una region intera fallisce” → RA-GRS o RA-GZRS (Read Access variant).

Trappole tipiche d’esame

  • Blob Archive è economicissimo MA i dati non sono immediatamente accessibili (rehydration fino a 15 ore).
  • File Storage costa più di Blob per gigabyte — usalo solo se serve davvero SMB/NFS.
  • Queue Storage ha limite messaggio 64KB. Per file grandi o strutture complesse, Service Bus.

Cosa hai imparato in questo percorso

Con queste 4 unità hai coperto circa l’80% del syllabus AZ-900:

  • Cloud concepts (CapEx/OpEx, IaaS/PaaS/SaaS, high availability, shared responsibility)
  • Compute (VM, App Service, ACI, AKS, Functions)
  • Storage (Blob/File/Queue/Table, tier, ridondanza)

Il restante 20% (identity con Entra ID, networking, cost management, governance) lo copri con la simulazione esame in cui vedrai domande su tutti i topic. Prossimo step consigliato: fai una simulazione AZ-900 completa per identificare le aree da rinforzare.