Amazon DEA-C01: Kostenoptimalisatie voor dataworkloads — Studiegids

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

Onderdeel van de Amazon Data Engineer Associate DEA-C01 — Studiegids. Oefen met geverifieerde antwoorden in het Amazon-examencentrum, of doe getimede oefentests op ExamRoll.io.

Kostenoptimalisatie voor data workloads zorgt ervoor dat opslag-, compute- en dataverwerkingspipelines waarde leveren zonder onbeheersbare uitgaven. Data engineers moeten een balans vinden tussen queryprestaties, dataduurzaamheid en beschikbaarheid, en prijsmodellen die variëren per service en gebruikspatroon. Dit domein vereist bekendheid met opslagklassen en lifecycle-beleid, controles op query- en clusterniveau, spot- en gereserveerde capaciteit, en de afwegingen tussen serverless en provisioned.

Kostenoptimalisatie voor S3-opslag

S3 Intelligent-Tiering is de aanbevolen standaard voor datasets met onvoorspelbare toegangspatronen: activeer Intelligent-Tiering via de console of AWS CLI wanneer de toegangsfrequentie tot objecten niet betrouwbaar kan worden voorspeld. Configureer Intelligent-Tiering met bewustzijn van de bijbehorende monitoring-/automatiseringskosten (er is een kleine maandelijkse monitoringkost per object) en het juiste minimumaantal dagen voor automatische overgangen naar een andere tier (30 dagen voor de overgang van frequent naar infrequent gebruikte tiers). Gebruik object-tags en lifecycle-regels om kleine objecten met veel requests uit te sluiten, waarbij de monitoringkosten hoger zouden zijn dan de besparingen.

Gebruik deze operationele patronen om S3-uitgaven te verminderen:

Voer S3 Storage Class Analysis uit (console > Management > Analytics of

undefined

) om toegangspatronen op prefix-/tag-niveau te identificeren voordat je lifecycle-regels aanmaakt.

Converteer grote historische datasets naar archiefklassen (Glacier Flexible Retrieval of Glacier Deep Archive) met behulp van lifecycle-transities; stel de timing van de lifecycle-transitie af op de zakelijke SLA’s en vermijd frequente Expedited retrievals.
Voeg veel kleine objecten (het ‘small-file problem’) samen tot grotere objecten (Parquet-containerbestanden) voor analytische workloads om de kosten per request en per GET te verlagen.

Beslissingscriteria:

Gebruik Intelligent-Tiering voor onvoorspelbare, gemiddeld gebruikte datasets waarbij de ophaaltijd flexibel is.
Gebruik Standard-IA of One Zone-IA voor data die niet vaak wordt benaderd maar wel snel en voorspelbaar moet kunnen worden opgehaald.
Gebruik Glacier Standard/Bulk/Deep Archive voor langetermijnbewaring waarbij ophalen zeldzaam is en een latentie van minuten tot uren acceptabel is; geef de voorkeur aan Bulk/Standard retrievals boven Expedited om hoge kosten te vermijden.

Kostenbeheer voor Athena en Redshift

Athena-kosten schalen met het aantal gescande bytes. Dwing workgroup-controles af (console of

undefined

) om limieten voor gescande data per query en maandelijkse budgetten per workgroup te implementeren; activeer “Enforce workgroup settings” zodat queries die de datalimiet per query overschrijden, mislukken in plaats van worden uitgevoerd. Verminder het aantal gescande bytes door bronbestanden te converteren naar kolomgeoriënteerde, gecomprimeerde formaten (Parquet/ORC), te partitioneren op datum of veelgebruikte filterkolommen, predicate pushdown toe te passen en CTAS of CREATE TABLE AS te gebruiken om geoptimaliseerde datasets te materialiseren. Gebruik hergebruik van queryresultaten en isolatie van workloads in afzonderlijke workgroups om kostenoverschrijdingen tussen teams te voorkomen.

Kostenbeslissingen voor Redshift hangen af van de voorspelbaarheid van de workload en de opslagkeuzes. Voor stabiel, voorspelbaar datawarehouse-computegebruik, schaf Reserved Nodes aan (termijnen van één of drie jaar, met gedeeltelijke/volledige vooruitbetaling) om kortingen vast te leggen ten opzichte van on-demand. Voor variabele workloads:

Gebruik Redshift Serverless of RA3-nodes met managed storage om compute en opslag te ontkoppelen.
Gebruik concurrency scaling spaarzaam (dit brengt extra kosten met zich mee maar biedt automatische schaling) en monitor de credits.

Vergelijkingspunten:

Reserved Nodes: het beste voor stabiele, langdurige clusters; vereist een commitment maar levert aanzienlijke korting op.
On-demand: flexibel voor onvoorspelbare of kortlopende projecten; hogere kosten per uur.
Serverless/RA3 met Spectrum: verplaats opslag naar S3 en betaal voor compute wanneer deze actief is om grote gereserveerde commitments te vermijden.

Kostenstrategieën voor Glue en EMR

AWS Glue biedt serverless ETL met meerdere hefbomen voor kostenbeheersing. Gebruik voor batch-jobs die niet latentiegevoelig zijn Glue flexible execution (Glue Flex jobs), wat de kosten tot ~34% kan verlagen in vergelijking met de standaard Glue-uitvoering. Configureer Glue job-parameters in Glue Studio of de CLI (

undefined

) om het workertype en het maximale aantal DPU’s te selecteren, stel een verstandige maximale DPU-limiet in om onbeperkte auto-scaling te voorkomen, en gebruik job bookmarks om volledige herverwerking te vermijden. Kies voor interactieve of latentiegevoelige workloads de juiste workertypes (Standard/G.1X/G.2X) en stem de parallellisatie verantwoord af.

Kostenreductie bij EMR is afhankelijk van het gebruik van Spot Instances voor task nodes, terwijl de master- en core-nodes On-Demand blijven (configureer instance fleets of instance groups in de console of via

undefined

). Gebruik Spot alleen voor task nodes, selecteer de ‘capacity-optimized’ allocatiestrategie en stel een passend bod/maximale prijs in als je Spot met biedingen gebruikt. Bescherm de clusterstatus en de veerkracht van jobs door:

Persistente data op te slaan in S3 (gebruik EMRFS) in plaats van HDFS bij het gebruik van Spot task nodes.
Automatische retries en op stappen gebaseerde workflows te gebruiken om Spot-onderbrekingen op te vangen.
EMR Managed Scaling te gebruiken om de clustergrootte te optimaliseren; monitor het schaalbeleid om oscillatie te voorkomen.

Beslissingscriteria:

Gebruik Glue Flex voor kostengevoelige ETL met lage prioriteit die een langere opstarttijd tolereert; limiteer het maximale aantal DPU’s.
Gebruik EMR met Spot task nodes voor grote, tijdelijke verwerkingen (bijv. nachtelijke batch), maar houd de master/core-nodes On-Demand of gebruik Instance Fleets met een gemengde allocatie.

Gereserveerde capaciteit en Savings Plans voor dataservices

Gereserveerde capaciteit en Savings Plans zijn verschillend van toepassing op dataservices. Voor services die op EC2 draaien (EMR, zelfbeheerde HBase, custom Hadoop), gebruik EC2 Savings Plans of Reserved Instances om de computekosten te dekken; selecteer regionale of zonale opties op basis van mobiliteitsbehoeften. Redshift ondersteunt de aankoop van gereserveerde nodes voor geprovisioneerde clusters om de uurkosten voor voorspelbare warehouse-workloads te verlagen. Serverless services (Glue, Athena) hebben geen resource-reserveringen; optimaliseer in plaats daarvan door de planning van workloads en wijzigingen in het dataformaat.

Praktische aankooprichtlijnen:

Koop Redshift Reserved Nodes voor stabiele datawarehouse-workloads met bekend gebruik (evalueer termijnen van 1 of 3 jaar, en volledige/gedeeltelijke/geen vooruitbetaling).
Gebruik EC2 Savings Plans om voorspelbare EMR/EC2-uitgaven over verschillende instance-families te dekken; Savings Plans bieden flexibiliteit als de instance-familie of regio verandert.
Koop geen reserveringen voor serverless services; optimaliseer in plaats daarvan gebruikspatronen, planning en data-indeling.

Veelvoorkomende valkuilen en beslissingscriteria

Athena scant de volledige tabel zonder partitionering — partitioneer grote tijdreeks-tabellen altijd op datum of andere kolommen met hoge kardinaliteit waarop vaak wordt gefilterd, en converteer naar Parquet/ORC om het aantal gescande bytes te minimaliseren.
Glue DPU auto-scaling kan te veel provisioneren — stel een maximum DPU-limiet in de jobconfiguratie in (console of

undefined

) en kies de juiste worker-types om de kosten voorspelbaar te houden.

Ophaalkosten voor S3 Glacier — vermijd Expedited retrieval tenzij het bedrijfskritisch is; plan voor Standard of Bulk retrieval en stel lifecycle-transities in met realistische SLA’s.
EMR master- en core-nodes mogen geen Spot gebruiken — configureer master/core als On-Demand en wijs Spot alleen toe aan task-nodes waarbij HDFS-status wordt vermeden of gerepliceerd.
Veel kleine S3-objecten drijven de request-kosten op en vertragen analyses — comprimeer kleine bestanden tijdens de opname (ingestion) tot grotere kolomgeoriënteerde bestanden.
Overmatig vertrouwen op concurrency scaling of onbeheerde auto-scaling kan de uurkosten verhogen — monitor schaalbaarheidsstatistieken, stel limieten in en gebruik gereserveerde capaciteit wanneer workloads voorspelbaar zijn.

Praktijkprobleem: Kostenreductie voor de nachtelijke ETL van Acme Analytics

Acme Analytics voert nachtelijke ETL en dagelijkse ad-hoc analyses uit; de maandelijkse clouduitgaven zijn sterk gestegen door groeiende onbewerkte S3-opslag en on-demand Redshift-uren. Het bedrijf heeft een reductie van 35% nodig zonder de nachtelijke SLA’s te beïnvloeden.

Voer S3 Storage Class Analysis en lifecycle-regels uit om ‘koude’ onbewerkte bestanden ouder dan 90 dagen te verplaatsen naar Glacier Flexible Retrieval (plan Bulk/Standard retrievals).
Converteer onbewerkte CSV’s naar gepartitioneerde, gecomprimeerde Parquet en comprimeer kleine bestanden; sla geoptimaliseerde datasets op onder afzonderlijke prefixes voor Athena/Redshift Spectrum.
Maak Athena-werkgroepen aan met limieten voor gescande data per query en dwing werkgroepinstellingen af; activeer hergebruik van queryresultaten en stel een maandelijks budget per werkgroep in.
Migreer batch-ETL naar Glue Flex-jobs voor niet-urgente transformaties, stel maximale DPU-limieten in en plan ze tijdens daluren; behoud een kleinere standaard Glue-vloot voor urgente jobs.
Right-size Redshift: koop 1-jarige Reserved Nodes voor een stabiele basis-compute, verplaats historische data naar S3 en gebruik Spectrum voor incidentele query’s, en activeer concurrency scaling alleen met monitoring.

Rationale: De strategie combineert optimalisatie van dataformaat en lifecycle (wat opslag- en scankosten verlaagt), serverless, goedkopere uitvoering voor flexibele jobs (Glue Flex), query governance (Athena-werkgroepen), en gereserveerde capaciteit voor aanhoudende compute om kortingen te maximaliseren met behoud van beschikbaarheid en prestaties.

← Monitoring en probleemoplossing van datapipelines · Alle domeinen · Datakwaliteit →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →