Cloud-Dateninfrastruktur: Services, Kosten & Migration
Die Cloud hat die Datenarchitektur dauerhaft verändert. On-premise-Dateninfrastruktur, also eigene Server, SAN-Storage, proprietäre Appliances, ist immer häufiger eine Legacy-Entscheidung. Aber Cloud-Dateninfrastruktur ist keine einzelne Sache. Sie ist ein Spektrum aus Services und Trade-offs, das bewusste Architekturentscheidungen erfordert.
Cloud-native Datenservices
Jeder große Cloud-Anbieter bietet einen kompletten Data Stack. Das ist jeweils enthalten:
AWS: S3 (Storage), Glue (ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen →/Katalog), Redshift (Warehouse), Athena (serverless SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen → auf S3), EMR (Spark), SageMaker (ML), Kinesis (Streaming), Lake Formation (Governance).
Google Cloud: GCS (Storage), BigQuery (Warehouse + Lake-Hybrid), Dataflow (Streaming-/Batch-ETL), Vertex AI (ML), Pub/Sub (Messaging), Dataplex (Governance).
Azure: ADLS Gen2 (Storage), Synapse Analytics (Warehouse + Lake), Data Factory (ETL), Azure ML, Event Hubs (Streaming), Microsoft Purview (Governance).
Cloud Data Architecture Patterns
Wissenscheck
1. Was ist laut Lektion die empfohlene praktische Antwort auf die Build-vs.-Buy-Entscheidung?
2. Warum sind offene Tabellenformate (Iceberg, Delta Lake) und offene Compute-Frameworks (Spark) laut Lektion wertvoll?
3. Was ist laut Lektion der häufigste tatsächliche Grund, warum Organisationen am Ende Multi-Cloud-Architekturen betreiben?
4. Wählen Sie ALLE Aussagen, die für das KAUFEN von Anbieter-Datenprodukten sprechen (im Gegensatz zum Bauen).
Wählen Sie alle richtigen Antworten aus.
5. Wählen Sie ALLE korrekten Aussagen über Cloud-Dateninfrastruktur, wie sie in der Lektion dargestellt wird.
Wählen Sie alle richtigen Antworten aus.
Die Build-vs.-Buy-Entscheidung
Jeder CDO steht immer wieder vor dieser Entscheidung: eigene Lösungen bauen oder Produkte von Anbietern kaufen?
Argumente für Buy: Schnelligkeit bis zum Nutzen. Eine Snowflake-Implementierung dauert Wochen, nicht Jahre. Der Anbieter kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →ümmert sich um Infrastruktur, Performance-Tuning und Upgrades. Ihr Team beschäftigt sich mit Datenproblemen, nicht mit Infrastrukturproblemen.
Argumente für Build: Kontrolle. Sie besitzen den Code, das SchemaSchemaEin Schema ist der formale Bauplan, der festlegt, wie Daten in einer Datenbank, einer Datei oder einer Nachricht strukturiert, benannt, typisiert und miteinander verknüpft sind.Vollständige Definition ansehen →, die Optimierung. Kein Vendor Lock-in. Keine Überraschungen bei Per-Query-Pricing. Open Source (Spark, Iceberg, Airflow) gibt Ihnen volle Flexibilität.
Die praktische Antwort: Kaufen Sie die Commodity-Komponenten (Storage, Compute, Orchestrierungs-SaaS), bauen Sie das, was Ihr Geschäft differenziert (proprietäre Datenmodelle, eigene ML-Pipelines, domänenspezifische Features).
Multi-Cloud und cloud-agnostische Architektur
Multi-Cloud klingt attraktiv (kein Vendor Lock-in, Best-of-Breed-Services), bringt aber echte Kosten mit sich: operative Komplexität, Datentransferkosten, Zersplitterung der Team-Skills. Die meisten Organisationen mit Multi-Cloud tun das aus regulatorischen Gründen (Anforderungen an Data Residency) oder als Ergebnis von M&A-Aktivitäten, nicht aus bewusster Entscheidung.
Offene Tabellenformate (Apache Iceberg, Delta Lake) und offene Compute-Frameworks (Apache Spark) reduzieren Lock-in, ohne die Komplexität von Multi-Cloud zu erfordern. Nutzen Sie sie als Absicherung.
Kostenarchitektur in der Cloud
Cloud-Datenkosten sind nicht trivial und werden leicht unterschätzt. Die wichtigsten Kostentreiber:
- Storage: Günstig, skaliert aber mit der Aufbewahrungsdauer. Setzen Sie Lifecycle-Policies um, verschieben Sie Daten nach 90 Tagen in günstigere Tiers, archivieren Sie nach einem Jahr.
- Compute: Die wesentliche variable Kostenposition. Warehouse-Query-Kosten skalieren mit den gescannten Daten. Clustering und Partitionierung reduzieren die gescannten Daten und senken damit direkt die Kosten.
- Egress: Daten zwischen Regionen oder nach on-premise zu bewegen ist teuer. Gestalten Sie die Architektur so, dass regionsübergreifende Datenbewegungen minimal bleiben.
- Tools und Lizenzen: Snowflake, Databricks und ähnliche Tools legen ihr Pricing auf die Cloud-Kosten obendrauf. Modellieren Sie die Gesamtkosten, bevor Sie sich festlegen.
Bei Spotify hat ein dediziertes Team für "Data Platform Cost Optimization" die Cloud-Ausgaben um 30 % gesenkt, ohne Funktionalität zu reduzieren, über Regeln zur Query-Optimierung, Data-Retention-Policies und Compute-Scheduling. Ein CDO, der die Kostenarchitektur nicht verantwortet, verantwortet die Datenplattform nicht wirklich.
Migrationsstrategie: von on-prem in die Cloud
Die meisten CDOs erben ein Stück on-premise-Infrastruktur. Cloud-Migration ist fast immer die richtige Richtung, erfordert aber eine Reihenfolge:
- Bewerten und inventarisieren: Was existiert, was es kostet, was davon abhängt
- Kandidaten mit geringem Risiko identifizieren: historische Daten, Archivdaten, Reporting-Workloads
- Zuerst Lift-and-Shift: Workloads verschieben, bevor sie optimiert werden; der Nachweis, dass die Cloud funktioniert, senkt den organisatorischen Widerstand
- Inkrementell refaktorieren: nach der Stabilisierung auf cloud-native Patterns optimieren
- Schrittweise stilllegen: On-premise erst abschalten, wenn die Cloud-Workloads stabil sind
Vermeiden Sie die Falle, alles gleichzeitig neu zu architektieren. Viele Cloud-Migrationen scheitern nicht an technischer Komplexität, sondern daran, dass der Scope zu ambitioniert ist.
Quizfragen
- Was ist der Hauptgrund, aus dem die meisten Organisationen Multi-Cloud einsetzen?
A) Um Kosten zu senken
B) Aus regulatorischen Gründen oder infolge von M&A
C) Um die Performance zu verbessern
D) Um die Architektur zu vereinfachen
Antwort: B
- Was ist der wichtigste Vorteil offener Tabellenformate wie Apache Iceberg?
A) Sie sind schneller als proprietäre Lösungen
B) Sie senken die Storage-Kosten
C) Sie reduzieren Vendor Lock-in, ohne eine Multi-Cloud-Architektur zu erfordern
D) Sie werden von den Cloud-Anbietern gepflegt
Antwort: C
- Welche Reihenfolge ist in der Cloud-Migrationsstrategie richtig?
A) Zuerst refaktorieren, dann migrieren
B) Alles migrieren und gleichzeitig optimieren
C) Inventarisieren → einfache Fälle migrieren → Lift-and-Shift → refaktorieren → stilllegen
D) On-premise stilllegen, bevor migriert wird
Antwort: C
Was Sie aus dieser Lektion umsetzen
Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.
- Migration in die Cloud: Inventar, Lift-and-Shift, dann schrittweises Refactoring
Verwandte Artikel
Aktuelle Blogartikel, die auf dieser Lektion aufbauen.
- Datalag_tolerance ist jetzt eine Budgetentscheidung, und die meisten Teams haben sie nicht getroffendbt State ist im September 2026 allgemein verfügbar geworden und macht aus „alles nach Zeitplan neu bauen“ ein „nur neu bauen, was sich geändert hat“. Die Einsparungen sind real, aber sie kommen nur an, wenn Sie Modell für Modell entscheiden, wie alt Ihre Daten sein dürfen.
- DataCloud-Datenkosten senken, ohne die Analytics zu ruinierenCloud-Rechnungen für Dateninfrastruktur gehören inzwischen zu den am schnellsten wachsenden Posten in IT-Budgets von Unternehmen, und die meisten Organisationen zahlen zu viel, ohne es zu merken. Dieses Playbook gibt CDOs eine konkrete Abfolge von Maßnahmen, um die Ausgaben deutlich zu senken und die analytische Leistungsfähigkeit zu erhalten.
- DataWarum Ihre Datenarchitektur Sie belügt und was moderne CDOs dagegen tunDie meisten Unternehmen glauben, sie hätten eine Datenarchitektur. Was sie tatsächlich haben, ist eine Ansammlung historischer Zufälle, zusammengehalten von guten Absichten und teurer Middleware. So bauen die CDOs, die Wettbewerbsvorteile neu definieren, anders.