Hybrid Cloud: Arbeitslasten richtig platzieren und Kosten kontrollieren
5. Mai 2026
Unkontrollierte Datentransferkosten, Latenzprobleme im Produktionsbetrieb oder regulatorische Befunde nach der Inbetriebnahme haben meist dieselbe Ursache: Arbeitslasten wurden ohne klaren Entscheidungsrahmen verteilt.
Das ist kein Einzelfall. Gartner prognostiziert: Bis 2027 betreiben 90 % aller Unternehmen hybride Cloud-Bereitstellungen – und 50 % der kritischen Anwendungen laufen außerhalb zentralisierter öffentlicher Cloud-Standorte. Heterogene Infrastruktur definiert somit das Zielbild moderner Plattformarchitekturen.
Die Frage lautet deshalb nicht mehr „Cloud oder vor Ort?“. Die Frage ist: Welche Arbeitslast gehört wohin – und auf welcher Entscheidungsbasis?
Der Entscheidungsrahmen: Drei Faktoren, klare Reihenfolge
Wer ohne klare Platzierungslogik in hybride Architekturen einsteigt, optimiert im falschen Lösungsraum. Die Reihenfolge ist eindeutig:
Compliance definiert den zulässigen Rahmen. Latenz setzt die physikalischen Grenzen. Kosten optimieren innerhalb dieses Rahmens.
McKinsey schätzt, dass rund 28% der Cloud-Kosten ohne direkten Mehrwert entstehen. Die Ursache liegt selten in der Plattformwahl, sondern in fehlenden Entscheidungen zur Arbeitslastplatzierung im Vorfeld.
-
Compliance: Der Ausgangspunkt
CLOUD Act vs. DSGVO: Was EU-Unternehmen wirklich riskieren
Datenspeicherort beschreibt, wo Daten liegen. Datensouveränität beschreibt, welches Recht darauf zugreift.
Ein Server in Frankfurt, betrieben von einem US-Anbieter, kann weiterhin US-Recht unterliegen. Maßgeblich ist die Konzernstruktur, nicht der Standort des Rechenzentrums. Anbieter wie Amazon Web Services, Microsoft Azure oder Google Cloud können rechtlich verpflichtet werden, auf Daten zuzugreifen – unabhängig davon, wo diese gespeichert sind.
Damit verschiebt sich die Perspektive:
Nicht der Standort entscheidet, sondern die Kontrolle über Zugriff, Plattform und Betrieb.
Für nicht-kritische Szenarien bleibt die Public Cloud ein sinnvoller Baustein. Sobald jedoch personenbezogene oder regulierte Daten betroffen sind, wird Architektur entscheidend. Compliance ist deshalb kein nachgelagerter Prüfschritt. Sie definiert den Lösungsraum von Anfang an.
-
Latenz: Physikalische Realität
Latenz ist kein rein technischer Parameter, den man beliebig optimieren kann. Entfernung, Netzpfade und Auslastung setzen klare Grenzen.
Niedrige Latenzen sind in regionalen Szenarien erreichbar. Entscheidend ist jedoch die Stabilität unter realen Bedingungen. Schwankungen im Netzwerk und Lastspitzen führen dazu, dass einzelne Anfragen deutlich länger benötigen als der Durchschnitt.
Für den Betrieb zählt deshalb nicht der Mittelwert, sondern die tatsächliche Verlässlichkeit im Betrieb. Diese entscheidet darüber, ob eine Arbeitslast zentral oder näher an den Nutzern betrieben werden muss.
-
Kosten (TCO) — Optimierungsdimension, erst wenn der Lösungsraum steht
Kosten sind kein Ausgangspunkt, sondern das Ergebnis der vorherigen Entscheidungen.
Variable Lasten profitieren von elastischen Infrastrukturen. Konstante Lasten mit hohem Datentransfer sind im Eigenbetrieb häufig wirtschaftlicher. Entscheidend ist, dass alle Faktoren berücksichtigt werden: Infrastruktur, Datentransfer, Lizenzen und Betrieb.
Erst wenn Compliance und Latenz geklärt sind, lässt sich eine belastbare Kostenbetrachtung durchführen.
Arbeitslastplatzierung in der Praxis
Arbeitslasten werden nicht nach Cloud-Modellen verteilt, sondern entlang klarer Entscheidungsregeln: regulatorische Anforderungen, Latenz und operative Kontrolle.
Typische Bereitstellungsebenen sind:
- Far Edge: Verarbeitung direkt am Entstehungsort, z. B. in Maschinen oder Fahrzeugen
- Edge: lokale Systeme nahe am Datenursprung mit erweiterter Rechenkapazität
- On-Premises: eigene Infrastruktur mit vollständiger Kontrolle über Betrieb und Daten
- Sovereign Cloud: skalierbare Umgebung unter europäischem Rechtsraum mit definierter Governance
Die Entscheidung folgt dabei einfachen Leitfragen:
| Entscheidungskriterium | Leitfrage | Konsequenz |
| Compliance | Gibt es regulatorische Anforderungen oder personenbezogene Daten? | Verarbeitung nur in kontrollierten Umgebungen |
| Latenz | Sind stabile Reaktionszeiten erforderlich? | Verarbeitung nahe am Entstehungsort |
| Kontrolle | Muss Zugriff, Betrieb und Plattform steuerbar bleiben? | Architektur mit klarer Governance und minimalen Abhängigkeiten |
| Skalierung | Schwankt die Last oder ist kurzfristige Kapazität erforderlich? | Nutzung elastischer Ressourcen innerhalb definierter Rahmenbedingungen |
| Integration | Wie eng ist die Arbeitslast mit bestehenden Systemen verzahnt? | Nähe zu Kernsystemen und stabile Integrationsarchitektur |
Diese Fragen zeigen: Arbeitslasten werden nicht nach Cloud-Modellen verteilt, sondern nach Anforderungen.
Von der Entscheidung zur operativen Umsetzung
Die Platzierungsentscheidung legt fest, wo eine Arbeitslast läuft. Im Betrieb zeigen sich dann die Konsequenzen.
Compliance wird plötzlich zum Audit-Thema. Latenz wird unter Last zum Problem. Kosten tauchen in der Abrechnung auf.
Viele hybride Setups sind fachlich korrekt entworfen – und scheitern genau an diesen Punkten im Alltag.
Die folgenden Aspekte zeigen, wo diese Brüche typischerweise entstehen können:
01 – Compliance ins Architekturprüfverfahren, nicht ins Nachgespräch.
NIS2, DORA und Datensouveränitäts-Anforderungen sind keine Checklisten am Projektende. Wer das nach der Inbetriebnahme klärt, baut zweimal.
02 – Latenz unter realer Last bewerten, nicht als Durchschnitt.
Durchschnittswerte verschleiern die Ausreißer, die den Betrieb tatsächlich stören. Entscheidend ist, wie stabil die Antwortzeiten unter Last bleiben. Das bestimmt, ob eine Arbeitslast zentral betrieben werden kann oder näher am Entstehungsort bleiben muss.
03 – TCO vollständig rechnen.
Datentransferkosten, Lizenzkosten für Managed Services, Betriebspersonal und Redundanzkapazität gehören in jede Eigen-oder-Fremdbezug-Rechnung. Wer das ausgehende Datenvolumen nicht vorab modelliert, liest es im nächsten Abrechnungshinweis.
04 – Beobachtbarkeit über alle Ebenen einbauen, nicht nachrüsten.
Ohne einheitliche Kennzahlen, Protokolle und Ablaufverfolgung über Cloud, Eigenbetrieb und Randschicht ist der hybride Betrieb operativ blind. Ein gemeinsamer Telemetriestandard wie OpenTelemetry verhindert, dass jede Ebene ihr eigenes Überwachungssilo aufbaut – und dass Störungen erst eskalieren, wenn der Schaden sichtbar wird.
05 – Identität ist der neue Perimeter, nicht das Netzwerk.
Zero-Trust auf Basis von Arbeitslast-Identität funktioniert standortunabhängig. Jeder Dienst erhält eine kryptografisch verifizierbare Identität (z.B. via SPIFFE/SPIRE), Kommunikation wird per gegenseitigem TLS abgesichert, Zugriffsrechte auf Basis dieser Identität vergeben – nicht auf Basis von Netzwerksegmenten.
Der Unterschied zwischen einer Hybrid-Architektur, die funktioniert, und einer, die Tickets produziert, liegt genau hier – nicht in der Plattformwahl.
Souveräne Cloud entsteht aus Architekturentscheidungen
Laut Gartner ist die zentrale Herausforderung die Technologieauswahl – es geht darum, Klarheit zu schaffen, welche Arbeitslast wohin gehört. Der strukturelle Rahmen muss stehen, bevor die Plattform gewählt wird.
Wer Arbeitslasten strukturiert platziert, reduziert Komplexität, Kosten und regulatorische Risiken gleichzeitig.
Die Ausgangssituation bleibt immer gleich:
Compliance definiert den Rahmen.
Latenz setzt die Grenzen.
Kosten entstehen daraus.
