Amazon DEA-C01: Kostenoptimierung für Daten-Workloads — Lernleitfaden

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

Teil des Amazon Data Engineer Associate DEA-C01 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Amazon-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Die Kostenoptimierung für Daten-Workloads stellt sicher, dass Speicher-, Rechen- und Datenverarbeitungspipelines einen Mehrwert liefern, ohne dass die Kosten ausufern. Data Engineers müssen die Abfrageleistung, Datendurabilität und Verfügbarkeit gegen Preismodelle abwägen, die je nach Service und Nutzungsmuster variieren. Dieser Bereich erfordert Kenntnisse über Speicherklassen und Lebenszyklusrichtlinien, Kontrollen auf Abfrage- und Cluster-Ebene, Spot- und reservierte Kapazitäten sowie die Abwägung zwischen Serverless- und Provisioned-Modellen.

S3-Speicherkostenoptimierung

S3 Intelligent-Tiering ist die empfohlene Standardeinstellung für Datensätze mit unvorhersehbaren Zugriffsmustern: Aktivieren Sie Intelligent-Tiering über die Konsole oder die AWS CLI, wenn die Zugriffshäufigkeit auf Objekte nicht zuverlässig vorhergesagt werden kann. Konfigurieren Sie Intelligent-Tiering unter Berücksichtigung der anfallenden Gebühr für Überwachung/Automatisierung (es gibt eine geringe monatliche Überwachungsgebühr pro Objekt) und mit der korrekten Mindestanzahl an Tagen für automatische Tier-Übergänge (30 Tage für den Übergang von häufig zu selten genutzten Tiers). Verwenden Sie Objekt-Tags und Lebenszyklusregeln, um kleine Objekte mit hoher Anfragerate auszuschließen, bei denen die Überwachungsgebühren die Einsparungen übersteigen würden.

Nutzen Sie diese operativen Muster, um die S3-Ausgaben zu reduzieren:

Führen Sie eine S3 Storage Class Analysis (Konsole > Management > Analytics oder aws s3control) durch, um Zugriffsmuster auf Präfix-/Tag-Ebene zu identifizieren, bevor Sie Lebenszyklusregeln erstellen.
Konvertieren Sie große historische Datensätze mithilfe von Lebenszyklusübergängen in Archivklassen (Glacier Flexible Retrieval oder Glacier Deep Archive); legen Sie den Zeitpunkt des Lebenszyklusübergangs so fest, dass er den Geschäfts-SLAs entspricht, und vermeiden Sie häufige Expedited-Abrufe.
Fassen Sie viele kleine Objekte (Problem mit kleinen Dateien, „Small-File-Problem“) für analytische Workloads zu größeren Objekten (Parquet-Containerdateien) zusammen, um die Kosten pro Anfrage und pro GET-Anforderung zu senken.

Entscheidungskriterien:

Verwenden Sie Intelligent-Tiering für unvorhersehbare, mäßig abgerufene Datensätze, bei denen der Abrufzeitpunkt flexibel ist.
Verwenden Sie Standard-IA oder One Zone-IA für selten abgerufene, aber schnell verfügbare Daten mit vorhersagbaren Abrufen.
Verwenden Sie Glacier Standard/Bulk/Deep Archive für die Langzeitarchivierung, bei der Abrufe selten sind und eine Latenz von Minuten bis Stunden toleriert werden kann; bevorzugen Sie Bulk/Standard-Abrufe gegenüber Expedited-Abrufen, um hohe Gebühren zu vermeiden.

Kostenmanagement für Athena und Redshift

Die Kosten für Athena skalieren mit der Menge der gescannten Bytes. Erzwingen Sie Workgroup-Kontrollen (Konsole oder aws athena create-work-group), um Limits für gescannte Daten pro Abfrage und monatliche Budgets pro Workgroup zu implementieren; aktivieren Sie „Enforce workgroup settings“, damit Abfragen, die das Datenlimit pro Abfrage überschreiten, fehlschlagen, anstatt ausgeführt zu werden. Reduzieren Sie die gescannten Bytes, indem Sie Quelldateien in spaltenbasierte komprimierte Formate (Parquet/ORC) konvertieren, nach Datum oder gängigen Filterspalten partitionieren, Predicate Pushdown anwenden und CTAS oder CREATE TABLE AS verwenden, um optimierte Datensätze zu materialisieren. Nutzen Sie die Wiederverwendung von Abfrageergebnissen und die Isolierung von Workloads in separaten Workgroups, um Kostenübertragungen zwischen Teams zu vermeiden.

Kostenentscheidungen bei Redshift hängen von der Vorhersehbarkeit des Workloads und der Wahl des Speichers ab. Für eine stabile, vorhersagbare Nutzung der Data-Warehouse-Rechenleistung kaufen Sie Reserved Nodes (Laufzeiten von einem oder drei Jahren, Optionen mit teilweiser/vollständiger Vorauszahlung), um sich Rabatte gegenüber On-Demand zu sichern. Für variable Workloads:

Verwenden Sie Redshift Serverless oder RA3-Knoten mit Managed Storage, um Rechenleistung und Speicher zu entkoppeln.
Setzen Sie Concurrency Scaling sparsam ein (es verursacht zusätzliche Kosten, bietet aber automatische Skalierung) und überwachen Sie die Credits.

Vergleichspunkte:

Reserved Nodes: Am besten für stabile Langzeit-Cluster; erfordert eine Verpflichtung, bietet aber einen erheblichen Rab

Reservierte Kapazität und Savings Plans für Datendienste

Reservierte Kapazität und Savings Plans werden bei den verschiedenen Datendiensten unterschiedlich angewendet. Für EC2-gestützte Dienste (EMR, selbstverwaltetes HBase, benutzerdefiniertes Hadoop) verwenden Sie EC2 Savings Plans oder Reserved Instances, um die Rechenkosten zu decken; wählen Sie je nach Mobilitätsanforderungen regionale oder zonale Optionen. Redshift unterstützt den Kauf von reservierten Knoten für provisionierte Cluster, um die stündlichen Kosten für vorhersagbare Warehouse-Workloads zu senken. Serverless-Dienste (Glue, Athena) haben keine Ressourcenreservierungen; optimieren Sie stattdessen durch die Planung von Workloads und Änderungen am Datenformat.

Praktische Anleitung zum Kauf:

Kaufen Sie Redshift Reserved Nodes für Data-Warehouse-Workloads mit konstantem Zustand und bekannter Auslastung (evaluieren Sie Laufzeiten von 1 vs. 3 Jahren und die Optionen All/Partial/No-Upfront).
Verwenden Sie EC2 Savings Plans, um vorhersagbare Ausgaben für EMR/EC2 über verschiedene Instance-Familien hinweg abzudecken; Savings Plans bieten Flexibilität bei Änderungen der Instance-Familie oder Region.
Kaufen Sie keine Reservierungen für Serverless-Dienste; optimieren Sie stattdessen Nutzungsmuster, Zeitplanung und Datenlayout.

Häufige Fallstricke und Entscheidungskriterien

Athena scannt die gesamte Tabelle ohne Partitionierung – partitionieren Sie große Zeitreihentabellen immer nach Datum oder anderen Spalten mit hoher Kardinalität, nach denen häufig gefiltert wird, und konvertieren Sie sie in Parquet/ORC, um die gescannten Bytes zu minimieren.
Das Auto-Scaling von Glue-DPUs kann zu einer Überprovisionierung führen – legen Sie eine maximale DPU-Obergrenze in der Job-Konfiguration fest (Konsole oder

undefined

) und wählen Sie geeignete Worker-Typen, um die Kosten vorhersagbar zu halten.

Abrufgebühren bei S3 Glacier – vermeiden Sie den „Expedited“-Abruf, es sei denn, er ist geschäftskritisch; planen Sie den „Standard“- oder „Bulk“-Abruf und legen Sie Lebenszyklus-Übergänge mit realistischen SLAs fest.
EMR Master- und Core-Knoten sollten keine Spot-Instances verwenden – konfigurieren Sie Master/Core als On-Demand und weisen Sie Spot nur Task-Knoten zu, bei denen der HDFS-Zustand vermieden oder repliziert wird.
Viele kleine S3-Objekte treiben die Anforderungskosten in die Höhe und verlangsamen die Analyse – fassen Sie kleine Dateien während der Erfassung (Ingestion) zu größeren, spaltenbasierten Dateien zusammen.
Eine übermäßige Abhängigkeit von Concurrency Scaling oder ungesteuertem Auto-Scaling kann die stündlichen Kosten erhöhen – überwachen Sie Skalierungsmetriken, setzen Sie Limits und nutzen Sie reservierte Kapazität, wenn Workloads vorhersagbar sind.

Praktisches Problem: Kostenreduzierung für den nächtlichen ETL-Lauf bei Acme Analytics

Acme Analytics führt nächtliche ETL-Läufe und tägliche Ad-hoc-Analysen durch; die monatlichen Cloud-Ausgaben sind aufgrund des wachsenden Rohdatenspeichers in S3 und der On-Demand-Stunden von Redshift stark angestiegen. Das Unternehmen benötigt eine Reduzierung um 35 %, ohne die nächtlichen SLAs zu beeinträchtigen.

Führen Sie eine S3 Storage Class Analysis durch und erstellen Sie Lebenszyklusregeln, um kalte Rohdaten, die älter als 90 Tage sind, nach Glacier Flexible Retrieval zu verschieben (planen Sie Bulk/Standard-Abrufe).
Konvertieren Sie rohe CSV-Dateien in partitioniertes, komprimiertes Parquet und fassen Sie kleine Dateien zusammen; speichern Sie die optimierten Datensätze unter separaten Präfixen für Athena/Redshift Spectrum.
Erstellen Sie Athena-Arbeitsgruppen (Workgroups) mit Limits für die pro Abfrage gescannten Daten und erzwingen Sie die Arbeitsgruppen-Einstellungen; aktivieren Sie die Wiederverwendung von Abfrageergebnissen und legen Sie ein monatliches Budget pro Arbeitsgruppe fest.
Migrieren Sie Batch-ETL-Prozesse für nicht dringende Transformationen zu Glue Flex-Jobs, legen Sie maximale DPU-Obergrenzen fest und planen Sie deren Ausführung außerhalb der Spitzenzeiten; behalten Sie eine kleinere Standard-Glue-Flotte für dringende Jobs bei.
Passen Sie die Größe von Redshift an (Right-Sizing): Kaufen Sie 1-Jahres-Reserved-Nodes für die konstante Basis-Rechenleistung, verschieben Sie historische Daten nach S3 und verwenden Sie Spectrum für seltene Abfragen, und aktivieren Sie Concurrency Scaling nur mit Überwachung.

Begründung: Die Strategie kombiniert die Optimierung von Datenformat und Lebenszyklus (Reduzierung der Speicher- und Scankosten), eine kostengünstigere Serverless-Ausführung für flexible Jobs (Glue Flex), Query Governance (Athena-Arbeitsgruppen) und reservierte Kapazität für dauerhafte Rechenleistung, um Rabatte zu maximieren und gleichzeitig Verfügbarkeit und Leistung zu erhalten.

← Überwachung und Fehlerbehebung von Datenpipelines · Alle Domänen · Datenqualität →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →