Scelta del database relazionale: RDS, Aurora e Aurora Global Database

Il primo criterio architetturale è distinguere workload relazionali da workload NoSQL. Per schemi relazionali con transazioni ACID, join complessi o compatibilità con motori esistenti (PostgreSQL, MySQL, Oracle, SQL Server) si parte da Amazon RDS: la HA si ottiene con deployment Multi-AZ (standby sincrono nella stessa region, failover automatico) e la scalabilità in lettura con read replica. Quando servono throughput superiore, storage auto-scaling fino a decine di TB e failover più rapido, la scelta è Amazon Aurora, con endpoint separati per writer e reader.

Per scenari multi-region entra in gioco Aurora Global Database: esiste un solo writer region (primary) e fino a più region secondarie in sola lettura, con replica cross-region tipicamente sotto il secondo. È la risposta corretta quando i requisiti sono bassa latenza di lettura globale e DR con RPO nell’ordine del secondo e RTO di pochi minuti tramite managed failover o promotion di una region secondaria. Non consente scritture attive in più region contemporaneamente: se il requisito è la scrittura globale, Aurora non è la soluzione.

DynamoDB, global tables e caching con DAX

Per workload key-value o document a scala massiva, con pattern di accesso noti e latenza a singola cifra di millisecondi, la scelta è Amazon DynamoDB, serverless e con capacità on-demand o provisioned. La multi-region active-active si ottiene con le global tables: scritture accettate in ogni region con risoluzione dei conflitti last-writer-wins e consistenza eventuale fra region. È l’opzione giusta quando servono utenti che scrivono da continenti diversi con failover regionale trasparente.

Il caching di DynamoDB ad altissime prestazioni si fa con DAX (DynamoDB Accelerator), cache in-memory write-through che porta le letture a livello di microsecondi ed è esclusiva di DynamoDB. Attenzione: DAX accelera le letture eventually consistent; le letture strongly consistent bypassano la cache. Per cache davanti a database relazionali o per store di sessione, DAX non è applicabile: si usa ElastiCache.

Data lake su S3: Lake Formation, Glue e Athena

Il data lake enterprise poggia su Amazon S3 come storage durevole e a basso costo, con lifecycle policy verso classi economiche. Il catalogo e l’ETL serverless sono gestiti da AWS Glue (crawler che popolano il Glue Data Catalog e job di trasformazione), mentre AWS Lake Formation aggiunge la governance centralizzata: permessi fine-grained a livello di database, tabella, colonna, riga e cella, più data filter e tag-based access control, superando i limiti delle sole IAM/bucket policy.

L’interrogazione ad-hoc avviene con Amazon Athena, motore SQL serverless che legge direttamente da S3 con pricing per dato scansionato. Per contenere costi e latenza si usano partizionamento, formati colonnari (Parquet/ORC) e compressione. Athena si integra con i permessi di Lake Formation, così le stesse regole di accesso valgono per chi esegue query.

Streaming e caching operativo: Kinesis ed ElastiCache

Per l’ingestion in tempo reale la famiglia Amazon Kinesis offre due opzioni chiave: Kinesis Data Streams per streaming real-time con consumer custom e controllo su shard e ordinamento; Kinesis Data Firehose per la consegna near-real-time e senza codice verso S3, Redshift o OpenSearch, con buffering e trasformazione opzionale. Per il caching applicativo generico davanti a RDS/Aurora, per session store, leaderboard e rate limiting si usa Amazon ElastiCache (Redis o Memcached), con strategie lazy loading o write-through e TTL.

Trappole tipiche d’esame

  • Scrittura attiva multi-region → DynamoDB global tables: Aurora Global Database ha un solo writer region; per active-active in scrittura la risposta è DynamoDB, non Aurora.
  • DR cross-region con RPO circa 1s per database relazionale → Aurora Global Database: la replica sub-secondo batte la cross-region read replica di RDS, che ha lag maggiore.
  • Letture DynamoDB a microsecondi → DAX, non ElastiCache: DAX è la cache nativa di DynamoDB; ElastiCache richiederebbe logica applicativa e non integra le API DynamoDB.
  • Permessi per colonna/riga sul data lake → Lake Formation: le sole IAM e bucket policy di S3 non offrono fine-grained access a livello di colonna o riga.
  • Consegna serverless su S3 senza codice → Kinesis Data Firehose: Data Streams richiede consumer applicativi; per il semplice delivery buffered si usa Firehose.
  • Ridurre i costi di Athena → partizioni + formato colonnare: Parquet/ORC e compressione riducono i dati scansionati, non il numero di query.