Amazon DEA-C01: Ottimizzazione dei costi per i carichi di lavoro dei dati — 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.

L’ottimizzazione dei costi per i carichi di lavoro dati garantisce che lo storage, il calcolo (compute) e le pipeline di elaborazione dei dati forniscano valore senza una spesa fuori controllo. I data engineer devono bilanciare le prestazioni delle query, la durabilità dei dati e la disponibilità con modelli di prezzo che variano a seconda del servizio e del pattern di utilizzo. Questo ambito richiede familiarità con le classi di storage e le policy del ciclo di vita, i controlli a livello di query e di cluster, la capacità spot e riservata, e i compromessi tra serverless e provisioned.

Ottimizzazione dei costi di storage S3

S3 Intelligent-Tiering è la scelta predefinita consigliata per i set di dati con pattern di accesso imprevedibili: abilitare Intelligent-Tiering tramite la console o la AWS CLI quando la frequenza di accesso agli oggetti non può essere prevista in modo affidabile. Configurare Intelligent-Tiering con la dovuta consapevolezza dei costi di monitoraggio/automazione (c’è un piccolo addebito mensile di monitoraggio per oggetto) e il giusto numero minimo di giorni per le transizioni automatiche tra livelli (30 giorni per i livelli da accesso frequente a infrequente). Utilizzare i tag degli oggetti e le regole del ciclo di vita per escludere oggetti piccoli e molto richiesti, per i quali i costi di monitoraggio supererebbero i risparmi.

Utilizzare questi pattern operativi per ridurre la spesa di S3:

Eseguire S3 Storage Class Analysis (console > Management > Analytics o

undefined

) per identificare i pattern di accesso a livello di prefisso/tag prima di creare regole del ciclo di vita.

Convertire grandi set di dati storici in classi di archiviazione (Glacier Flexible Retrieval o Glacier Deep Archive) utilizzando le transizioni del ciclo di vita; impostare la tempistica della transizione del ciclo di vita in modo che corrisponda agli SLA aziendali e per evitare frequenti recuperi Expedited.
Consolidare molti oggetti di piccole dimensioni (problema dei file piccoli) in oggetti più grandi (file contenitore Parquet) per i carichi di lavoro analitici, al fine di ridurre i costi per richiesta e per GET.

Criteri decisionali:

Usare Intelligent-Tiering per set di dati con accesso imprevedibile e moderato, dove la tempistica di recupero è flessibile.
Usare Standard-IA o One Zone-IA per dati a cui si accede di rado ma che devono essere recuperabili rapidamente, con recuperi prevedibili.
Usare Glacier Standard/Bulk/Deep Archive per la conservazione a lungo termine, dove i recuperi sono rari e possono tollerare una latenza da minuti a ore; preferire i recuperi Bulk/Standard rispetto a Expedited per evitare costi elevati.

Gestione dei costi di Athena e Redshift

I costi di Athena scalano in base ai byte scansionati. Impostare controlli sui gruppi di lavoro (console o

undefined

) per implementare limiti di dati scansionati per query e budget mensili per gruppo di lavoro; abilitare “Enforce workgroup settings” in modo che le query che superano il limite di dati per query falliscano invece di essere eseguite. Ridurre i byte scansionati convertendo i file di origine in formati colonnari compressi (Parquet/ORC), partizionando per data o per colonne di filtro comuni, applicando il predicate pushdown e utilizzando CTAS o CREATE TABLE AS per materializzare set di dati ottimizzati. Utilizzare il riutilizzo dei risultati delle query e l’isolamento dei carichi di lavoro in gruppi di lavoro separati per evitare fughe di costi tra team.

Le decisioni sui costi di Redshift dipendono dalla prevedibilità del carico di lavoro e dalle scelte di storage. Per un utilizzo di calcolo del data warehouse stabile e prevedibile, acquistare Nodi Riservati (termini di uno o tre anni, opzioni di pagamento parziale/totale anticipato) per assicurarsi sconti rispetto alla modalità on-demand. Per carichi di lavoro variabili:

Usare Redshift Serverless o nodi RA3 con storage gestito per disaccoppiare il calcolo (compute) e lo storage.
Usare il concurrency scaling con parsimonia (comporta costi aggiuntivi ma fornisce scalabilità automatica) e monitorare i crediti.

Punti salienti del confronto:

Nodi Riservati: ideali per cluster a regime e a lungo termine; richiedono un impegno ma offrono uno sconto significativo.
On-demand: flessibile per progetti imprevedibili o a breve termine; costo orario più elevato.
Serverless/RA3 con Spectrum: sposta lo storage su S3 e paga per il calcolo quando è attivo per evitare grandi impegni di capacità riservata.

Strategie di costo per Glue ed EMR

AWS Glue fornisce ETL serverless con diverse leve di costo. Per i job batch che non sono sensibili alla latenza, utilizzare l’esecuzione flessibile di Glue (job Glue Flex), che può ridurre i costi fino a circa il 34% rispetto all’esecuzione standard di Glue. Configurare i parametri del job Glue in Glue Studio o tramite la CLI (

undefined

) per selezionare il tipo di worker e il numero massimo di DPU, impostare un limite massimo ragionevole di DPU per prevenire un auto-scaling illimitato e utilizzare i job bookmark per evitare la rielaborazione completa. Per carichi di lavoro interattivi o sensibili alla latenza, scegliere i tipi di worker (Standard/G.1X/G.2X) e ottimizzare il parallelismo in modo responsabile.

La riduzione dei costi di EMR si basa sull’utilizzo di Istanze Spot per i nodi task, mantenendo i nodi master e core On-Demand (configurare flotte di istanze o gruppi di istanze nella console o tramite

undefined

). Utilizzare le Istanze Spot solo per i nodi task, selezionare la strategia di allocazione capacity-optimized e impostare un’offerta/prezzo massimo appropriato se si utilizza Spot con offerte. Proteggere lo stato del cluster e la resilienza dei job:

Archiviando i dati persistenti in S3 (usare EMRFS) anziché in HDFS quando si utilizzano nodi task Spot.
Utilizzando tentativi automatici e flussi di lavoro basati su step per gestire le interruzioni delle istanze Spot.
Impiegando EMR Managed Scaling per dimensionare correttamente i cluster; monitorare le policy di scaling per evitare oscillazioni.

Criteri decisionali:

Usare Glue Flex per ETL a bassa priorità e sensibili ai costi, con tolleranza per tempi di avvio più lunghi; limitare il numero massimo di DPU.
Usare EMR con nodi task Spot per grandi elaborazioni transienti (es. batch notturni), ma mantenere i nodi master/core On-Demand o usare Flotte di Istanze con allocazione mista.

Capacità riservata e Savings Plans per i servizi dati

La capacità riservata e i Savings Plans si applicano in modo diverso ai vari servizi dati. Per i servizi basati su EC2 (EMR, HBase autogestito, Hadoop personalizzato), utilizzare gli EC2 Savings Plans o le Istanze Riservate per coprire la spesa di calcolo; selezionare opzioni regionali o zonali in base alle esigenze di mobilità. Redshift supporta l’acquisto di nodi riservati per i cluster con provisioning per ridurre i costi orari dei workload di data warehouse prevedibili. I servizi serverless (Glue, Athena) non dispongono di prenotazioni di risorse; ottimizzare invece attraverso la pianificazione dei workload e modifiche al formato dei dati.

Guida pratica all’acquisto:

Acquistare Nodi Riservati di Redshift per workload di data warehouse stabili con utilizzo noto (valutare termini di 1 o 3 anni e opzioni di pagamento anticipato totale/parziale/nullo).
Utilizzare gli EC2 Savings Plans per coprire la spesa prevedibile di EMR/EC2 su diverse famiglie di istanze; i Savings Plans offrono flessibilità in caso di cambio di famiglia di istanze o regione.
Non acquistare prenotazioni per servizi serverless; ottimizzare invece i modelli di utilizzo, la pianificazione e la disposizione dei dati.

Insidie comuni e criteri decisionali

Athena scansiona l’intera tabella senza partizionamento — partizionare sempre le tabelle di grandi dimensioni e basate su serie temporali per data o altre colonne ad alta cardinalità e filtrate di frequente, e convertirle in Parquet/ORC per minimizzare i byte scansionati.
L’auto-scaling delle DPU di Glue può causare un over-provisioning — impostare un limite massimo di DPU nella configurazione del job (console o

undefined

) e scegliere tipi di worker appropriati per mantenere i costi prevedibili.

Costi di recupero da S3 Glacier — evitare il recupero Expedited a meno che non sia critico per il business; pianificare recuperi di tipo Standard o Bulk e impostare transizioni del ciclo di vita con SLA realistici.
I nodi master e core di EMR non dovrebbero usare istanze Spot — configurare i nodi master/core come On-Demand e assegnare istanze Spot solo ai nodi di task, evitando o replicando lo stato HDFS.
Molti oggetti S3 di piccole dimensioni gonfiano i costi delle richieste e rallentano le analisi — compattare i file piccoli in file colonnari più grandi durante l’ingestion.
Un eccessivo affidamento sul concurrency scaling o sull’auto-scaling non gestito può aumentare i costi orari — monitorare le metriche di scaling, impostare limiti e utilizzare la capacità riservata quando i workload sono prevedibili.

Problema pratico: riduzione dei costi dell’ETL notturno di Acme Analytics

Acme Analytics esegue ETL notturni e analisi ad-hoc giornaliere; la spesa mensile per il cloud è aumentata vertiginosamente a causa della crescita dello storage S3 grezzo e delle ore on-demand di Redshift. L’azienda necessita di una riduzione del 35% senza impattare gli SLA notturni.

Eseguire S3 Storage Class Analysis e applicare regole del ciclo di vita per spostare i file grezzi “cold” più vecchi di 90 giorni su Glacier Flexible Retrieval (pianificare recuperi Bulk/Standard).
Convertire i CSV grezzi in Parquet partizionato e compresso e compattare i file piccoli; archiviare i dataset ottimizzati sotto prefissi separati per Athena/Redshift Spectrum.
Creare workgroup Athena con limiti sui dati scansionati per query e imporre le impostazioni del workgroup; abilitare il riutilizzo dei risultati delle query e impostare un budget mensile per workgroup.
Migrare l’ETL batch su job Glue Flex per le trasformazioni non urgenti, impostare limiti massimi di DPU e pianificarli durante le ore non di punta; mantenere una flotta Glue standard più piccola per i job urgenti.
Dimensionare correttamente Redshift: acquistare Nodi Riservati per 1 anno per il carico di calcolo di base costante, spostare i dati storici su S3 e usare Spectrum per le query poco frequenti, e abilitare il concurrency scaling solo con monitoraggio.

Logica: La strategia combina l’ottimizzazione del formato dei dati e del ciclo di vita (riducendo i costi di storage e di scansione), l’esecuzione serverless a basso costo per i job flessibili (Glue Flex), la governance delle query (workgroup Athena) e la capacità riservata per il calcolo sostenuto per massimizzare gli sconti preservando disponibilità e performance.

← Monitoraggio e risoluzione dei problemi delle pipeline di dati · Tutti i domini · Qualità →

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