Amazon SAA-C03: Database e Caching — Guida allo studio

By Laurynas Brazys · 17 July 2026 · #amazon #saa-c03 #certification #exam-prep #study-guide

Fa parte della AWS SAA-C03 — Guida di studio completa. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Amazon RDS: Motori Relazionali Gestiti

Amazon RDS fornisce sei motori gestiti — MySQL, PostgreSQL, MariaDB, Oracle, SQL Server e Amazon Aurora (compatibile con MySQL e PostgreSQL) — astraendo l’applicazione di patch, i backup, la topologia di replica e il failover. La scelta del motore determina le licenze, la semantica dei backup e la disponibilità delle funzionalità: Oracle e SQL Server presentano distinzioni tra BYOL e License Included, SQL Server supporta fino a cinque repliche di lettura tramite la replica nativa e le repliche di lettura di Oracle richiedono la Enterprise Edition con Active Data Guard.

Le due funzionalità di RDS più sfruttate per la disponibilità e la scalabilità — e le due più frequentemente confuse — sono le implementazioni Multi-AZ e le repliche di lettura (read replica). Sono ortogonali, complementari e non intercambiabili.

Multi-AZ predispone una replica di standby sincrona in una seconda Zona di Disponibilità. Ogni scrittura viene confermata sia sul primario che sullo standby prima di essere notificata, fornendo un RPO effettivamente pari a zero e un RTO di 60–120 secondi durante il failover automatico. Lo standby non accetta traffico — esiste esclusivamente per il failover. Quando il primario si guasta, una AZ ha problemi o la manutenzione richiede un riavvio, RDS inverte il CNAME DNS verso lo standby e le applicazioni si riconnettono in modo trasparente attraverso lo stesso endpoint. Il Multi-AZ è la soluzione che richiede il minimo sforzo per un single point of failure in una singola AZ: è un’opzione di configurazione, non richiede modifiche allo schema o all’applicazione e preserva l’endpoint. La più recente implementazione cluster Multi-AZ è una topologia a tre nodi (un writer, due standby leggibili) che utilizza una replica semi-sincrona con una latenza di commit di circa un secondo, offrendo HA più un offload di lettura limitato.

Le repliche di lettura utilizzano la replica asincrona nativa del motore (binlog di MySQL, streaming WAL di PostgreSQL). Sono lo strumento corretto per la scalabilità in lettura — query analitiche, dashboard di reporting, SELECT ad-hoc — che altrimenti metterebbero in crisi l’OLTP sul primario. Lo scenario canonico: un database di elaborazione ordini che va in timeout perché i dipendenti eseguono lunghi report di fine mese. Aggiungere una replica di lettura e puntare lo strumento di reporting al suo endpoint isola il carico analitico senza dover aumentare le dimensioni del primario. Le repliche di lettura possono essere cross-region e possono essere promosse manualmente a database autonomi, ma la promozione non è mai automatica e qualsiasi transazione non ancora replicata al momento del guasto viene persa.

Due tranelli si ripresentano in questo ambito. Primo, trattare le repliche di lettura come una soluzione di HA è sbagliato per molteplici motivi: le repliche sono asincrone (potenziale perdita di dati), non hanno promozione automatica, l’endpoint cambia al momento della promozione e le transazioni in corso svaniscono. Se un’architettura promette “zero perdita di dati” e indica una replica di lettura come target di failover, quella promessa è falsa. Secondo, predisporre il Multi-AZ per servire il traffico di lettura è uno spreco di denaro perché lo standby non è leggibile nella topologia standard. Il Multi-AZ risolve la disponibilità; le repliche di lettura risolvono la scalabilità in lettura; spesso si desiderano entrambi.

Le repliche di lettura, inoltre, non fanno nulla per la scalabilità in scrittura — ogni scrittura colpisce ancora il primario e le repliche devono rieseguirla. Per la scalabilità in scrittura, si ricorre allo sharding, si passa ad Aurora (storage disaccoppiato) o si riprogetta verso DynamoDB.

Dimensionamento Corretto delle Repliche di Lettura

Una replica non deve necessariamente corrispondere alla classe di istanza del primario. Il primario gestisce l’intero carico di scrittura più le letture; una replica gestisce solo le letture che la raggiungono. Un primario db.r6i.4xlarge abbinato a una replica db.r6i.large per un processo di reporting notturno è del tutto ragionevole — a condizione che la replica riesca a tenere il passo con l’I/O di replica. La metodologia è: misurare la CPU, la memoria e il ritardo di replica (replica lag) effettivi della replica, quindi dimensionarla in base a quel carico di lavoro. L’unica avvertenza: se si intende promuovere una replica a primario durante un DR, essa deve essere dimensionata per gestire il carico di scrittura. Le repliche sottodimensionate non sono target idonei alla promozione.

Deployment Blue/Green e Storage

I Deployment Blue/Green di RDS creano una copia di staging completa della produzione (green) che rimane sincronizzata tramite replica logica. Si aggiorna la versione del motore, si cambiano i gruppi di parametri o si alterano gli schemi su green, si testa e si effettua lo switch in meno di un minuto con la ridenominazione automatica dell’endpoint. Questo elimina il classico rischio dell’aggiornamento in-place, in cui un aggiornamento di versione major fallito costringe a un ripristino da snapshot.

La selezione dello storage è importante tanto quanto la classe di istanza per carichi OLTP con scritture intensive. La tassonomia gp3/io2:

Il miglioramento di gp3 rispetto a gp2 è il disaccoppiamento degli IOPS dalla dimensione — non è più necessario sovradimensionare la capacità per ottenere prestazioni. Scegliere io2 quando gli IOPS sostenuti superano il limite massimo di gp3 o quando è richiesta una durabilità del 99,999%. Multi-Attach consente a un singolo volume io2 di essere collegato a un massimo di 16 istanze Nitro, ma il filesystem o l’applicazione devono essere consapevoli del cluster (cluster-aware); non è un sostituto della replica. Un tranello che può causare un’interruzione latente: predisporre uno storage a dimensione fissa senza l’autoscaling dello storage abilitato o un allarme CloudWatch su FreeStorageSpace. Quando lo spazio libero arriva a zero, RDS entra nello stato storage-full e rifiuta le scritture.

Amazon Aurora: Architettura ed Endpoint

Aurora reimplementa il livello di storage sottostante a MySQL e PostgreSQL come un volume distribuito, log-structured, replicato sei volte su tre AZ. I nodi di calcolo (compute) sono stateless rispetto allo storage, quindi una Replica Aurora legge dallo stesso volume sottostante dell’istanza di scrittura (writer) invece di riprodurre un log. Il ritardo di replica (replication lag) è tipicamente di 10–20 ms, rispetto ai secondi delle repliche RDS standard, e un cluster supporta fino a 15 repliche che possono essere promosse a istanza di scrittura in circa 30 secondi.

Aurora espone quattro tipi di endpoint:

Gli endpoint personalizzati sono importanti quando le repliche sono eterogenee. Se tre di sei repliche sono db.r6g.8xlarge per il reporting analitico mentre le altre servono letture OLTP, l’endpoint di lettura generico indirizzerà occasionalmente il reporting ai nodi più piccoli, compromettendo la prevedibilità. Un endpoint personalizzato limitato solo alle repliche più grandi offre un isolamento deterministico del carico di lavoro:

aws rds create-db-cluster-endpoint \
  --db-cluster-identifier prod-aurora \
  --db-cluster-endpoint-identifier reporting \
  --endpoint-type READER \
  --static-members reporting-node-1 reporting-node-2 reporting-node-3

Nota che il TTL del DNS degli endpoint di Aurora è di 5 secondi; mettere in cache le stringhe di connessione per un tempo più lungo vanifica il comportamento di failover.

Aurora Auto Scaling aggiunge e rimuove repliche di lettura (reader) in base a metriche target di CPU o di connessioni, che è la risposta canonica per carichi di lavoro imprevedibili e con molte letture (read-heavy) che devono rimanere ad alta disponibilità:

TargetTrackingScalingPolicyConfiguration:
  PredefinedMetricSpecification:
    PredefinedMetricType: RDSReaderAverageCPUUtilization
  TargetValue: 60.0
  ScaleInCooldown: 300
  ScaleOutCooldown: 60

Quando le repliche di lettura di RDS MySQL non riescono a mantenere il ritardo di replica sotto il secondo nei momenti di picco, la risposta low-code è migrare ad Aurora MySQL — le stringhe di connessione cambiano a malapena e la replica a livello di storage elimina il ritardo.

Aurora Serverless v2 e Clonazione

Aurora Serverless v2 scala la capacità di calcolo (compute) verticalmente in Aurora Capacity Unit (ACU, 2 GiB di memoria ciascuna) a grana fine, in circa mezzo secondo, senza disconnettere le sessioni. È adatto a carichi di lavoro variabili con un’impronta di memoria di base nota — per esempio, una migrazione di un database MySQL on-premise che consuma sempre almeno 2 GiB. Imposta il minimo a 1 ACU e il massimo a 32 ACU, e il cluster si adatterà senza bisogno di amministrazione. Aurora Provisioned rimane preferibile quando il carico è stabile e prevedibile, poiché Serverless v2 comporta un costo aggiuntivo per ACU.

La clonazione di Aurora crea un nuovo cluster che condivide le pagine di storage del cluster di origine tramite copy-on-write. I cloni vengono creati in pochi secondi e non hanno costi finché i dati non divergono, rendendoli ideali per ambienti di staging, migrazioni rischiose o per permettere agli analisti di sottoporre a stress una copia della produzione. Il ripristino da uno snapshot reidrata fisicamente i dati e può richiedere ore; la clonazione è la scelta vincente quando la velocità è fondamentale.

Aurora Global Database

Aurora Global Database estende un cluster fino a cinque Regioni secondarie utilizzando un’infrastruttura di replica dedicata a livello di storage — non tramite l’invio di binlog (binlog shipping). Il ritardo di replica tipico è inferiore a un secondo, l’RPO è inferiore a un secondo e il failover gestito promuove una regione secondaria in meno di un minuto.

Due semantiche critiche: le regioni secondarie sono di sola lettura (read-only) durante il normale funzionamento, e Global Database è progettato per il disaster recovery (DR) a basso RPO e per letture remote a bassa latenza, non per configurazioni multi-master active-active. Assumere che un Global Database “gestisca automaticamente le scritture nella regione secondaria” è sbagliato — le scritture in quella regione richiedono un failover gestito esplicito o un’operazione di “detach-and-promote” (scollegamento e promozione). Per un requisito dichiarato di RPO di 5 minuti / RTO di 20 minuti tra regioni con un overhead operativo minimo, Global Database è la risposta canonica.

RDS Proxy e Gestione delle Connessioni

I carichi di lavoro serverless e ad alta concorrenza aggravano un problema classico: le tempeste di connessioni (connection storms). Una funzione Lambda che scala fino a 3.000 esecuzioni concorrenti apre 3.000 socket, superando il limite max_connections e causando fallimenti a cascata — proprio quando il sistema è sotto carico. I pool di connessioni all’interno della funzione non aiutano, perché ogni ambiente di esecuzione concorrente è isolato.

RDS Proxy si interpone tra i client e il database, mantenendo un pool “caldo” di connessioni e multiplando le sessioni dei client su di esse. Risolve due problemi:

1. Tempeste di connessioni. Migliaia di sessioni client vengono multiplate su un piccolo pool di connessioni verso il backend.
2. Tempo di failover. Il proxy mantiene aperte le connessioni dei client mentre ristabilisce il collegamento con il backend, riducendo il tempo di failover percepito fino al 66% ed eliminando la necessità di ristabilire la connessione TCP/TLS e di risolvere nuovamente il DNS da parte del client.

Si integra con IAM e Secrets Manager per la gestione delle credenziali, rimuovendo i segreti hard-coded dal codice dell’applicazione.

DBProxy:
  Type: AWS::RDS::DBProxy
  Properties:
    EngineFamily: POSTGRESQL
    RequireTLS: true
    IdleClientTimeout: 1800
    Auth:
      - AuthScheme: SECRETS
        SecretArn: !Ref DBSecret
        IAMAuth: REQUIRED

Le applicazioni si connettono all’endpoint del proxy, non all’endpoint del cluster. Qualsiasi architettura Lambda-to-RDS o ad alto “fan-out” dovrebbe utilizzare RDS Proxy, a meno che non ci sia una ragione specifica per non farlo. Eseguire un proprio pooler (PgBouncer, ProxySQL) su EC2 è possibile, ma aggiunge l’overhead operativo che il proxy è stato creato per eliminare.

DynamoDB: Modalità di capacità

DynamoDB è un datastore gestito di tipo chiave-valore/documento con una latenza nell’ordine dei millisecondi a una cifra (single-digit) a qualsiasi scala, partizionato orizzontalmente tramite una chiave di hash. Offre due modalità di capacità:

La modalità on-demand è decisamente più semplice ma costa circa 6-7 volte di più per richiesta rispetto alla capacità provisioned ben utilizzata. Per un batch notturno di 4 ore a 500 WCU, la modalità on-demand comporta un costo significativamente superiore: la modalità provisioned con scalabilità pianificata (scheduled scaling) o capacità riservata (reserved capacity) è molto più economica. Al contrario, l’uso della modalità provisioned per un carico di lavoro imprevedibile legato a un lancio pubblico porta al throttling. Per carichi di lavoro costanti con varianza moderata, la modalità provisioned con auto-scaling di tipo target-tracking intorno al 70% di utilizzo è significativamente più economica di quella on-demand, spesso del 50-70%:

TargetTrackingScalingPolicyConfiguration:
  TargetValue: 70.0
  PredefinedMetricSpecification:
    PredefinedMetricType: DynamoDBReadCapacityUtilization
  ScaleInCooldown: 60
  ScaleOutCooldown: 60

È possibile cambiare modalità una volta ogni 24 ore. Presumere che la modalità on-demand sia universalmente più economica è un errore costoso; lo stesso vale per il presumere che la modalità provisioned sia sempre la scelta giusta per il traffico con picchi.

DynamoDB: Consistenza, Streams, Global Tables

Le letture sono per impostazione predefinita a consistenza finale (eventually consistent), il che significa che possono restituire dati non aggiornati entro ~1 secondo, al costo di 0,5 RCU. Impostando ConsistentRead=true si ottiene l’ultimo valore confermato (committed) al doppio del costo. Le letture a consistenza forte (strongly consistent) non sono supportate tramite indici secondari globali o tramite DAX: questi percorsi restituiscono sempre dati a consistenza finale.

DynamoDB Streams cattura le modifiche a livello di item come un log ordinato, conservato per 24 ore, attivando funzioni Lambda per l’elaborazione a valle (downstream), come l’indicizzazione per la ricerca, le notifiche o la denormalizzazione tra tabelle, senza la necessità di polling.

Global Tables si basano su Streams per fornire una replica multi-attiva e multi-regione con risoluzione dei conflitti di tipo “last-writer-wins” (l’ultima scrittura vince). Sono la soluzione giusta quando le letture e le scritture devono essere locali in più regioni. Tuttavia, raddoppiano approssimativamente i costi di storage e di scrittura (ogni scrittura consuma una WCU in ogni regione di replica) e indeboliscono la consistenza tra le regioni. La trappola è abilitare le Global Tables quando una singola regione soddisfa i requisiti di disponibilità: DynamoDB in una singola regione è già replicato su tre AZ con una disponibilità del 99,99%. Una soluzione HA (alta disponibilità) economica in una singola regione consiste in una tabella a regione singola con PITR abilitato e, se desiderato, capacità provisioned con auto-scaling.

Point-in-Time Recovery (PITR) fornisce backup continui con una granularità di ripristino al secondo per gli ultimi 35 giorni, con un overhead trascurabile. Abilitatelo su qualsiasi tabella di produzione: soddisfa i tipici requisiti di RPO di minuti anziché di ore. Per una conservazione più lunga (ad esempio per obblighi normativi), integrate AWS Backup per backup pianificati, gestiti tramite lifecycle e copiabili tra regioni.

TTL permette di specificare un attributo contenente una data di scadenza in formato Unix epoch; DynamoDB elimina in modo asincrono gli elementi scaduti senza alcun costo, ideale per archiviare sessioni, token effimeri o cache di eventi. Le eliminazioni tramite TTL passano attraverso gli Streams per l’archiviazione a valle:

TTLSpecification:
  AttributeName: expireAt
  Enabled: true

Per l’analisi dei dati, l’esportazione su S3 produce uno snapshot point-in-time leggibile da Athena, Redshift Spectrum o EMR senza consumare la capacità della tabella: un pattern molto migliore rispetto alla scansione della tabella.

DAX: DynamoDB Accelerator

DAX è una cache in-memory di tipo write-through, completamente gestita e specifica per DynamoDB, che offre una latenza di lettura nell’ordine dei microsecondi rispetto alla latenza base di DynamoDB, che è nell’ordine dei millisecondi a una cifra. La sua caratteristica distintiva è la compatibilità delle API: il client DAX è un sostituto “drop-in” del client SDK di DynamoDB, quindi le applicazioni lo adottano semplicemente cambiando la configurazione dell’endpoint anziché riscrivere la logica delle query:

import amazondax
dax = amazondax.AmazonDaxClient(
    endpoint_url='dax://cluster.abc.dax-clusters.us-east-1.amazonaws.com')
table = dax.Table('Products')
resp = table.get_item(Key={'sku': '1234'})  # microsecond hit path

DAX mantiene due cache: una cache degli item per i risultati di GetItem/BatchGetItem e una cache delle query per i risultati di Query/Scan. Le scritture sono di tipo write-through: DAX funge da proxy verso DynamoDB e aggiorna la sua cache degli item in caso di successo. La cache delle query, tuttavia, si basa su un TTL, quindi i risultati delle query possono diventare obsoleti anche per gli item appena scritti.

Ci sono due vincoli importanti. Primo, DAX accelera solo le letture a consistenza finale; le letture a consistenza forte bypassano la cache. Secondo, altri processi di scrittura che bypassano DAX causano dati obsoleti (staleness). Per una pagina di dettaglio di un prodotto visitata milioni di volte al giorno, DAX è l’acceleratore con il minor overhead operativo: nessun codice di invalidazione della cache, nessuna gestione separata del cluster. ElastiCache davanti a DynamoDB funzionerebbe, ma richiederebbe una logica di tipo cache-aside che DAX rende superflua.

ElastiCache: Redis e Memcached

ElastiCache offre accesso ai dati in memoria con latenza inferiore al millisecondo come servizio gestito che esegue Redis o Memcached. La scelta del motore dipende dalle funzionalità richieste:

• Memcached — una pura cache chiave/valore multi-thread con sharding orizzontale, senza persistenza, senza replica, senza pub/sub. Da utilizzare solo per il caching effimero, dove la perdita dell’intera cache è accettabile.
• Redis — supporta replica, Multi-AZ con failover automatico, modalità cluster per lo sharding, persistenza, pub/sub, set ordinati, transazioni e crittografia in transito e a riposo. Necessario per qualsiasi caso d’uso che richieda durabilità o tipi di dati complessi.

Dominano due pattern canonici.

Archivio di sessioni centralizzato. Quando un ALB distribuisce il traffico su istanze EC2 o ECS stateless, l’archiviazione locale delle sessioni forza l’uso di sessioni permanenti (sticky session), il che sbilancia il carico e causa problemi durante lo scale-in, i deployment e i guasti delle AZ. Esternalizzare le sessioni su Redis permette a qualsiasi istanza di servire qualsiasi richiesta, e le sessioni sopravvivono ai guasti degli host:

import redis, json
r = redis.Redis(host='sessions.abc123.ng.0001.use1.cache.amazonaws.com',
                port=6379, ssl=True)

def save_session(sid, data, ttl=1800):
    r.setex(f"sess:{sid}", ttl, json.dumps(data))

Offload di lettura per query onerose — classifiche (set ordinati di Redis tramite ZADD/ZREVRANGE), ricerche nel catalogo, aggregazioni. Le strategie di caching devono corrispondere alle esigenze di consistenza:

• Lazy loading (cache-aside): l’applicazione legge dalla cache; in caso di miss (mancato riscontro), legge dal DB e popola la cache con un TTL. Semplice, ma i cold miss (primi accessi mancati) sono penalizzanti e i dati possono diventare obsoleti (stale).
• Write-through: l’applicazione scrive sulla cache e sul DB nella stessa operazione. La cache rimane aggiornata, ma le scritture sono più lente e i dati non utilizzati continuano a occupare memoria.
• Write-back (write-behind): le scritture avvengono prima sulla cache, per poi essere trasferite asincronamente sul DB. Scritture più veloci, ma un guasto della cache comporta la perdita di dati.

data = r.get(f"product:{sku}")
if data is None:
    data = db.query("SELECT * FROM products WHERE sku=%s", sku)
    r.setex(f"product:{sku}", 300, serialize(data))

Affidarsi a un qualsiasi layer di caching senza una strategia di invalidazione — TTL, DEL esplicito all’aggiornamento o write-through — produce letture di dati obsoleti (stale read). La modalità di fallimento è silente: l’applicazione sembra funzionare correttamente finché gli utenti non notano una divergenza. Il caching è anche spesso il modo più economico per scalare le letture oltre ciò che le repliche di lettura (read replica) supportano agevolmente e protegge il primario durante i picchi di traffico.

A differenza di DAX, ElastiCache è agnostico rispetto al motore — la logica di invalidazione è a carico dell’utente — motivo per cui DAX vince in termini di semplicità operativa quando il datastore sottostante è DynamoDB.

Migrazione: DMS e SCT

AWS Database Migration Service (DMS) replica i dati tra motori omogenei (Oracle→Oracle, MySQL→Aurora MySQL) o eterogenei (Oracle→Aurora PostgreSQL, SQL Server→RDS MySQL, on-premise→DynamoDB). Un task DMS ha tre fasi:

1. Caricamento completo (Full load) — copia massiva delle righe esistenti.
2. CDC (Change Data Capture) — segue il log delle transazioni della sorgente e applica le modifiche in corso.
3. Caricamento completo + CDC — il pattern comune per un downtime minimo: la sorgente rimane online, DMS mantiene la destinazione sincronizzata, e il passaggio (cutover) consiste in un breve cambio di DNS.

aws dms create-replication-task \
  --replication-task-identifier ora-to-aurora \
  --source-endpoint-arn $SRC --target-endpoint-arn $TGT \
  --migration-type full-load-and-cdc \
  --table-mappings file://mappings.json \
  --replication-instance-arn $RI

DMS Serverless elimina la necessità di dimensionare e gestire le istanze di replica — la capacità si adatta automaticamente al carico di lavoro, rendendolo adatto per CDC variabili o di lunga durata. I motori di origine devono avere abilitato il supplemental logging (Oracle) o il binary logging in formato ROW (MySQL). Per seeding di dati molto grandi, DMS si integra con Snowball Edge per caricamenti offline.

DMS sposta i dati, non lo schema. Per le migrazioni eterogenee si abbina all’AWS Schema Conversion Tool (SCT), che converte stored procedure, viste, trigger, sequenze e tipi specifici del dialetto — per esempio, da Oracle PL/SQL a PostgreSQL PL/pgSQL, o da T-SQL ad Aurora MySQL. SCT produce un report di valutazione che segnala gli oggetti che richiedono un intervento manuale (tipicamente il 5-20% per codebase complesse). Eseguire solo DMS per una migrazione tra motori diversi è un errore comune: sebbene DMS possa creare tabelle di destinazione rudimentali, non traduce correttamente le procedure o i tipi proprietari. Per le migrazioni omogenee, SCT non è necessario — gli strumenti nativi (mysqldump, pg_dump, RMAN) più il CDC di DMS sono sufficienti.

Il pattern completo per la migrazione tra motori diversi:

1. SCT: convert schema, apply to target RDS/Aurora
2. DMS full-load task: bulk copy existing data
3. DMS CDC task: capture ongoing changes from source
4. Cutover: stop writes at source, wait for CDC lag = 0, redirect app

Backup e Point-in-Time Recovery

I backup automatici di RDS combinano snapshot giornalieri con backup dei log delle transazioni ogni 5 minuti, abilitando il PITR (Point-in-Time Recovery) a qualsiasi secondo all’interno della finestra di conservazione (da 1 a 35 giorni, default 7). Il ripristino crea una nuova istanza — non è possibile ripristinare sulla stessa istanza (in-place) — quindi gli endpoint dell’applicazione o i CNAME devono essere aggiornati. Gli snapshot manuali persistono oltre il periodo di conservazione, sopravvivono alla cancellazione dell’istanza (in base all’impostazione dello snapshot finale), possono essere copiati tra Regioni per il DR (Disaster Recovery) e possono essere condivisi tra account.

Fast Snapshot Restore (FSR) per gli snapshot basati su EBS elimina la penalità del lazy-load (caricamento differito), fornendo ai volumi ripristinati le massime prestazioni immediatamente — utile quando si devono avviare più ambienti da un unico snapshot in tempi stretti. Il cloning di Aurora bypassa completamente gli snapshot per le copie all’interno della stessa regione. Il PITR di DynamoDB è una funzionalità parallela che deve essere abilitata per ogni tabella e produce una nuova tabella al momento del ripristino.

Database Purpose-Built

Selezionare un motore purpose-built (creato per uno scopo specifico) quando i pattern di accesso lo richiedono previene costose riprogettazioni dell’architettura. Amazon Neptune è un database a grafo gestito che supporta Gremlin, openCypher e SPARQL — appropriato quando le query attraversano relazioni (reti fraudolente, grafi sociali, grafi di conoscenza) dove join ricorsivi in un motore relazionale sarebbero proibitivamente costosi. Amazon QLDB è un ledger immutabile e crittograficamente verificabile con un journal di tipo append-only (solo aggiunta), adatto a sistemi di registrazione (system of record) che richiedono un audit a prova di manomissione — tracciabilità della catena di approvvigionamento, transazioni finanziarie, registri della motorizzazione. DynamoDB è la scelta di default per l’accesso chiave-valore o a documenti con latenza di pochi millisecondi (single-digit) a qualsiasi scala, utilizzando pattern come il single-table design, chiavi di ordinamento composite per l’accesso gerarchico e GSI (Global Secondary Indexes) per percorsi di accesso alternativi. Forzare questi carichi di lavoro su RDS crea contesa sui lock (scritture del ledger), complessità delle query (attraversamento di grafi) o limiti di scalabilità (accesso chiave-valore ad alto throughput) — ciascuno dei quali è molto più costoso da rimediare in seguito rispetto a una scelta corretta in fase di progettazione.

Riepilogo delle trappole

• Read replica come soluzione di HA. Repliche asincrone, nessuna promozione automatica, l’endpoint cambia alla promozione, le transazioni in corso vengono perse. Multi-AZ è la risposta per l’HA.
• Multi-AZ per la scalabilità in lettura. L’istanza di standby non è leggibile in una configurazione RDS Multi-AZ standard. Utilizzare le read replica o le repliche Aurora.
• Produzione in Single-AZ. Nessun target di failover; si perde la disponibilità in caso di evento a livello di AZ o di riavvio dell’istanza. Il Multi-AZ costa circa il doppio, ma offre un salto qualitativo in termini di disponibilità.
• Replica dimensionata di default come l’istanza primaria. Le repliche spesso richiedono molte meno risorse; dimensionarle in base al carico di lavoro misurato, a meno che la replica non sia un target di promozione.
• DynamoDB on-demand è sempre più economico. Il costo per richiesta è circa 6-7 volte superiore; la modalità provisioned + auto-scaling è vincente per carichi di lavoro stabili.
• Global Tables per esigenze single-region. Raddoppia i costi e indebolisce la consistenza senza alcun beneficio, a meno che non siano richieste la prossimità all’utente multi-region o finalità di DR.
• Le istanze secondarie di un Aurora Global Database servono le scritture. Sono in sola lettura finché un failover gestito non le promuove.
• Lambda → RDS senza RDS Proxy. Una tempesta di connessioni esaurisce max_connections; i pool di connessioni all’interno della funzione non aiutano tra ambienti di esecuzione concorrenti.
• DMS da solo per una migrazione eterogenea. Sposta i dati, non lo schema. Abbinarlo a SCT.
• Storage RDS fisso senza autoscaling o allarmi su FreeStorageSpace. Interruzione latente: lo stato storage-full rifiuta le scritture.
• Caching senza una strategia di invalidazione. Dati obsoleti in modo silente (silent staleness). TTL, write-through o invalidazione esplicita non sono negoziabili.
• Letture strongly consistent tramite DAX o GSI. Entrambi i percorsi servono solo dati eventually consistent.

← Distribuzione dei Contenuti · Tutti i domini · Analytics →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →

Sfoglia Amazon →