Hybride Cloud-Umgebungen: Ein Leitfaden zu den besten Applikationen, Workloads und Strategien

Die meisten Unternehmen betreiben längst eine hybride Umgebung — nur haben die wenigsten sie so geplant. Sie ist entstanden: Ein Fachbereich hat ein SaaS-Werkzeug eingeführt, ein Entwicklungsteam hat eine neue Anwendung bei einem Public-Cloud-Anbieter gebaut, der Warenwirtschaft steht weiterhin auf dem Server im Serverraum, und die Buchhaltung liegt beim Steuerberater. Das Ergebnis ist eine Landschaft aus vier oder fünf Plattformen, für die es keine gemeinsame Regel gibt.

Ein Leitfaden für hybride Umgebungen fängt deshalb nicht bei der Technik an, sondern bei einer Zuordnung: Welche Anwendung läuft wo, und warum genau dort?

Hybrid und Multi-Cloud sind nicht dasselbe

Die beiden Begriffe werden häufig vermischt. Hybrid bedeutet, dass eigene Infrastruktur — im eigenen Haus oder bei einem Hoster — mit gemieteter Cloud-Infrastruktur zusammenarbeitet. Multi-Cloud bedeutet, dass mehrere Public-Cloud-Anbieter parallel im Einsatz sind.

Der Unterschied ist mehr als Wortklauberei, weil die Probleme verschieden sind. Bei einer hybriden Umgebung geht es um die Verbindung zwischen zwei Welten: Netz, Identitäten, Datenabgleich. Bei Multi-Cloud geht es um doppeltes Know-how — Werkzeuge, Rechteverwaltung, Abrechnungsmodelle und Fehlerbilder unterscheiden sich zwischen den Anbietern erheblich. Wer ein Team, das mit einer Plattform vertraut ist, ohne Weiteres auf eine zweite setzt, unterschätzt das regelmäßig.

Kriterien für die Zuordnung von Workloads

Statt einer Liste „diese Anwendung gehört dorthin“ ist eine Reihe von Fragen brauchbarer, die man je System durchgeht.

Wie sieht das Lastprofil aus? Gleichmäßige, gut vorhersagbare Grundlast ist auf gemieteter oder eigener Hardware meist günstiger. Stark schwankende Last — Kampagnenspitzen, Saisongeschäft, Veranstaltungen — spricht für eine Umgebung, die man kurzfristig hoch- und wieder herunterfahren kann.

Welche Daten verarbeitet das System? Personenbezogene Daten und Geschäftsgeheimnisse verlangen eine bewusste Entscheidung über Standort und Zugriff. Eine Datenklassifizierung, die vor der Migration entsteht, erspart die Diskussion später bei jedem einzelnen Dienst.

Wie viele Daten fließen heraus? Der Transfer aus einer Public Cloud heraus wird abgerechnet, der Transfer hinein in der Regel nicht. Anwendungen, die große Mengen ausliefern oder ständig zwischen zwei Plattformen synchronisieren, werden dadurch überraschend teuer. Das ist der Posten, der in Kalkulationen am häufigsten fehlt.

Wie empfindlich ist die Anwendung gegenüber Latenz? Ein Produktionssystem, das im Millisekundenbereich antworten muss, gehört nah an den Ort, wo die Daten entstehen. Genau darum geht es beim Edge-Computing.

Was kostet die Lizenz wo? Bei Datenbanken und Standardsoftware unterscheiden sich die Lizenzbedingungen je nach Plattform deutlich. Bei älteren Systemen mit prozessorbezogener Lizenzierung kann dieser Posten die Infrastrukturkosten überschreiten.

Woran hängt das System? Eine Anwendung, die täglich mit dem ERP im eigenen Haus spricht, in die Public Cloud zu verschieben, verlagert das Problem nur — dann läuft die Schnittstelle über eine Standleitung, und jede Störung darin trifft beide Systeme.

Cloud-Bursting: in der Theorie elegant

Das gängige Lehrbuchbeispiel lautet: Normale Last läuft in der eigenen Umgebung, Spitzen werden automatisch in die Public Cloud ausgelagert. Das funktioniert, hat aber Voraussetzungen, die selten erfüllt sind. Die Anwendung muss zustandslos sein oder ihren Zustand teilen können, die Daten müssen auf beiden Seiten verfügbar sein, und der Abgleich muss schnell genug laufen, damit die zusätzliche Kapazität rechtzeitig bereitsteht.

In der Praxis ist der einfachere Weg meist, eine klar abgegrenzte Komponente vollständig in die Cloud zu legen — die Bildauslieferung eines Shops, den Suchindex, die Verarbeitung von Uploads — statt eine Anwendung im laufenden Betrieb über zwei Plattformen zu strecken.

Container lösen weniger, als man hofft

Container und Kubernetes gelten als Antwort auf die Frage der Portabilität, und für die Anwendung selbst stimmt das: Ein Image läuft überall dort, wo eine passende Laufzeitumgebung existiert. Was nicht mitwandert, sind die verwalteten Dienste drumherum — die Datenbank, die Warteschlange, der Objektspeicher, die Rechteverwaltung, die Protokollierung. Genau diese Dienste nimmt man in Anspruch, weil man sie nicht selbst betreiben will, und genau sie erzeugen die Bindung an einen Anbieter.

Das ist kein Argument dagegen, sie zu nutzen. Es ist ein Argument dafür, die Entscheidung bewusst zu treffen und zu wissen, welcher Teil der Umgebung im Zweifel neu gebaut werden müsste.

Betrieb: was einheitlich sein muss

Eine hybride Umgebung wird dort unbeherrschbar, wo jede Plattform ihre eigene Verwaltung mitbringt. Drei Dinge sollten deshalb übergreifend funktionieren.

Erstens die Identität: eine zentrale Anmeldung mit zweitem Faktor für alle Systeme, damit Rechte an einer Stelle vergeben und wieder entzogen werden. Zweitens die Überwachung: ein gemeinsamer Ort für Protokolle, Metriken und Alarme statt drei Oberflächen, in die niemand regelmäßig schaut. Drittens die Beschreibung der Infrastruktur als Code, damit nachvollziehbar bleibt, was warum existiert — sonst ist nach zwei Jahren niemand mehr sicher, wofür eine bestimmte Maschine läuft.

Dazu kommt das Backup, und zwar für jede Plattform einzeln. Dass Daten in einer Cloud liegen, heißt nicht, dass sie gesichert sind: Die Anbieter sichern ihre Infrastruktur gegen Ausfall, nicht die eigenen Daten gegen versehentliches Löschen.

Anbieterbindung und Ausstieg

Seit dem 12. September 2025 gilt der EU Data Act. Er verpflichtet Anbieter von Cloud-Diensten unter anderem dazu, den Wechsel zu einem anderen Anbieter vertraglich vorzusehen, darüber vorab zu informieren und ihn technisch zu unterstützen. Gebühren für den Wechsel dürfen übergangsweise nur noch die tatsächlich entstehenden Kosten abdecken und entfallen ab dem 12. Januar 2027 vollständig.

Für hybride Umgebungen ist das relevant, weil der teuerste Teil eines Anbieterwechsels bisher oft die Datenausleitung war. Trotzdem bleibt die Aufgabe bestehen, den Ausstieg technisch vorzubereiten: zu wissen, in welchem Format Daten exportierbar sind, welche Dienste ohne Ersatz sind und wie lange eine vollständige Übertragung dauert.

Selbst machen oder begleiten lassen

Eine Migration in Eigenregie funktioniert gut, wenn die Umgebung überschaubar ist und im Team jemand die Zielplattform wirklich kennt. Sie wird dort schwierig, wo zwei Plattformen zusammengeführt werden sollen und die Erfahrung nur für eine davon vorliegt. Beide Wege sind legitim — was nicht funktioniert, ist die Annahme, Wissen über eine Cloud-Plattform lasse sich ohne Aufwand auf eine andere übertragen.

Wie sich diese Fragen für ein einzelnes Projekt beantworten, hängt vom System ab. Für Websites, Shops und Anwendungen, die wir betreuen, klären wir das im Rahmen der Webentwicklung mit; wenn eine dauerhaft betriebene Umgebung mit fester Zuständigkeit die passendere Antwort ist, steht sie unter SSD-Webhosting. Der grundsätzliche Blick darauf, was heute für und was gegen eine Migration spricht, steht im Beitrag über den Umstieg in die Cloud.

Bild: AWS.com