Harbinger ExplorerHarbinger
Cloud allgemein

Hybrid-Cloud-Datenarchitektur: Patterns für die reale Welt

Praktischer Leitfaden zu Hybrid-Cloud-Datenarchitekturen — Data-Gravity, Synchronisations-Patterns, Netzwerk-Topologie, Identity-Federation und Migrations-Strategien.

Harbinger Team3. April 20268 Min. LesezeitAktualisiert 14.5.2026
  • hybrid-cloud
  • architecture
  • data-platform
  • networking
  • migration
  • terraform
Inhaltsverzeichnis22 Abschnitte

Hybrid-Cloud-Datenarchitektur: Patterns für die reale Welt

Reine Cloud-Native ist das Ziel. Realität ist chaotischer. Die meisten Enterprises betreiben eine Hybrid-Landschaft: Mainframes, die alle im Raum überleben werden, On-Premise-Datacenter mit regulatorischen Auflagen, und Cloud-Workloads, die schnell wachsen. Hybrid-Cloud-Datenarchitektur ist die Disziplin, das zum Funktionieren zu bringen — zuverlässig, sicher und ohne in operativer Komplexität zu ertrinken.

TL;DR

  • Hybrid ist Dauerzustand, nicht Übergangszustand für viele Enterprises
  • Data-Gravity entscheidet, was sich bewegen lässt — 10 TB Oracle mit 20 Jahren Stored Procedures verschiebst du nicht "mal eben"
  • 5 Kern-Patterns: Cloud-Bursting, Federated Query, Event-Driven Sync, Hybrid Data Mesh, Progressive Migration
  • Netzwerk ist der unterschätzte Teil: VPN reicht oft nicht, Direct-Connect ab 1 TB/Tag
  • DACH-Realität: DSGVO-Datenresidenz, BSI-Vorgaben, AVV mit Cloud-Providern

Warum Hybrid? (Und warum es schwerer ist als es aussieht)

graph TD
    A[On-Premise Datacenter] -->|Latency: 5-50ms| B[Cloud Region]
    A --> A1[ERP / Mainframe]
    A --> A2[Legacy RDBMS]
    A --> A3[Regulatory-bound PII]
    B --> B1[Data Lake / Lakehouse]
    B --> B2[ML Workloads]
    B --> B3[Analytics / BI]
    C[Edge / Branch Offices] -->|Latency: 20-200ms| B
    C --> C1[IoT / Sensors]
    C --> C2[POS / Local Apps]
TreiberHält Daten On-PremiseDrückt Daten in die Cloud
LatenzReal-time OT/IoTBatch-Analytics
RegulierungDSGVO, DatenresidenzDev/Test-Workloads
KostenBestehender CAPEXBurst-Compute
IntegrationLegacy-System-APIsModernes SaaS
SicherheitKlassifizierte DatenNicht-sensitive Workloads

Das Data-Gravity-Problem

Data-Gravity: Daten ziehen Services um sich herum an. Eine 10-TB-On-Premise-Oracle-DB hat Jahrzehnte von Stored Procedures, ETL-Jobs und BI-Tools angedockt. Du kannst sie nicht "mal eben in die Cloud schieben". Hybrid-Architektur respektiert Data-Gravity und verschiebt graduell Value-Add-Workloads cloud-wärts.

Pattern 1: Cloud-Bursting für Analytics

Datenquellen On-Premise lassen, schwere Analytics in der Cloud mit ephemerem Compute laufen lassen. Daten fließen einseitig: On-Prem → Cloud zur Verarbeitung, Resultate zurück.

sequenceDiagram
    participant OP as On-Premise RDBMS
    participant GW as Data Gateway
    participant S3 as Cloud Landing Zone
    participant Spark as Ephemeral Spark Cluster
    participant DW as Cloud Data Warehouse

    OP->>GW: CDC / Batch export
    GW->>S3: Encrypted transfer
    S3->>Spark: Trigger job (event-driven)
    Spark->>Spark: Transform + aggregate
    Spark->>DW: Load results
    DW-->>OP: Sync aggregates back (optional)

Terraform: AWS Site-to-Site VPN für sicheren Transfer

resource "aws_customer_gateway" "on_prem" {
  bgp_asn    = 65000
  ip_address = var.on_prem_public_ip
  type       = "ipsec.1"

  tags = {
    Name = "on-prem-datacenter"
  }
}

resource "aws_vpn_gateway" "cloud" {
  vpc_id = aws_vpc.data_platform.id

  tags = {
    Name = "data-platform-vpn-gw"
  }
}

resource "aws_vpn_connection" "on_prem_to_cloud" {
  vpn_gateway_id      = aws_vpn_gateway.cloud.id
  customer_gateway_id = aws_customer_gateway.on_prem.id
  type                = "ipsec.1"
  static_routes_only  = false

  tunnel1_ike_versions              = ["ikev2"]
  tunnel1_phase1_encryption_algorithms = ["AES256"]
  tunnel1_phase1_integrity_algorithms  = ["SHA2-256"]
  tunnel1_phase2_encryption_algorithms = ["AES256-GCM-16"]
}

AWS DataSync für Bulk-Transfer

# DataSync-Location für On-Premise NFS anlegen
aws datasync create-location-nfs   --server-hostname on-prem-nas.internal   --subdirectory /data/exports   --on-prem-config AgentArns=arn:aws:datasync:us-east-1:123456789:agent/agent-0abc

# S3-Destination anlegen
aws datasync create-location-s3   --s3-bucket-arn arn:aws:s3:::my-platform-bronze   --subdirectory /on-prem-exports   --s3-config BucketAccessRoleArn=arn:aws:iam::123456789:role/DataSyncS3Role

# Transfer-Task anlegen und starten
aws datasync create-task   --source-location-arn arn:aws:datasync:...:location/loc-source   --destination-location-arn arn:aws:datasync:...:location/loc-dest   --name "nightly-export-to-s3"   --options VerifyMode=ONLY_FILES_TRANSFERRED,TransferMode=CHANGED

aws datasync start-task-execution   --task-arn arn:aws:datasync:...:task/task-0abc

Pattern 2: Federated Query

Daten in-place über Cloud und On-Premise hinweg abfragen, ohne sie zu bewegen. Am besten für Ad-hoc-Analytics, wenn Daten-Movement zu langsam oder teuer wäre.

graph LR
    A[User / BI Tool] --> B[Federated Query Engine
Trino / Athena Federation]
    B -->|Query pushdown| C[Cloud S3 Tables]
    B -->|Query pushdown| D[On-Prem PostgreSQL]
    B -->|Query pushdown| E[On-Prem Oracle]
    B -->|Query pushdown| F[Cloud Snowflake]
    B --> A

Trino Federated-Query-Config

# catalog/postgresql.properties (on-prem source)
connector.name=postgresql
connection-url=jdbc:postgresql://on-prem-pg.internal:5432/production
connection-user=${ENV:POSTGRES_USER}
connection-password=${ENV:POSTGRES_PASSWORD}

# catalog/hive.properties (cloud S3)
connector.name=hive
hive.metastore=glue
hive.metastore.glue.region=us-east-1
hive.s3.sse.enabled=true
hive.s3.sse.type=KMS
hive.s3.sse.kms-key-id=alias/data-platform-prod

# catalog/iceberg.properties (cloud lakehouse)
connector.name=iceberg
iceberg.catalog.type=glue
iceberg.file-format=PARQUET

-- Federated Join: Cloud-Aggregate + On-Prem Customer-Master
SELECT
    c.customer_name,
    c.segment,
    s.total_revenue_30d,
    s.order_count_30d
FROM postgresql.public.customers c
JOIN (
    SELECT
        customer_id,
        SUM(amount) AS total_revenue_30d,
        COUNT(*) AS order_count_30d
    FROM hive.gold.daily_order_summary
    WHERE dt >= CURRENT_DATE - INTERVAL '30' DAY
    GROUP BY 1
) s ON c.id = s.customer_id
WHERE c.region = 'EMEA'
ORDER BY s.total_revenue_30d DESC
LIMIT 100;

Pattern 3: Event-Driven Synchronisation

Für bidirektionalen Sync zwischen On-Premise und Cloud: Event-Streaming als Backbone. Beide Seiten publizieren und konsumieren Events; keine ist Master.

graph LR
    subgraph On-Premise
        A[OLTP DB] -->|CDC| B[Kafka On-Prem]
    end
    subgraph Cloud
        D[Cloud Kafka] -->|Replicate| E[Cloud Data Lake]
        E --> F[ML / Analytics]
    end
    B -->|MirrorMaker 2| D
    F -->|Predictions / Enrichments| G[Cloud Kafka Topic]
    G -->|MirrorMaker 2| B
    B -->|Consume| H[On-Prem App Server]

Kafka MirrorMaker 2 Config

# mm2.properties
clusters = on-prem, cloud
on-prem.bootstrap.servers = kafka-on-prem.internal:9092
cloud.bootstrap.servers = kafka-cloud.us-east-1.amazonaws.com:9094

# Replicate on-prem → cloud
on-prem->cloud.enabled = true
on-prem->cloud.topics = orders\..*,inventory\..*,products\..*
on-prem->cloud.topics.blacklist = .*\.internal

# Replicate cloud → on-prem (predictions only)
cloud->on-prem.enabled = true
cloud->on-prem.topics = predictions\..*,enrichments\..*

# Consumer group offset sync
on-prem->cloud.sync.group.offsets.enabled = true
on-prem->cloud.sync.group.offsets.interval.seconds = 60

# Network compression
compression.type = lz4

# Security
on-prem.security.protocol = PLAINTEXT
cloud.security.protocol = SASL_SSL
cloud.sasl.mechanism = AWS_MSK_IAM

Pattern 4: Data Mesh mit hybriden Domains

Ein Data Mesh verteilt Ownership über Domains. In einer Hybrid-Umgebung leben manche Domains natürlich On-Premise (Core Banking, ERP), andere in der Cloud (Analytics, ML).

graph TD
    subgraph On-Premise Domains
        A[Finance Domain
SAP / ERP]
        B[HR Domain
Workday On-Prem]
        C[Manufacturing Domain
SCADA / MES]
    end
    subgraph Cloud Domains
        D[Customer Domain
Cloud CRM]
        E[Marketing Domain
SaaS Stack]
        F[Analytics Domain
Lakehouse]
    end
    G[Data Mesh Governance
Data Catalog + Policy Engine] --> A
    G --> B
    G --> C
    G --> D
    G --> E
    G --> F
    A -->|Data Products| G
    D -->|Data Products| G

Domain-Ownership in Terraform

# Jede Domain hat eigenen AWS-Account + Budget
module "finance_domain" {
  source = "./modules/data-domain"

  domain_name  = "finance"
  account_id   = var.finance_account_id
  data_gravity = "on-premise"  # Primary data stays on-prem

  cloud_resources = {
    s3_landing_bucket = true
    glue_catalog      = true
    athena_workgroup  = true
  }

  data_product_topics = [
    "gl_journal_entries",
    "cost_center_hierarchy",
    "currency_exchange_rates"
  ]
}

module "customer_domain" {
  source = "./modules/data-domain"

  domain_name  = "customer"
  account_id   = var.customer_account_id
  data_gravity = "cloud"  # Primary data in cloud

  cloud_resources = {
    s3_landing_bucket = true
    rds_postgres      = true
    redshift_cluster  = true
  }
}

Pattern 5: Progressive Cloud-Migration

Die "Big-Bang"-Migration scheitert fast immer. Stattdessen: Strangler-Fig-Pattern — Hybrid betreiben und Workloads schrittweise migrieren.

Migrations-Phasen

PhaseDauerWas wandertWas bleibt
1 - Shadow1-3 MonateAnalytics-ReplikasAlle Writes
2 - Read-Migration3-6 MonateBI-Queries → CloudTransaktionale Writes
3 - Write-Migration6-12 MonateNeue App-Writes → CloudLegacy-App-Writes
4 - Cutover1-3 MonateAller TrafficNur Archiv

Dual-Write-Pattern für Phase 3

# Application config: Dual-Write zu beiden Systemen
data_stores:
  primary:
    type: postgresql
    host: on-prem-pg.internal
    database: production
    role: read_write

  secondary:
    type: postgresql
    host: cloud-rds.us-east-1.rds.amazonaws.com
    database: production
    role: read_write
    lag_threshold_ms: 500  # Alert wenn Secondary nachhängt

dual_write:
  enabled: true
  mode: synchronous  # Beide müssen erfolgreich sein
  fallback: primary_only  # Bei Secondary-Failure
  reconciliation_job:
    schedule: "0 */6 * * *"
    alert_on_drift: true

Netzwerk-Architektur für Hybrid-Daten

graph TD
    subgraph On-Premise
        A[Datacenter]
        A1[Private VLAN: 10.0.0.0/8]
    end
    subgraph AWS
        B[VPC: 172.16.0.0/12]
        B1[Private Subnet
172.16.1.0/24]
        B2[Public Subnet
172.16.2.0/24]
    end
    A1 -->|Direct Connect / VPN
1-10 Gbps| B1
    B2 -->|NAT Gateway| C[Internet]
    B1 --> D[VPC Endpoints
S3, KMS, Glue]
    D -.->|No internet egress| C

Bandwidth-Planning

Daten-VolumenTransfer-FrequenzEmpfohlener LinkGeschätzte Kosten
< 100 GB/TagNightly BatchSite-to-Site VPN~50 $/Mo
100 GB - 1 TB/TagStündlichDirect Connect 1G~200 $/Mo
1-10 TB/TagStreamingDirect Connect 10G~600 $/Mo
> 10 TB/TagNear-real-timeDirect Connect 100G + DataSync~2.000 $/Mo

Identity-Federation in Hybrid-Umgebungen

Betreibe nicht zwei Identity-Systeme. Federiere On-Premise AD/LDAP mit Cloud IAM.

# AWS IAM Identity Center (SSO) mit AD-Connector
resource "aws_ssoadmin_instance" "main" {}

resource "aws_identitystore_group" "data_engineers" {
  identity_store_id = tolist(aws_ssoadmin_instance.main.identity_store_ids)[0]
  display_name      = "DataEngineers"
  description       = "Data platform engineers - cloud access"
}

# Permission-Set für Data-Engineers
resource "aws_ssoadmin_permission_set" "data_engineer" {
  instance_arn     = aws_ssoadmin_instance.main.arn
  name             = "DataEngineerAccess"
  session_duration = "PT8H"
}

resource "aws_ssoadmin_managed_policy_attachment" "data_engineer_s3" {
  instance_arn       = aws_ssoadmin_instance.main.arn
  permission_set_arn = aws_ssoadmin_permission_set.data_engineer.arn
  managed_policy_arn = "arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess"
}

Monitoring von Hybrid-Daten-Flows

Observability wird härter, wenn Daten Netzwerk-Grenzen überqueren.

# Cross-Boundary-Transfer-Latenz monitoren
aws cloudwatch get-metric-statistics   --namespace AWS/DataSync   --metric-name BytesTransferred   --dimensions Name=TaskId,Value=task-0abc123   --start-time $(date -u -d '1 hour ago' +%Y-%m-%dT%H:%M:%SZ)   --end-time $(date -u +%Y-%m-%dT%H:%M:%SZ)   --period 300   --statistics Sum

DACH-Spezifika

  • DSGVO-Datenresidenz: Personenbezogene Daten müssen kontrolliert verbleiben (eu-central-1 Frankfurt, eu-west-3 Paris).
  • BSI C5: Cloud-Provider mit BSI-C5-Testat (AWS, Azure, GCP haben diesen) erleichtern Compliance für regulierte Branchen.
  • AVV: Auftragsverarbeitungsverträge mit Cloud-Providern sind Standard — Sub-Auftragsverarbeiter explizit prüfen.

FAQ

Wann lohnt sich Hybrid statt voll Cloud? Wenn 30 %+ deiner Daten regulatorisch On-Prem bleiben müssen, Legacy-Apps mit hohem CAPEX-Investment laufen, oder Latenz-kritische OT/IoT-Workloads existieren.

Was kostet Direct-Connect realistisch? 1-Gbit Port: ~300 €/Monat + Datentransfer (~0,02 €/GB outbound). Für 10-Gbit: ~3.000 €/Monat. ROI vs. VPN ab ~1 TB/Tag.

Wie löst man Identity-Federation pragmatisch? AWS IAM Identity Center, Azure Entra ID oder Google Workspace mit SAML/OIDC-Federation zur On-Prem-AD. Single Sign-On, ein zentrales Berechtigungssystem.

Sind Federated Queries production-grade? Trino und Athena Federation sind solide, aber Query-Latenz hängt vom schwächsten Datasource ab. Für interaktive BI: meist materialisieren. Für Ad-hoc-Analytics: oft ausreichend.

Fazit

Hybrid-Cloud-Datenarchitektur ist kein Übergangszustand — für viele Enterprises ist es das permanente Operating-Model. Design dafür bewusst:

  1. Verstehe Data-Gravity, bevor du entscheidest, was wandert
  2. Nutze Event-Streaming (Kafka + MirrorMaker) für bidirektionalen Sync
  3. Federiere Queries mit Trino/Athena-Federation
  4. Migriere progressiv mit Shadow-Mode und Dual-Write
  5. Federiere Identity — ein IAM für alle
  6. Instrumentiere Cross-Boundary-Flows mit Transfer-Metriken und Freshness-SLOs

Stand: 14. Mai 2026.

H

Geschrieben von

Harbinger Team

Cloud-, Data- und AI-Engineer in DACH. Schreibt seit 2018 über infrastruktur­kritische Tech-Entscheidungen — keine Marketing- Folien, sondern echte Trade-offs aus Production-Workloads.

Mehr über Marchello@harbingerexplorer.com

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.

Weitere Artikel aus Cloud allgemein

Alle Artikel
Cloud·14. Mai 2026

Streaming vs Batch Processing: Wann was nutzen (2026)

Klares Framework für die Wahl zwischen Streaming und Batch — Kafka, Flink, Spark Structured Streaming im Vergleich, mit Code und Entscheidungshilfen.

Cloud·14. Mai 2026

Surrogate vs Natural Keys: Wann was nutzen (2026)

Praktische Aufschlüsselung von Surrogate- und Natural-Keys — Trade-offs, Failure-Modes und wann jeder der richtige Choice für dein Datenmodell ist.

Cloud·14. Mai 2026

Event-Driven Data Architecture mit Kafka und CQRS

Event-Driven Datenarchitektur mit Kafka, Event Sourcing und CQRS — Konzepte, Code-Beispiele in PySpark und ehrliche Trade-offs gegenüber Batch-Pipelines.