Amazon CLF-C02: Servizi di database principali — Guida allo studio

By Laurynas Brazys · 29 July 2026 · #amazon #clf-c02 #certification #exam-prep #study-guide

Fa parte della AWS Cloud Practitioner CLF-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Database relazionali gestiti: Amazon RDS e Amazon Aurora

Amazon RDS fornisce motori relazionali completamente gestiti (MySQL, PostgreSQL, MariaDB, SQL Server, Oracle) con backup automatici, Multi-AZ per l’alta disponibilità, read replica per la scalabilità e ripristino basato su snapshot. Aurora è un motore purpose-built, compatibile con MySQL e PostgreSQL, che separa il calcolo da un livello di storage distribuito e fault-tolerant per offrire un throughput più elevato, un ripristino rapido dai crash e funzionalità come il backtrack e il Global Database per la replica cross-region. I modelli di prezzo includono istanze On-Demand per una capacità flessibile, Reserved Instances o Savings Plans per risparmi prevedibili e modelli di capacità serverless o di autoscaling per Aurora Serverless per allineare i costi ai carichi di lavoro variabili. Le decisioni architetturali chiave dipendono dal profilo di lettura/scrittura, dai requisiti di latenza e dalla tolleranza operativa: scegli RDS quando le esigenze di compatibilità e licenza sono predominanti, e Aurora quando hai bisogno di prestazioni più elevate, autoscaling dello storage o letture globali. Le trappole comuni per gli operatori sono il sotto-provisioning degli IOPS per carichi di lavoro con molte scritture, dimenticare di abilitare il Multi-AZ per la produzione, mantenere le credenziali master predefinite e non testare il ripristino point-in-time. Per la conformità, abilita la crittografia at-rest usando AWS KMS, imponi TLS per la crittografia in-transit e verifica che i backup automatici e gli snapshot soddisfino gli obiettivi di retention e di DR cross-region.

Database NoSQL, di caching e a grafo: DynamoDB, ElastiCache, Amazon Neptune

Per carichi di lavoro chiave-valore e a documenti su larghissima scala, Amazon DynamoDB offre una latenza nell’ordine dei millisecondi a una cifra, partizionamento automatico e due modalità di capacità: provisioned (con autoscaling) e on-demand per traffico imprevedibile. Funzionalità come DynamoDB Streams, global tables e point-in-time recovery (PITR) supportano la replica, il change data capture e i backup. Una trappola comune è una progettazione scadente della chiave di partizione che crea partizioni “hot” e throttling; modella prima i pattern di accesso ai dati. Per carichi di lavoro in-memory a bassa latenza usa ElastiCache: Redis offre persistenza, clustering e pub/sub, mentre Memcached è un sistema di caching semplice e multi-threaded. Usa DAX per carichi di lavoro DynamoDB con molte letture che richiedono un caching nell’ordine dei microsecondi. Per query a grafo incentrate sulle relazioni, Amazon Neptune è un database a grafo completamente gestito che supporta Gremlin e SPARQL. Decisioni sul prezzo: DynamoDB on-demand è facile da usare ma più costoso con traffico elevato e costante; la modalità provisioned con autoscaling e Reserved Capacity può essere molto più economica. Il dimensionamento della cache, le policy di eviction e le scelte di persistenza in ElastiCache influenzano il costo e il ripristino. Valuta la durabilità, i modelli di consistenza e la complessità operativa quando scegli tra database NoSQL gestiti, cache in-memory e database a grafo.

DynamoDB vs RDS/Aurora: DynamoDB per scalabilità massiva, schema flessibile, design a tabella singola; RDS/Aurora per query SQL complesse, transazioni e integrità relazionale.
ElastiCache (Redis) vs DAX: Redis per carichi di lavoro in-memory generici e persistenza; DAX è una cache di lettura specifica per DynamoDB con integrazione lato client.
Neptune: Da usare quando le attraversate e l’analisi dei grafi sono centrali per l’applicazione.

Pattern per analytics e data lake: Amazon Redshift, Athena e scelte di storage S3

Amazon Redshift è un data warehouse colonnare su scala petabyte, ottimizzato per query analitiche complesse e alta concorrenza. Il Redshift moderno (nodi RA3) disaccoppia il calcolo e lo storage gestito, permettendoti di scalare il calcolo in modo indipendente e di ridurre i costi sfruttando S3 come storage gestito; Redshift Spectrum interroga i dati direttamente in S3 per l’integrazione con il data lake. Per query SQL ad-hoc su file, Amazon Athena fornisce analytics serverless pay-per-query (fatturate per TB scansionato) ed è ideale per CSV/Parquet/JSON su S3; l’ottimizzazione dei formati e della compressione riduce drasticamente i costi. S3 offre diverse classi di storage: per pattern di accesso sconosciuti, S3 Intelligent-Tiering sposta automaticamente gli oggetti tra i livelli di accesso per minimizzare i costi senza tariffe di recupero; per archivi a lungo termine considera S3 Glacier o Glacier Deep Archive, dove si applicano latenze e costi di recupero. I compromessi di costo includono storage vs calcolo: comprimi, partiziona e usa formati colonnari per ridurre i volumi di scansione; considera il concurrency scaling e il workload management di Redshift per prestazioni prevedibili. Per carichi di lavoro di machine learning legati all’analytics, un training intensivo può richiedere famiglie di EC2 con GPU (serie P o G), ma la maggior parte dei carichi di lavoro su database analitici si basa su CPU ottimizzate ed esecuzione colonnare piuttosto che su GPU.

Migrazione, backup, sicurezza e best practice operative

La migrazione e la protezione dei database richiedono il giusto mix di servizi e policy. AWS Database Migration Service (DMS) gestisce migrazioni omogenee ed eterogenee con tempi di inattività minimi; lo Schema Conversion Tool aiuta a convertire gli schemi dei database quando si passa da un tipo di motore all’altro. Per i backup e la protezione basata su policy, utilizzare le funzionalità native dei motori (backup automatici e snapshot di RDS, PITR di DynamoDB) insieme ad AWS Backup per policy di backup centralizzate e multi-servizio e per copie cross-account o cross-region. La sicurezza deve includere policy IAM basate sul principio del privilegio minimo (least-privilege), crittografia in transito (TLS) e a riposo (KMS), e controlli di rete: i security group sono firewall stateful a livello di host che si collegano alle istanze, mentre le network ACL sono filtri stateless a livello di sottorete — entrambi sono complementari ma hanno un comportamento diverso. Secondo il modello di responsabilità condivisa, AWS gestisce l’infrastruttura cloud, mentre i clienti gestiscono i dati, IAM, le patch a livello di sistema operativo su istanze autogestite e la rotazione delle chiavi per segreti e credenziali di accesso. L’automazione operativa tramite CloudFormation, AWS CLI o gli SDK consente il provisioning di ambienti ripetibili; le trappole comuni sono fare affidamento sull’account root, lasciare in vigore policy IAM troppo permissive, trascurare la rotazione delle chiavi e non monitorare l’ambiente con CloudWatch, VPC Flow Logs o AWS Config. Per trasferimenti di grandi volumi di dati, considerare AWS Snowball o DataSync per spostare terabyte/petabyte in modo sicuro con crittografia in transito e convalida dell’integrità.

Problema pratico: Scenario d’uso

Scenario: AcmeRetail gestisce una piattaforma di e-commerce stagionale con un database OLTP MySQL on-premise e grandi file CSV storici delle vendite su una condivisione NFS locale. Il loro account AWS ha un VPC con sottoreti private e un Transit Gateway verso il loro data center. Hanno bisogno di migrare il database transazionale con tempi di inattività minimi e di rendere i dati storici interrogabili per la BI.

Sfida: Spostare il database di produzione con tempi di inattività quasi nulli, abilitare analisi scalabili sui CSV storici e garantire backup, crittografia e accesso basato sul principio del privilegio minimo.

Approccio consigliato:

Utilizzare AWS Database Migration Service (DMS) con lo Schema Conversion Tool, se necessario, per migrare MySQL su Amazon Aurora (compatibile con MySQL), configurando la replica continua per ridurre al minimo i tempi di inattività.
Trasferire i file CSV storici su Amazon S3 utilizzando AWS DataSync o Snowball (per volumi molto grandi), archiviarli in S3 utilizzando Intelligent-Tiering e convertirli in formato Parquet con AWS Glue ETL per migliorare l’efficienza delle query.
Effettuare il provisioning di Amazon Redshift (RA3) o utilizzare Amazon Athena sui dati in S3 (Parquet) per le query di BI; usare Redshift Spectrum se si combinano query sul data warehouse e sul data lake.
Implementare backup automatici (backup automatici e snapshot di RDS), abilitare la crittografia con chiavi KMS, limitare l’accesso con ruoli IAM e security group basati sul principio del privilegio minimo e centralizzare le policy di backup con AWS Backup.

Motivazione: La replica continua di DMS consente una migrazione con tempi di inattività quasi nulli per i sistemi transazionali; la combinazione S3 + Parquet + Athena/Redshift minimizza i costi di analisi e le dimensioni delle scansioni; KMS, i backup e le policy IAM basate sul privilegio minimo sono in linea con il modello di responsabilità condivisa e le best practice operative per disponibilità, sicurezza e controllo dei costi.

← Servizi di archiviazione principali · Tutti i domini · Networking e distribuzione di contenuti →

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