Inhaltsverzeichnis17 Abschnitte
- TL;DR
- Storage-Tiers im Vergleich
- AWS S3 Storage Classes
- GCS Storage Classes
- Azure ADLS Gen2 (Blob Storage Tiers)
- Data-Lake-Zonen-Mapping
- Lifecycle-Policies implementieren
- AWS S3 — Terraform
- GCS — Autoclass (empfohlen)
- Azure ADLS — Lifecycle Management Policy
- Delta-Lake-Compaction und Tiering
- OPTIMIZE und VACUUM
- Transaction-Log-Management
- Kostenmodell
- Continuous Cost Observability
- FAQ
- Zusammenfassung
Object Storage ist billig — bis du Petabytes davon hast. Ab einer gewissen Größe wird Storage ein eigenständiger Kostenblock, und der Default-Ansatz (alles in Standard und Schwamm drüber) fängt an, echtes Geld zu kosten.
Eine vernünftige Tiering-Strategie reduziert die Storage-Kosten eines Data Lakes um 40-70% — ohne Query-Performance für aktive Daten zu opfern. Hier ist die Anleitung für AWS, GCP und Azure.
TL;DR
- Hot bleibt hot: Gold-Zone niemals in IA/Glacier schieben — die Retrieval-Kosten fressen jede Storage-Ersparnis.
- Bronze/Silver: Lifecycle-Rules nach 30/90/365 Tagen.
- GCS Autoclass für unvorhersagbare Zugriffsmuster.
- Delta OPTIMIZE wöchentlich gegen Small-File-Akkumulation.
- DSGVO-Hinweis: EU-Region wählen (eu-central-1 / europe-west3), und bei personenbezogenen Daten Retention im Lifecycle codieren.
Storage-Tiers im Vergleich
Alle drei Hyperscaler bieten mehrere Tiers mit unterschiedlichen Kosten-/Zugriff-Trade-offs:
AWS S3 Storage Classes
| Storage Class | Use Case | Min. Dauer | Retrieval-Kosten | $/GB/Monat (ca.) |
|---|---|---|---|---|
| S3 Standard | Hot, aktive Analytics | Keine | Keine | $0,023 |
| S3 Standard-IA | Warm, wöchentlicher Zugriff | 30 Tage | $0,01/GB | $0,0125 |
| S3 One Zone-IA | Reproduzierbare warme Daten | 30 Tage | $0,01/GB | $0,01 |
| S3 Glacier Instant | Cold, Millisekunden-Retrieval | 90 Tage | $0,03/GB | $0,004 |
| S3 Glacier Flexible | Deep Archive, Stunden-Retrieval | 90 Tage | $0,01/GB + $0,03/GB | $0,0036 |
| S3 Glacier Deep Archive | Langzeit-Compliance | 180 Tage | $0,02/GB | $0,00099 |
EUR-Hinweis: AWS-Preise auf der Website sind USD. Multipliziere ca. mit 0,93 für EUR-Equivalent (Mai 2026).
GCS Storage Classes
| Class | Use Case | Min. Dauer | Latenz |
|---|---|---|---|
| Standard | Hot | Keine | ms |
| Nearline | Monatlicher Zugriff | 30 Tage | ms |
| Coldline | Quartalsweise | 90 Tage | ms |
| Archive | Jährlich | 365 Tage | ms |
Azure ADLS Gen2 (Blob Storage Tiers)
| Tier | Use Case | Min. Dauer | Retrieval |
|---|---|---|---|
| Hot | Häufiger Zugriff | Keine | Niedrige Latenz |
| Cool | Selten (30+ Tage) | 30 Tage | Niedrige Latenz |
| Cold | Rar (90+ Tage) | 90 Tage | Niedrige Latenz |
| Archive | Compliance-Archiv | 180 Tage | Stunden (Rehydration) |
Data-Lake-Zonen-Mapping
Ordne deine Lake-Zonen den Tiers zu:
flowchart LR
subgraph Landing Zone
L[Raw Ingest
Retention: 7 Tage
Tier: Standard]
end
subgraph Bronze
B[Cleaned Raw
Retention: 90 Tage hot
Tier: Standard → IA @ 30d]
end
subgraph Silver
S[Kuratiert / transformiert
Retention: 1 Jahr hot
Tier: Standard → IA @ 90d]
end
subgraph Gold
G[Aggregiert / serving
Retention: 3 Jahre
Tier: Standard immer]
end
subgraph Archive
A[Compliance / Historie
Retention: 7+ Jahre
Tier: Glacier Deep Archive]
end
L --> B --> S --> G
S --> A
B --> A
Kernerkenntnis: Gold-Zone bleibt in Standard — BI-Tools und Data Scientists greifen ständig darauf zu, und Retrieval-Kosten aus IA/Glacier killen schnell jede Ersparnis.
Lifecycle-Policies implementieren
AWS S3 — Terraform
resource "aws_s3_bucket_lifecycle_configuration" "data_lake" {
bucket = aws_s3_bucket.data_lake.id
# Bronze: nach 30 Tagen IA, nach 90 Glacier
rule {
id = "bronze-tiering"
status = "Enabled"
filter {
prefix = "bronze/"
}
transition {
days = 30
storage_class = "STANDARD_IA"
}
transition {
days = 90
storage_class = "GLACIER_INSTANT_RETRIEVAL"
}
expiration {
days = 365
}
}
# Silver: IA nach 90 Tagen, Glacier nach 365
rule {
id = "silver-tiering"
status = "Enabled"
filter {
prefix = "silver/"
}
transition {
days = 90
storage_class = "STANDARD_IA"
}
transition {
days = 365
storage_class = "GLACIER_INSTANT_RETRIEVAL"
}
}
# Archive: sofort Glacier Deep Archive
rule {
id = "archive-deep"
status = "Enabled"
filter {
prefix = "archive/"
}
transition {
days = 1
storage_class = "DEEP_ARCHIVE"
}
noncurrent_version_expiration {
noncurrent_days = 30
}
}
# Landing: nach 7 Tagen löschen
rule {
id = "landing-cleanup"
status = "Enabled"
filter {
prefix = "landing/"
}
expiration {
days = 7
}
}
}
GCS — Autoclass (empfohlen)
GCS Autoclass ist der Low-Ops-Ansatz — Objekte werden automatisch zwischen Tiers verschoben, basierend auf realen Zugriffsmustern:
# Autoclass auf einem GCS-Bucket aktivieren
gcloud storage buckets update gs://company-data-lake-bronze \
--enable-autoclass \
--autoclass-terminal-storage-class=ARCHIVE
# Für Buckets, wo Archive zu aggressiv ist (z. B. Silver):
gcloud storage buckets update gs://company-data-lake-silver \
--enable-autoclass \
--autoclass-terminal-storage-class=NEARLINE
Autoclass passt für Silver und Bronze, wenn die Zugriffsmuster schwer vorhersagbar sind. Für Gold (immer hot) und Archive (immer cold) besser explizite Tiers.
Azure ADLS — Lifecycle Management Policy
resource "azurerm_storage_management_policy" "data_lake" {
storage_account_id = azurerm_storage_account.data_lake.id
rule {
name = "bronze-tiering"
enabled = true
filters {
prefix_match = ["bronze/"]
blob_types = ["blockBlob"]
}
actions {
base_blob {
tier_to_cool_after_days_since_modification_greater_than = 30
tier_to_cold_after_days_since_modification_greater_than = 90
tier_to_archive_after_days_since_modification_greater_than = 365
delete_after_days_since_modification_greater_than = 730
}
}
}
rule {
name = "archive-immediate"
enabled = true
filters {
prefix_match = ["archive/"]
blob_types = ["blockBlob"]
}
actions {
base_blob {
tier_to_archive_after_days_since_modification_greater_than = 1
}
}
}
}
Delta-Lake-Compaction und Tiering
Delta Lake fügt zusätzliche Storage-Kosten-Komplexität hinzu — durch das Transaction Log und Small-File-Akkumulation. Ohne Wartung sammeln Delta-Tabellen tausende kleine Parquet-Files, was sowohl Storage- Kosten als auch Query-Latenz erhöht.
OPTIMIZE und VACUUM
# PySpark / Databricks: Delta-Tabellen-Wartung
from delta.tables import DeltaTable
from pyspark.sql import SparkSession
spark = SparkSession.builder.appName("DeltaMaintenance").getOrCreate()
# OPTIMIZE: kleine Files kompaktieren (Bin-Pack)
delta_table = DeltaTable.forPath(spark, "s3://data-lake/silver/orders/")
delta_table.optimize().executeCompaction()
# Z-ORDER für häufig gefilterte Spalten (verbessert Data-Skipping)
delta_table.optimize().executeZOrderBy("order_date", "customer_id")
# VACUUM: Files älter als Retention-Window entfernen
# Default: 7 Tage; explizit setzen für Compliance
delta_table.vacuum(retentionHours=168) # 7 Tage
OPTIMIZE wöchentlich als Job auf allen Silver- und Gold-Tabellen:
# Databricks Workflow: Weekly Delta Maintenance
name: delta-maintenance-weekly
schedule:
quartz_cron_expression: "0 0 2 ? * SUN"
timezone_id: "UTC"
tasks:
- task_key: optimize_silver
notebook_task:
notebook_path: /ops/delta_maintenance
base_parameters:
zone: silver
z_order_cols: order_date,customer_id
job_cluster_key: maintenance_cluster
clusters:
- job_cluster_key: maintenance_cluster
new_cluster:
spark_version: 14.3.x-scala2.12
node_type_id: m5.xlarge
num_workers: 4
Transaction-Log-Management
Das Delta-Transaction-Log (_delta_log/) enthält pro Transaktion ein
JSON-File. Bei High-Frequency-Tabellen sammeln sich tausende Files:
# Transaction-Log-Größe prüfen
aws s3 ls s3://data-lake/silver/orders/_delta_log/ --recursive | wc -l
# Delta Auto-Checkpoint alle 10 Transaktionen (konfigurierbar)
# Für High-Frequency-Tabellen niedriger setzen:
ALTER TABLE silver.orders SET TBLPROPERTIES (
'delta.checkpointInterval' = '5',
'delta.logRetentionDuration' = 'interval 30 days',
'delta.deletedFileRetentionDuration' = 'interval 7 days'
);
Kostenmodell
Vor dem Tiering: erwartete Einsparungen modellieren.
# Einfacher Storage-Kosten-Rechner
def calculate_tiering_savings(
total_gb: float,
hot_pct: float, # Anteil in Standard
warm_pct: float, # Anteil in IA / Nearline
cold_pct: float, # Anteil in Glacier / Archive
standard_cost: float = 0.023,
ia_cost: float = 0.0125,
glacier_cost: float = 0.004,
retrieval_cost_per_gb: float = 0.01,
monthly_retrieval_gb: float = 0.0
) -> dict:
hot_gb = total_gb * hot_pct
warm_gb = total_gb * warm_pct
cold_gb = total_gb * cold_pct
baseline_cost = total_gb * standard_cost
tiered_cost = (
hot_gb * standard_cost +
warm_gb * ia_cost +
cold_gb * glacier_cost +
monthly_retrieval_gb * retrieval_cost_per_gb
)
savings = baseline_cost - tiered_cost
savings_pct = (savings / baseline_cost) * 100
return {
"baseline_monthly_usd": round(baseline_cost, 2),
"tiered_monthly_usd": round(tiered_cost, 2),
"monthly_savings_usd": round(savings, 2),
"savings_percent": round(savings_pct, 1)
}
# Beispiel: 500-TB-Data-Lake
result = calculate_tiering_savings(
total_gb=500_000,
hot_pct=0.15,
warm_pct=0.35,
cold_pct=0.50,
monthly_retrieval_gb=5_000 # 5 TB warm retrieval/Monat
)
print(result)
# {'baseline_monthly_usd': 11500.0, 'tiered_monthly_usd': 3512.5,
# 'monthly_savings_usd': 7987.5, 'savings_percent': 69.5}
Bei 500 TB spart intelligentes Tiering ca. 8.000 $/Monat. Bei Petabyte-Scale sind das siebenstellige Jahresbudget-Effekte.
Continuous Cost Observability
Storage-Kosten als Teil der Plattform-Hygiene continuous tracken:
- Storage-Größe und Kosten pro Zone (Landing, Bronze, Silver, Gold, Archive) wöchentlich tracken
- Alert, wenn eine Zone schneller wächst als erwartet (Pipeline-Bug schreibt Duplikate)
- Verhältnis der Daten pro Tier tracken — wenn Gold so schnell wächst wie Bronze, läuft was schief
- Glacier-Retrieval-Kosten monitoren — unerwartete Spikes deuten auf Consumer hin, die unbeabsichtigt auf Cold-Data zugreifen
FAQ
Lohnt sich Tiering bei kleinen Data Lakes (< 10 TB)? Selten. Bei 10 TB sind 50% Ersparnis ca. 100 €/Monat — das deckt nicht mal die Engineering-Zeit für die Konfiguration. Tiering wird ab 50-100 TB interessant.
Was passiert mit S3 Intelligent Tiering vs. manuellen Lifecycle- Rules? Intelligent Tiering ist bequemer, kostet aber pro Objekt eine monatliche Monitoring-Gebühr (~0,0025 $/1000 Objekte). Bei vielen kleinen Files frisst das die Ersparnis. Manuelle Rules sind günstiger, wenn du dein Zugriffsmuster kennst.
Wie wirkt sich DSGVO auf Tiering aus? Personenbezogene Daten müssen löschbar sein. Glacier Deep Archive mit 180-Tage-Mindestdauer kann mit DSGVO-Löschpflichten kollidieren. Lösung: Daten vor dem Archive-Tier pseudonymisieren, oder klare Retention-Klassen im Datenkatalog definieren.
Zusammenfassung
Eine gut umgesetzte Tiering-Strategie ist eines der höchsten ROI- Investments im Data-Platform-Engineering:
- Lake-Zonen vor Terraform auf Tiers mappen
- Gold immer hot — Retrieval-Kosten löschen Einsparungen
- GCS Autoclass oder S3 Intelligent-Tiering bei unvorhersagbaren Zugriffsmustern
- Delta OPTIMIZE wöchentlich gegen Small-File-Akkumulation
- Kosten vor und nach modellieren, continuous tracken
Test Harbinger Explorer 7 Tage kostenlos — Storage-Kosten und Tiering-Effizienz über deinen gesamten Data-Lake-Bestand aus einer Übersicht heraus tracken.
Stand: 14. Mai 2026. Cloud-Preise ändern sich — kritische Annahmen direkt bei AWS, GCP und Azure verifizieren.
Geschrieben von
Harbinger Team
Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastrukturkritische Tech-Entscheidungen — keine Marketing- Folien, sondern echte Trade-offs aus Production-Workloads.
Hat dir das geholfen?
Jede Woche ein neuer Artikel über DACH-Cloud, Data und AI — direkt in dein Postfach. Kein Spam, kein Marketing-Sprech.
Kein Spam. 1-Klick-Abmeldung. Datenschutz bei Loops.so.