Amazon SAP-C02: Database e analytics — Guida allo studio

By Laurynas Brazys · 31 July 2026 · #amazon #sap-c02 #certification #exam-prep #study-guide

Fa parte della AWS Solutions Architect Professional SAP-C02 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Database Transazionali, Pattern di Scalabilità e Caching

La scelta tra Amazon RDS (MySQL/PostgreSQL/Oracle/SQL Server), Amazon Aurora e Amazon DynamoDB inizia dal profilo del carico di lavoro: uno schema relazionale rigido e transazioni complesse favoriscono RDS/Aurora; scalabilità massiva, ricerche con latenza nell’ordine dei millisecondi a singola cifra e uno schema flessibile favoriscono DynamoDB. Aurora offre un throughput elevato con storage distribuito, autoscaling delle repliche, failover rapido, Global Database per letture cross-region e disaster recovery a latenza ridotta. RDS Multi-AZ fornisce la replica sincrona per l’alta disponibilità ma non per la scalabilità in lettura; le repliche di lettura (read replica) (RDS/Aurora) gestiscono i carichi di lavoro con un’intensa attività di lettura. Per il caching key-value e una latenza nell’ordine dei microsecondi, ElastiCache (Redis o Memcached) riduce il carico sul database; MemoryDB for Redis aggiunge la durabilità e una persistenza compatibile con Redis laddove i dati devono essere altamente disponibili e recuperabili. Le trappole comuni includono la sottostima dei limiti di connessione (numero massimo di connessioni di MySQL), il mancato utilizzo del connection pooling (con Lambda/container che generano molte connessioni), le partizioni “hot” in DynamoDB a causa di una progettazione errata delle chiavi e la trascuratezza delle policy di eviction/progettazione della cache, che porta a dati obsoleti (stale data). I compromessi decisionali (trade-off) si concentrano spesso sul costo rispetto alle prestazioni e alla resilienza: le istanze Aurora/RDS di grandi dimensioni in modalità provisioned costano di più ma riducono la latenza e semplificano le transazioni, mentre DynamoDB con modalità on-demand o autoscaling può ridurre i costi operativi ma richiede un’attenta pianificazione dello schema e della capacità. La crittografia, i backup automatizzati, il PITR (Point-In-Time Recovery) e i pattern di replica cross-region devono essere scelti in base a RPO/RTO.

Data Lake, ETL e Motori di Query Analitiche

S3 è il data lake durevole per antonomasia; la progettazione deve basarsi su partizionamento, formati colonnari (Parquet/ORC), compressione e compattazione (compaction) per ottenere query efficienti in termini di costi. AWS Glue e AWS Glue Data Catalog forniscono ETL serverless, scoperta dello schema (schema discovery) e catalogazione; Lake Formation aggiunge controllo degli accessi centralizzato, permessi granulari (fine-grained) e condivisione cross-account per data lake governati. Per l’analisi interattiva, Amazon Athena esegue query direttamente sui dati in S3 (serverless, con pagamento per query), mentre Amazon Redshift (con supporto RA3/Iceberg) fornisce un data warehouse MPP gestito e performante per BI complessa e join. Utilizzare Redshift Spectrum per eseguire query sui dati di S3 da Redshift senza doverli ingerire tutti. Kinesis Data Firehose è un percorso di ingestione gestito per trasferire eventi in streaming su S3 o Redshift. Le trappole comuni per gli architetti includono un numero eccessivo di file di piccole dimensioni che causa un overhead elevato per Athena/Redshift, chiavi di partizione scelte male che creano sbilanciamenti (skew) e la mancata compattazione o conversione in formati colonnari. I compromessi riguardano la latenza rispetto al costo: Athena ha un basso costo operativo per query ad-hoc; Redshift offre prestazioni sostenute più elevate a un costo provisioned maggiore. La data governance e il lineage tramite Glue/Lake Formation sono essenziali per la conformità e la proprietà condivisa tra più team.

Streaming, Elaborazione in Tempo Reale e Ricerca

L’ingestione e l’elaborazione in tempo reale utilizzano Kinesis Data Streams (throughput basato su shard e garanzie di ordinamento), Kinesis Data Firehose (consegna gestita verso destinazioni, o sink), Kinesis Data Analytics (elaborazione con SQL/Apache Flink) o Amazon MSK per esigenze di compatibilità con Kafka. Scegliere Kinesis per un’integrazione serverless nativa AWS semplice e diretta; scegliere MSK quando i client si basano sugli strumenti dell’ecosistema Kafka. Le semantiche di consegna “at-least-once”, i limiti degli shard, il parallelismo dei consumer e il provisioning di un numero adeguato di shard sono comuni insidie operative. Per la ricerca rapida a valle (downstream) e l’osservabilità, Amazon OpenSearch Service fornisce indicizzazione, ricerca near-real-time e dashboard Kibana integrate; la gestione del ciclo di vita degli indici (index lifecycle management) e i tier warm/cold riducono i costi per i dati più vecchi. Utilizzare Kinesis + Lambda o Kinesis + KDA per arricchire/trasformare gli eventi prima di persisterli su OpenSearch o S3. Progettare l’idempotenza e la deduplicazione nei consumer, poiché i tentativi (retry) o le riesecuzioni (replay) possono causare duplicati. I criteri decisionali bilanciano throughput e latenza: Kinesis con molti shard supporta un throughput elevato ma aumenta i costi e la gestione; Firehose elimina l’onere del consumer ma offre una trasformazione meno flessibile.

Migrazione, Replica, Governance e Resilienza Operativa

Database Migration Service (AWS DMS) e Schema Conversion Tool (SCT) sono gli strumenti principali per migrazioni omogenee ed eterogenee, abilitando la change data capture (CDC) continua. I pattern di migrazione includono il rehost (lift-and-shift), il replatform (ad es. spostamento su Aurora) e il refactor verso DynamoDB o soluzioni serverless, a seconda dei casi. Utilizzare DMS con validazione pre e post-migrazione, copia parallela delle tabelle e un’attenta gestione dei LOB/LOBLOB. La replica tra account e tra regioni richiede l’accesso a chiavi KMS, il peering VPC o un Transit Gateway e la pianificazione della larghezza di banda di rete; le Global Databases e le repliche di lettura sono alternative quando sono necessarie letture a bassa latenza tra le regioni. La governance e la sicurezza devono includere Lake Formation per la condivisione dei dati, il principio del privilegio minimo di IAM, policy delle risorse per gli snapshot di S3 e RDS e VPC endpoint/PrivateLink per evitare l’egress pubblico. Le trappole operative includono un monitoraggio insufficiente (mancata rilevazione del replica lag), la mancata esecuzione di test di failover/runbook e costi di egress nascosti durante i trasferimenti di massa. La strategia di backup, PITR e ripristino automatico influisce sui compromessi RTO/RPO; combinare la replica per l’alta disponibilità con backup regolari per la conservazione a lungo termine e la conformità.

Problema Pratico: Scenario d’Uso

Scenario: Acme Retail gestisce una piattaforma di e-commerce in un’organizzazione AWS multi-account con carichi di lavoro di produzione in us-east-1 e europe-west-1. L’azienda archivia clickstream ed eventi transazionali in S3 e gestisce un database OLTP on-premise che deve essere migrato su AWS con tempi di inattività minimi.

Sfida: Migrare il database OLTP verso una destinazione ad alta disponibilità e scalabile in lettura tra le regioni, costruendo al contempo un data lake analitico governato su S3 con capacità di ingestione ed esecuzione di query in tempo reale.

Approccio Raccomandato:

Utilizzare AWS DMS con SCT per la conversione dello schema e impostare una CDC continua dal DB on-premise ad Amazon Aurora (Global Database) in us-east-1, con una replica di lettura Aurora in europe-west-1.
Ingerire i clickstream e gli eventi transazionali tramite Amazon Kinesis Data Streams e Firehose; bufferizzare e distribuire gli eventi grezzi su S3 in formato Parquet, partizionati per data e regione.
Catalogare i dati di S3 con AWS Glue, applicare il controllo degli accessi tramite Lake Formation ed eseguire ETL con i job di Glue (o Glue Studio) per produrre dataset curati; esporli agli analisti tramite Amazon Athena e Redshift Spectrum.
Aggiungere ElastiCache (Redis) per il caching ad alta intensità di lettura dei dati “caldi” di prodotti e sessioni; implementare il monitoraggio end-to-end con CloudWatch, abilitare l’Enhanced Monitoring su Aurora e convalidare il failover con i runbook.

Motivazione: Questo approccio minimizza i tempi di inattività utilizzando la CDC di DMS, fornisce letture globali a bassa latenza tramite Aurora Global Database, stabilisce un data lake governato su S3 per l’agilità analitica e riduce il carico sui sistemi OLTP con il caching e l’ingestione disaccoppiata in streaming, in linea con le best practice aziendali di resilienza e performance.

← Storage e gestione dei dati · Tutti i domini · Migrazione e modernizzazione →

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