Scegliere lo storage: object vs block

La prima decisione riguarda il tipo di storage, non il servizio. Amazon S3 è object storage: durabilità elevatissima, capacità di fatto illimitata, accesso via API/HTTPS. È ideale per static asset, backup, log e data lake, ma non è un filesystem: non lo monti come disco e non offre semantica POSIX. Le storage class (Standard, Standard-IA, Glacier) permettono di bilanciare costo e frequenza di accesso.

Amazon EBS è invece block storage collegato a una singola istanza Amazon EC2 dentro una sola Availability Zone: è il “disco” del server. Il volume di riferimento è gp3, che disaccoppia performance e capacità: parti da una baseline (3000 IOPS e 125 MB/s di throughput) e puoi aumentare IOPS e throughput in modo indipendente dalla dimensione del volume, pagando solo ciò che serve. È la grande differenza rispetto a gp2, dove le performance crescevano automaticamente con la size. Quando servono IOPS molto elevati e latenza sub-millisecondo costante (database transazionali critici) si sale a io2 / io2 Block Express.

Storage condiviso: EFS e FSx

EBS serve una sola istanza; quando più istanze EC2 devono leggere e scrivere sugli stessi file contemporaneamente occorre uno shared storage. Amazon EFS è un filesystem NFS POSIX completamente gestito, elastico, accessibile in parallelo da molte istanze su più AZ: perfetto per web farm, content management e home directory condivise su Linux.

Per esigenze specifiche esiste la famiglia Amazon FSx: FSx for Windows File Server (condivisioni SMB per ambienti Windows/Active Directory), FSx for Lustre (workload HPC ad altissimo throughput), FSx for NetApp ONTAP e FSx for OpenZFS. La regola: EFS per condivisione POSIX/Linux, FSx quando il protocollo o il file system richiesto è specifico.

Scegliere il database

Amazon RDS è il relazionale gestito (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server): AWS gestisce patch, backup e replica. Il deployment Multi-AZ mantiene uno standby sincrono in un’altra AZ per il failover automatico: serve alla disponibilità, non alle performance di lettura.

Amazon Aurora è compatibile MySQL/PostgreSQL con storage distribuito che cresce automaticamente e replica i dati su sei copie in tre AZ. Espone un reader endpoint che distribuisce le letture tra i replica, semplificando lo scaling. Varianti utili: Aurora Serverless v2 per carichi variabili e Aurora Global Database per scenari multi-region con bassa latenza di lettura remota.

Amazon DynamoDB è il NoSQL key-value serverless a latenza costante di pochi millisecondi. La modalità on-demand assorbe traffico imprevedibile senza dover pianificare la capacità (l’alternativa è provisioned con auto scaling). Global Tables offre replica multi-region attiva-attiva.

Scaling in lettura e caching

Il read-scaling si ottiene separando le letture dalle scritture. Su RDS si aggiungono read replica asincrone (fino a più repliche, anche cross-region) e si punta l’applicazione di sola lettura verso di esse. Su Aurora si usa direttamente il reader endpoint. Per abbattere ulteriormente latenza e carico si introduce il caching: Amazon ElastiCache (Redis o Memcached) davanti a RDS/Aurora, e DynamoDB Accelerator (DAX) come cache in-memory specifica per DynamoDB. Il caching riduce le letture ripetute; le read replica scalano il throughput di lettura complessivo.

Trappole tipiche d’esame

  • Più EC2 devono scrivere sugli stessi file (POSIX) → EFS: EBS si collega a una sola istanza e S3 non è un filesystem montabile; lo storage condiviso multi-istanza è EFS.
  • IOPS/throughput da regolare in modo indipendente dalla capacità e a costo ridotto → EBS gp3: gp2 lega le performance alla dimensione; se serve controllo granulare la risposta è gp3, non “aumentare la size”.
  • IOPS altissimi e latenza costante per DB critico → io2 (Block Express): gp3 ha un tetto più basso; per i workload più esigenti si sceglie io2.
  • Solo più capacità di lettura, senza riscrivere l’app → read replica RDS / reader endpoint Aurora: il Multi-AZ standby serve al failover, non alle letture, ed è l’errore classico da evitare.
  • File share SMB per Windows/Active Directory → FSx for Windows File Server: EFS è NFS/Linux, non copre lo scenario SMB.
  • Traffico spiky o imprevedibile senza gestire la capacità → DynamoDB on-demand: evita di dimensionare a mano; on-demand assorbe i picchi automaticamente.