Zum Hauptinhalt springen

Die große Neukalibrierung: Cloud-Repatriierung, Egress-Ökonomie und hybride Architekturen für 2026

Jahrelang wurde „Cloud First“ wie ein Naturgesetz behandelt: migrieren, standardisieren, schnell vorangehen und den Hyperscaler den Rest erledigen lassen.

Dieser Ansatz hat echte Vorteile gebracht. Besonders dann, wenn Nachfrage unvorhersehbar ist, Teams klein sind und Geschwindigkeit wichtiger ist als Unit Economics. Doch mit zunehmender Reife von Organisationen zeigt sich eine andere Realität: Manche Workloads profitieren nicht davon, Elastizität dauerhaft zu mieten.

Deshalb verschiebt sich die Cloud-Strategie leise von „Cloud First“ zu „Workload Appropriate“. Ein häufig zitierter Indikator: Eine Barclays-CIO-Umfrage, öffentlich von DataBank aufgegriffen, zeigt, dass 86 Prozent der Enterprise-CIOs planen, zumindest einen Teil ihrer Workloads zurück auf private Infrastruktur oder On-Premises zu verlagern.

Das ist keine Anti-Cloud-Bewegung. Das ist die Branche, die erwachsen wird.

TL;DR

  • Cloud-Repatriierung wird normal, keine Ausnahme mehr.
  • Die größte Kostenüberraschung liegt für viele Teams nicht im Compute-Bereich, sondern im Datenverkehr und in Netzwerkkomponenten wie NAT Gateways.
  • Das „Hidden Tax“-Muster: Je nach Traffic-Pfad zahlen Sie sowohl für Data Transfer Out als auch pro GB für NAT-Verarbeitung.
  • Die pragmatischste Architektur für 2026 ist Hybrid Edge: Cloud-native Services dort behalten, wo sie stark sind, und dedizierte Infrastruktur nutzen, um Bandbreitenökonomie zu kontrollieren und Kontrolle zurückzugewinnen.

1) Warum „Cloud First“ bröckelt: das Steady-State-Problem

Cloud ist wie ein Versicherungsprodukt bepreist. Sie zahlen eine Prämie für Optionalität. Sofortige Skalierung. Managed Services. Globale Reichweite. Diese Prämie lohnt sich bei Spitzenlast oder unsicherer Nutzung.

Aber viele Workloads sind keine Spitzenlast. Sie sind Steady-State:

  • Kern-Datenbanken
  • Always-on-APIs
  • Kontinuierliches Streaming oder Media Delivery
  • Große Downloads wie Patches, Datensätze oder Backups
  • KI-Inferenz-Services mit vorhersehbarem Traffic

Andreessen Horowitz beschreibt diese Spannung als „Trillion Dollar Paradox“: Cloud kann für Geschwindigkeit hervorragend sein, aber auf Skalenniveau teuer werden. Sie modellieren Repatriierung als potenziellen Weg, einen erheblichen Teil der Cloud-Ausgaben in reifen Unternehmen zu reduzieren.

Die neue Frage lautet nicht “Sollten wir in der Cloud sein?”
Sondern “Welche Workloads verdienen tatsächlich die Cloud-Prämie?”

2) Der Kostenfaktor, den viele Teams unterschätzen: Egress und Netzwerkpfade

Die meisten Cloud-Rechnungen bestehen aus drei Messgrößen:

  1. Compute, wie vCPU, RAM und Managed Runtimes
  2. Storage, wie GB pro Monat, IOPS und Requests
  3. Datenverkehr, wie Egress, Cross-AZ, Inter-Region und Gateways

 

Compute lässt sich oft durch Reservierungen, Rightsizing, Autoscaling und Plattformoptimierung verbessern. Datenbewegung ist schwieriger. Denn sie ist direkt daran gekoppelt, wie Ihre Anwendung Wert liefert.

Die „Hotel California“-Dynamik (einfach erklärt)

Cloud-Ingress ist häufig kostenlos. Cloud-Egress nicht.

AWS enthält in vielen Fällen ein monatliches „Data Transfer Out“-Kontingent von 100 GB, mit Ausnahmen. Danach wird ausgehender Traffic gestaffelt berechnet und variiert je nach Region und Service.

Egress-Berechnungen, die standhalten

Die folgenden Zahlen sind illustrativ. Keine Angebotskalkulation. Keine Vertragskonditionen.

Annahmen (explizit genannt)

  • Es werden dezimale Einheiten verwendet: 1 TB ≈ 1.000 GB, nicht TiB.
  • Es werden illustrative Listenpreise verwendet. Tatsächliche Preise hängen von Region, Service-Pfad wie Internet, CDN oder Private Connectivity, Rabatten und Verträgen ab.

Wie 100 TB pro Monat aussehen können (illustrative Listenpreise)

Basierend auf einem häufig zitierten Staffelmodell, rein als Beispiel:

  • 10.000 GB × 0,09 USD pro GB = 900
  • 40.000 GB × 0,085 USD pro GB = 3.400
  • 50.000 GB × 0,07 USD pro GB = 3.500

Gesamt ≈ 7.800 USD pro Monat

Vor CDNs, Delivery-Services, regionalen Besonderheiten oder Rabattprogrammen.

 

Wie 1 PB pro Monat aussehen können (illustrative Listenpreise)

Gleiches Beispielmodell:

  • Erste 10.000 GB: 900
  • Nächste 40.000 GB: 3.400
  • Nächste 100.000 GB: 7.000
  • Verbleibende 850.000 GB × 0,05 USD pro GB: 42.500

Gesamt ≈ 53.800 USD pro Monat

Ab diesem Punkt kann Egress die gesamte Rechnung dominieren, selbst wenn Compute optimiert ist.

3) Der versteckte Multiplikator: NAT Gateways als GB-Mautstelle

In gängigen VPC-Designs laufen Workloads in privaten Subnetzen. Um das Internet zu erreichen, etwa für Updates, Paketabrufe oder Drittanbieter-APIs, werden sie häufig über ein NAT Gateway geroutet.

Ein entscheidender Punkt: NAT Gateways werden in der Regel bepreist mit:

  • einem Stundentarif
  • einem Verarbeitungsentgelt pro GB

 

Diese pro-GB-Gebühr kann bei Skalierung erheblich werden.

Das Doppel-Meter-Muster, mit wichtiger Nuance

Wenn ausgehender Traffic über folgenden Pfad läuft:

Privates Subnetz → NAT Gateway → Ziel

Dann zahlen Sie die NAT-Verarbeitung für diese Bytes.

Zusätzlich können je nach Ziel und Austrittspunkt aus dem Cloud-Netzwerk weitere Datentransferkosten anfallen:

  • Geht der Traffic ins öffentliche Internet, zahlen Sie unter Umständen sowohl Data Transfer Out als auch NAT-Verarbeitung.
  • Geht der Traffic zu bestimmten Cloud-Services über öffentliche Endpoints, zahlen Sie möglicherweise nicht die klassische Internet-Egress-Gebühr, aber dennoch die NAT-Verarbeitung und gegebenenfalls weitere Transferkosten abhängig vom Pfad.

 

Das ist die „Hidden Tax“, die viele erst auf der Rechnung bemerken: Bytes durch NAT sind gemessene Bytes.

4) Eine praktische Entscheidungslogik für Repatriierung

Repatriierung sollte keine ideologische Entscheidung sein. Sondern Portfoliomanagement.

Starke Kandidaten für Repatriierung oder dedizierte Infrastruktur

  • Vorhersehbare Baseline, konstant hohe Auslastung, 24/7
  • Hoher Outbound-Traffic, bandbreitenintensive Delivery, Downloads oder Media
  • Data Gravity, große persistente Datensätze
  • Strenge Kontrollanforderungen, Auditierbarkeit, Mandantenisolation, bekannte physische Lokation
  • Hohe und dauerhafte CPU- oder I/O-Last ohne Multi-Tenant-Varianz

 

Besser in der Public Cloud belassen

  • Spitzen- oder ereignisgetriebene Last
  • Kurzlebige Jobs wie Batch oder CI/CD
  • Managed Services, die ihren Preis tatsächlich wert sind
  • Globale Produkte, die schnell viele Regionen benötigen

 

Ziel ist nicht, die Cloud zu verlassen.
Ziel ist, die Cloud-Prämie nur dort zu zahlen, wo sie echten Mehrwert bringt.

5) Hybrid Edge: Cloud-Agilität behalten, Bandbreitenökonomie korrigieren

Das effektivste Muster für 2026 ist ein hybrides Design:

  • Die Cloud bleibt Control Plane und Innovationsschicht.
  • Dedizierte Infrastruktur wird zur ökonomischen Schicht für Steady-State und bandbreitenintensive Komponenten.

Hybrid Edge bedeutet: Eine hybride Architektur, in der eine dedizierte Schicht bewusst für die schweren Bytes und Baseline-Workloads eingesetzt wird.

Muster A: Das Egress Gateway (die Bandbreitenökonomie transparent verändern)

Konzept:

  • Applikationslogik in der Cloud belassen (Kubernetes, PaaS, Serverless).
  • Schweres Outbound-Delivery in eine dedizierte Umgebung mit hochkapazitivem Transit verlagern.
  • Cloud ↔ dediziert über Private Connectivity verbinden, zum Beispiel AWS Direct Connect.

 

Warum es funktionieren kann:

  • Direct Connect hat eigene Preiskomponenten (Port-Stunden + Datentransfer). Cloud-Anbieter veröffentlichen diese Preislisten.
  • Die Einsparungen entstehen meist durch eine veränderte Kostenfläche: Wenn Ihr dedizierter Anbieter flachere Bandbreitenökonomie bietet (gebündelter Transit, hohe Portgeschwindigkeiten), reduzieren Sie die „strafende Steigung“ der Internet-DTO-Listenpreise.

 

Wichtiger Realitätscheck (das muss unübersehbar sein):

  • Direct Connect liefert Traffic bis zu Ihrem Direct-Connect-Standort. Es wird nicht automatisch zu „kostenlosem Internet“.
  • Anbieter berechnen DTO über Private Connectivity weiterhin, abhängig von Region und Standort. Es geht nicht um „kostenlos“, sondern um „anderer Pfad + andere Preisliste + anderes nachgelagertes Bandbreitenmodell“.

 

Pattern B: The “Object Storage Offload” (stop paying egress for the heaviest bytes)

Konzept:

  • Compute und Orchestrierung in der Cloud belassen.
  • Große Assets (Videos, große Exporte, Backups, Modellartefakte) aus einem Object Store auf dedizierter Infrastruktur ausliefern, zum Beispiel S3-kompatibler Storage wie MinIO oder Ceph.
  • Die Anwendung stellt signierte URLs zum dedizierten Object Store aus.

 

Warum es funktioniert:

  • Sie entfernen Cloud-Egress für die größten Payloads und behalten die Cloud für das, worin sie stark ist: Orchestrierung, Identity, Automatisierung, Managed Control Planes.

 

Muster C: Baseline auf dediziert, Burst in die Cloud

Konzept:

  • Baseline-Workloads laufen auf dedizierter Infrastruktur (vorhersehbare Kosten).
  • Burst-Kapazität geht bei Bedarf in die Cloud (Prämie nur zahlen, wenn Sie Elastizität nutzen).

 

Das vermeidet den klassischen Fehler: 24/7 für „Elastizitätsversicherung“ zu zahlen.

6) Regulierung und Souveränität: Kontrolle rückt nach oben

Ökonomie ist der lauteste Treiber. Governance der stille Beschleuniger.

DORA macht Resilienz und Third-Party-Aufsicht nicht verhandelbar (für den Finanzsektor)

DORA gilt seit dem 17. Januar 2025. Es ist kein Mandat, die Cloud zu verlassen. Aber es zwingt Finanzunternehmen dazu, operative Resilienz und Third-Party-Risiken ernst zu nehmen.

EU-Regulierungsbehörden haben zudem große Technologieunternehmen als kritische Drittanbieter im Rahmen von DORA eingestuft, darunter AWS, Google Cloud und Microsoft, wie öffentlich Ende 2025 berichtet wurde.

Was das in der Praxis bedeutet: Ihre Infrastrukturstrategie muss belastbare Antworten liefern auf:

  • Exit-Planung
  • Konzentrationsrisiken bei Abhängigkeiten
  • Incident-Resilienz
  • und nachweisbare operative Kontrolle

 

Jurisdiktionsrisiko ist keine Paranoia, sondern rechtliche Struktur

Das US-CLOUD-Act-Regime kann bestimmte Anbieter verpflichten, Daten offenzulegen, die sich in ihrem „possession, custody, or control“ befinden, selbst wenn diese außerhalb der USA gespeichert sind, abhängig vom jeweiligen Fall.

Für EU-Organisationen ist das kein Schlagwort, sondern ein Governance-Input. Die praktische Konsequenz: Eigentümerstruktur, rechtliche Jurisdiktion und Betriebsmodell sind relevant, wenn Sie Infrastruktur unter dem Gesichtspunkt von Souveränität entwerfen.

(Dies ist keine Rechtsberatung. Sprechen Sie mit Ihrer Rechtsabteilung oder externen Beratern für Ihr konkretes Risikomodell.)

 

7) Compliance ist nicht „automatisch höher auf Bare Metal“, sondern „kontrollierbarer“

Es ist verlockend zu behaupten, dedizierte Infrastruktur sei automatisch konformer. Das ist falsch.

Beispiel HIPAA: Die US-HHS-Leitlinien machen klar, dass bei Nutzung eines Cloud-Providers geeignete vertragliche und operative Schutzmaßnahmen erforderlich sind, einschließlich eines BAA, sofern notwendig. Die Organisation bleibt verantwortlich.

Die ehrliche Aussage lautet:

  • Dedizierte Umgebungen können bestimmte Kontrollen leichter nachweisbar machen.

  • Compliance hängt weiterhin von Verträgen, Prozessen und Schutzmaßnahmen ab.

Ehrlichkeit schafft Vertrauen.

8) Ein 30-Tage-Aktionsplan für IT-Verantwortliche

If you want a real “workload appropriate” program (not a vibes-based migration), do this:

1) Teilen Sie Ihre Cloud-Rechnung nach den drei Messgrößen auf

  • compute, storage, Datenverkehr
  • Identifizieren Sie, welche Messgröße mit steigender Nutzung am schnellsten wächst

 

2) Identifizieren Sie Ihre „Egress Cliff“

  • Bestimmen Sie den Punkt, an dem Outbound-Kosten signifikant werden, häufig 20 % oder mehr der Gesamtrechnung bei datenintensiven Anwendungen
  • Modellieren Sie 50 TB, 100 TB, 250 TB und 1 PB Szenarien anhand der veröffentlichten Tarife Ihrer Region sowie aller Rabattprogramme, für die Sie qualifiziert sind

 

3) Prüfen Sie Ihre NAT-Gateway-Exposition

  • Ermitteln Sie, wo private Subnetze große Datenmengen über NAT routen
  • Kalkulieren Sie die Kosten anhand des Preismodells Ihres Anbieters (Stundentarif + Verarbeitung pro GB)

 

4) Wählen Sie eine Workload für einen Hybrid-Edge-Piloten

Wählen Sie die mit der klarsten „Heavy-Bytes“-Grenze:

  • downloads
  • exporte
  • media delivery
  • backups / artefakte

 

5) Planen Sie für Reversibilität

Wenn Sie nicht zurückrollen oder den Anbieter wechseln können, betreiben Sie kein „Smart Hybrid“. Sie schaffen lediglich ein neues Lock-in.

Wo Worldstream in der Hybrid-Edge-Architektur passt (ohne Marketing-Nebel)

Hybrid Edge funktioniert nur, wenn die dedizierte Schicht:

  • vorhersehbar, Single-Tenant und automatisierbar ist
  • gut angebunden ist, mit Low-Latency-Pfaden und Private-Cross-Connect-Optionen
  • in der Lage ist, hohen Outbound-Traffic wirtschaftlich zu bewältigen

 

Worldstreams Rolle in dieser Architektur ist klar: dedizierte Infrastruktur in den Niederlanden als Steady-State- und Bandbreiten-Schicht, integriert mit Ihrer Cloud-Schicht über Private Connectivity und moderne Tooling-Stacks, sodass Sie Cloud-Agilität behalten und gleichzeitig die Messgrößen kontrollieren, die Sie bei Skalierung bestrafen.

(Und ausdrücklich: Die Einsparungen hängen von Ihrem Traffic-Muster, regionalen Preisstrukturen und Ihrem Connectivity-Design ab. Ziel ist es, das Modell ehrlich zu berechnen, bevor Sie irgendetwas verlagern.)

Abschluss: Das Zeitalter von „Cloud Smart“

Das Cloud-Zeitalter endet nicht. Das Dogma schon.

Im Jahr 2026 ist die erfolgreiche Infrastrukturstrategie weder „alles Cloud“ noch „keine Cloud“. Es ist Cloud dort, wo sie ihre Prämie verdient, und dediziert dort, wo Vorhersehbarkeit, Bandbreite und Kontrolle wichtiger sind.

Die Organisationen, die gewinnen, sind nicht die, die die meiste Infrastruktur mieten.
Sondern die, die wissen, was sie mieten, was sie leasen oder besitzen, und was sie miteinander verbinden.

FAQ

Cloud-Repatriierung bedeutet, einige Workloads aus einer Public Cloud wie AWS, Azure oder Google Cloud zurück auf Infrastruktur zu verlagern, die Sie selbst kontrollieren, zum Beispiel dedizierte Server, Private Cloud oder On-Premises.

Sie wird in der Regel durchgeführt, um Steady-State-Kosten zu senken, vorhersehbare Performance zu verbessern oder Anforderungen an Datenkontrolle und Compliance zu erfüllen. Typischerweise handelt es sich um eine selektive Maßnahme, also um bestimmte Workloads, nicht um einen vollständigen Ausstieg.