CLF-C02 · Storage e database

Storage a oggetti, a blocchi e a file

AWS distingue tre modelli di storage e l’esame ti chiede di riconoscere quale usare.

Amazon S3 è object storage: salvi file (“oggetti”) dentro bucket e li raggiungi via API/HTTPS, non come disco di sistema. È pensato per scalabilità praticamente illimitata e durabilità elevatissima (11 nove, 99,999999999%), con dati replicati su più Availability Zone. Casi tipici: backup, data lake, hosting di file statici, log, media. Non è un filesystem montabile né un disco avviabile per un’istanza.

Amazon EBS (Elastic Block Store) è block storage: un volume a blocchi che colleghi a una singola istanza Amazon EC2, come un disco virtuale. Vive dentro una singola Availability Zone e persiste indipendentemente dal ciclo di vita dell’istanza. È la scelta per il disco di boot e per applicazioni che richiedono I/O a bassa latenza su un singolo server.

Amazon EFS (Elastic File System) è file storage: un filesystem NFS condiviso che più istanze EC2 (Linux) possono montare contemporaneamente, con capacità che cresce e si riduce in automatico. È la scelta quando serve accesso condiviso agli stessi file da parte di più server.

Le storage class di Amazon S3

S3 offre più storage class per bilanciare costo e frequenza di accesso, senza cambiare API:

S3 Standard: dati acceduti spesso, latenza bassa.
S3 Intelligent-Tiering: sposta automaticamente gli oggetti fra livelli in base all’uso; ideale quando gli accessi sono imprevedibili.
S3 Standard-IA / One Zone-IA: accesso infrequente; One Zone-IA costa meno ma tiene i dati in una sola AZ.
S3 Glacier (Instant/Flexible Retrieval) e Glacier Deep Archive: archiviazione a lungo termine a costo molto basso, con tempi di recupero crescenti.

Regola pratica: più raramente accedi ai dati, più risparmi sullo storage ma paghi di più (o attendi di più) al recupero.

Database gestiti: RDS, Aurora e DynamoDB

Amazon RDS è il servizio di database relazionale gestito. Supporta motori come MySQL, PostgreSQL, MariaDB, Oracle e SQL Server: dati strutturati in tabelle, query SQL, transazioni ACID. Essendo un managed service, AWS si occupa di patching, backup automatici, high availability con deployment Multi-AZ (failover su una standby) e scalabilità in lettura tramite read replica. Lo usi quando hai uno schema fisso e relazioni fra i dati (gestionali, e-commerce transazionali).

Amazon Aurora fa parte della famiglia RDS: è compatibile con MySQL e PostgreSQL ma progettato da AWS per prestazioni e durabilità superiori. È l’opzione relazionale quando serve più throughput restando sul modello SQL.

Amazon DynamoDB è un database NoSQL key-value e documentale, completamente gestito e serverless: nessun server da amministrare, scalabilità automatica e latenze in single-digit millisecond anche a volumi enormi. È adatto a schema flessibili e carichi molto elevati (cataloghi, sessioni, IoT, gaming).

Abbinare esigenza e servizio

Il criterio di scelta è il cuore delle domande. Chiediti: i dati sono strutturati con relazioni e query SQL? → RDS/Aurora. Servono flessibilità di schema e scala orizzontale enorme con accesso a chiave? → DynamoDB. Devo archiviare file/oggetti? → S3. Serve un disco per una singola istanza? → EBS. Serve un filesystem condiviso fra più istanze? → EFS. In tutti questi casi il valore del managed service è che AWS gestisce l’infrastruttura sottostante, lasciandoti responsabile solo di dati, configurazione e accessi (shared responsibility model). Il passing score dell’esame è 700/1000: allena il ragionamento per associazione, non la memoria.

Trappole tipiche d’esame

Storage condiviso da più EC2 → soluzione: Amazon EFS, non EBS: un volume EBS standard si collega a una sola istanza in una sola AZ.
Schema flessibile e scala massiva a bassa latenza → soluzione: DynamoDB, non RDS: il relazionale è per dati strutturati con relazioni, non per il NoSQL a chiave.
Archiviazione a lungo termine al minor costo → soluzione: S3 Glacier Deep Archive, non S3 Standard: se accedi di rado, l’archiviazione fredda abbatte i costi.
Accessi imprevedibili senza gestire manualmente i tier → soluzione: S3 Intelligent-Tiering, che ottimizza i costi in automatico.
Alta disponibilità del database relazionale → soluzione: RDS Multi-AZ (failover), da non confondere con le read replica, che scalano le letture, non il failover.
“Minimo sforzo operativo / nessun server da gestire” → soluzione: servizio managed o serverless (es. DynamoDB, Aurora Serverless): frasi come “least operational overhead” indirizzano ai servizi gestiti, non a database installati su EC2.