Amazon DEA-C01: Archiviazione dei dati e architettura del Lake — Guida allo studio

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Fa parte della Amazon Data Engineer Associate DEA-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Questo dominio tratta di come i servizi di storage e i motori di database AWS supportino l’ingestion di dati su larga scala, l’archiviazione durevole, le prestazioni delle query e la governance sicura nelle moderne piattaforme dati. I data engineer devono bilanciare costi, latenza di accesso, durabilità e controllo granulare degli accessi durante l’integrazione di servizi come S3, Lake Formation, Redshift e DynamoDB nelle pipeline. Comprendere i compromessi tra le classi di storage, l’automazione del ciclo di vita, lo storage gestito rispetto a quello locale e i pattern di partizionamento previene sorprese in termini di prestazioni e costi in produzione.

Classi di storage e policy del ciclo di vita di Amazon S3

S3 offre diverse classi di storage e controlli del ciclo di vita per ottimizzare i costi e i pattern di accesso. È possibile configurare la classe di storage al momento del caricamento (dalla console o tramite CLI:

undefined

) o utilizzare le regole del ciclo di vita del bucket (

undefined

). Intelligent-Tiering sposta automaticamente gli oggetti tra i livelli di accesso frequente e infrequente e prevede una piccola tariffa di monitoraggio; è consigliabile abilitarlo per pattern di accesso sconosciuti o variabili. Utilizzare le regole del ciclo di vita per trasferire gli oggetti a GLACIER o DEEP_ARCHIVE per la conservazione a lungo termine e per far scadere/eliminare le versioni precedenti.

Criteri decisionali e compromessi:

Intelligent-Tiering: basso overhead operativo per accessi variabili, costo di monitoraggio mensile per oggetto; ideale quando il pattern di accesso è imprevedibile.
Glacier vs Glacier Deep Archive: Glacier offre opzioni di recupero standard e accelerato più veloci con un costo di storage più elevato; Deep Archive è il più economico per la conservazione pluriennale con tempi di recupero standard/bulk (ore).
Standard-IA vs Intelligent-Tiering: Standard-IA ha un addebito minimo di 30 giorni e costi di recupero — da evitare per dati ad accesso frequente o oggetti di breve durata.

Note operative:

Abilitare il versioning (

undefined

) e l’object lock (

undefined

) per l’immutabilità; l’abilitazione di MFA Delete richiede operazioni CLI speciali e l’account del proprietario del bucket con MFA.

Le transizioni del ciclo di vita si applicano alle versioni degli oggetti e possono essere limitate per prefisso/tag; utilizzare abort-incomplete-multipart-upload per evitare perdite di storage.

Progettazione di un data lake con S3 e Lake Formation

Progettare un data lake con S3 come object store centrale e Lake Formation per il controllo degli accessi centralizzato e la catalogazione. Registrare le location S3 come risorse di Lake Formation, impostare un AWS Glue Data Catalog e utilizzare le concessioni (grant) di Lake Formation per database/tabelle (

undefined

). Lake Formation può applicare controlli granulari: a livello di colonna, a livello di riga (con espressioni di filtro) e mascheramento a livello di cella utilizzando LF-tag e filtri dati applicati alle query di Glue/Athena.

Pattern chiave di configurazione e governance:

Registrare la location: utilizzare la console di Lake Formation per registrare s3://bucket/path e associare un ruolo IAM che consenta a Lake Formation di eseguire il crawling/leggere.
Policy granulari: definire LF-tag e associarli a tabelle/colonne; concedere autorizzazioni con column-list per limitare le colonne e utilizzare espressioni di filtro a livello di riga (row-filter) per limitare le righe restituite per un principal.
Ricordare che le autorizzazioni di Lake Formation possono sovrascrivere o bloccare le autorizzazioni IAM S3 per l’accesso tramite Glue/Athena — concedere sia l’accesso a livello di Lake Formation sia a livello di S3 dove necessario.

Punti decisionali:

Utilizzare Lake Formation quando si necessita di catalogazione centralizzata, LF-tag e applicazione di policy granulari su più motori di analisi.
Per un controllo degli accessi semplice o per l’accesso di strumenti esterni, considerare le policy dei bucket S3 e IAM, ma con attenzione: i motori di analisi governati da Lake Formation potrebbero ignorare le autorizzazioni concesse solo tramite IAM.

Architettura e storage di Amazon Redshift

Redshift separa il calcolo (compute) e lo storage gestito sui nodi RA3 rispetto ai nodi DS2 supportati da SSD locali. I nodi RA3 utilizzano Redshift Managed Storage (RMS), in cui i dati risiedono su Amazon S3 gestito dal cluster; scegliere RA3 per uno storage scalabile con prestazioni di query costanti e la possibilità di pagare separatamente per il calcolo. I nodi DS2 archiviano i dati su dischi locali dell’istanza, il che richiede un attento dimensionamento e ridimensionamento man mano che i dati crescono.

Dettagli di configurazione e operativi:

Creare un cluster RA3 tramite console o CLI:

undefined

Comando COPY: deve essere eseguito su un cluster a cui è associato un ruolo IAM che concede l’accesso in lettura a S3. Associare il ruolo alla creazione del cluster o modificare il cluster per aggiungere ruoli IAM; l’ARN del ruolo (

undefined

) è referenziato nel comando COPY come credenziali ‘aws_iam_role=arn:…’.

Monitorare le code WLM, la short query acceleration, il vacuuming automatico e utilizzare SORT/ENCODE per ottimizzare lo storage e le prestazioni.

Confronto (RA3 vs DS2):

RA3: storage disaccoppiato, tiering automatico dei dati su S3, minore gestione dello storage, ideale per dataset in crescita.
DS2: storage SSD locale, latenza inferiore per i dati locali ma capacità limitata e più difficile da scalare.

DynamoDB e selezione di database purpose-built

Scegliere DynamoDB per carichi di lavoro chiave-valore e a documenti su larga scala che richiedono una latenza nell’ordine dei millisecondi a singola cifra. La progettazione della tabella dipende dalla selezione della chiave di partizione (e della chiave di ordinamento opzionale): utilizzare chiavi ad alta cardinalità e ben distribuite per evitare partizioni calde (hot partition). Per chiavi sequenziali o basate su timestamp, implementare un prefisso casuale (sharding) o usare UUID per distribuire le scritture. Utilizzare la capacità on-demand per evitare il provisioning, ma considerare la capacità con provisioning e autoscaling per carichi di lavoro prevedibili e per sfruttare la capacità adattiva sulle partizioni calde.

Note pratiche di configurazione:

CLI per la creazione della tabella: aws dynamodb create-table –table-name Events –attribute-definitions AttributeName=pk,AttributeType=S AttributeName=sk,AttributeType=S –key-schema AttributeName=pk,KeyType=HASH AttributeName=sk,KeyType=RANGE –billing-mode PAY_PER_REQUEST.
Utilizzare i GSI per pattern di accesso alternativi, abilitare il TTL per la scadenza automatica e usare DynamoDB Streams + Lambda per pattern di change-data-capture.
Per la cache di carichi di lavoro con molte letture, aggiungere DAX; per query complesse o esigenze relazionali, scegliere Aurora o Redshift Spectrum a seconda della complessità delle query e delle esigenze di coerenza.

Criteri decisionali per la selezione del motore:

Utilizzare DynamoDB per pattern di accesso prevedibili su singola tabella e per una scalabilità massiva con bassa latenza.
Utilizzare Redshift per analisi complesse e OLAP su larga scala.
Utilizzare Aurora per carichi di lavoro relazionali transazionali.

Errori Comuni e Criteri Decisionali

Utilizzare S3 Standard-IA per dati ad accesso frequente — Standard-IA ha un addebito minimo di 30 giorni; usare Standard o Intelligent-Tiering per oggetti di breve durata o ad accesso frequente.
Dimenticare che i permessi di Lake Formation sovrascrivono i permessi IAM S3 per Glue/Athena — concedere l’accesso sia a Lake Formation sia a S3 quando si usano Glue/Athena e verificare i permessi effettivi nella console di Lake Formation.
Il comando COPY di Redshift richiede un ruolo IAM associato al cluster, non solo i permessi dell’utente — associare un ruolo IAM con accesso a S3 al cluster e fare riferimento al suo ARN nelle operazioni COPY.
Partizioni calde (hot partition) in DynamoDB a causa di chiavi sequenziali — evitare chiavi monotone; usare chiavi con hash, prefissi casuali o UUID e considerare la capacità on-demand o con provisioning e autoscaling.
Abilitare S3 Object Lock e MFA Delete in modo errato — Object Lock richiede che il versioning sia abilitato e i permessi appropriati; MFA Delete può essere abilitato/disabilitato solo tramite la CLI con MFA e ha requisiti stringenti sul proprietario del bucket.
Transizioni del ciclo di vita improprie senza testare i costi e i tempi di recupero — testare i flussi di lavoro di recupero per le classi Glacier per evitare latenze e addebiti di recupero imprevisti.

Problema Pratico: Scenario d’Uso

Acme Media deve archiviare 50 TB di video grezzi in ingresso, fornire agli analisti accesso in query ai metadati trasformati e applicare un accesso a livello di riga e colonna per diverse unità di business, minimizzando al contempo i costi di archiviazione.

Ingestire i video grezzi in S3 usando il multipart upload, taggare gli oggetti per data di ingestione e dataset, utilizzare Intelligent-Tiering per i pattern di accesso inizialmente sconosciuti.
Configurare regole di ciclo di vita per trasferire i media su GLACIER o DEEP_ARCHIVE dopo un periodo di conservazione configurabile (assicurare un allineamento di 30+ giorni per Standard-IA, se viene preso in considerazione).
Registrare le location S3 in Lake Formation, creare crawler Glue per popolare il Data Catalog e concedere permessi a livello di riga e colonna basati su tag di Lake Formation alle unità di business.
Archiviare i metadati curati in Redshift RA3 per l’analisi; associare un ruolo IAM al cluster per il comando COPY da S3 e utilizzare le operazioni VACUUM/ANALYZE durante le finestre di manutenzione.
Utilizzare DynamoDB con chiavi UUID sottoposte ad hash per una tabella di lookup ad alto throughput dei manifest dei video e abilitare la capacità on-demand per assorbire i picchi di traffico.

Motivazione: Questo approccio isola i costi di archiviazione a freddo (cold storage) con le classi Glacier, utilizza Intelligent-Tiering per pattern sconosciuti, applica Lake Formation per un controllo degli accessi sicuro e granulare su tutti i motori di analisi, e seleziona RA3 per uno storage analitico scalabile, mentre DynamoDB gestisce le ricerche operative a bassa latenza.

← Ingestione e raccolta dei dati · Tutti i domini · Catalogazione dei dati e gestione dei metadati →

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