Entscheidung & Vergleich

Hybrid Cloud: Was in die Cloud gehört und was im eigenen Rechenzentrum bleibt

Im deutschen Mittelstand ist Hybrid kein Übergangszustand, sondern das Zielbild. Was an Maschinen, Kassen oder Laboren hängt, bleibt vor Ort, weil Latenz und Verfügbarkeit dort physikalisch entschieden werden. In die Cloud gehört, was stark schwankt, was schnell wachsen soll und was ohnehin als Dienst eingekauft wird. Teuer wird der Hybridbetrieb erst dann, wenn beide Seiten getrennt verwaltet werden, mit zwei Werkzeugkästen und zwei Mannschaften.

5 Kapitel mit allen Befehlen
Zwei IT-Entscheider vergleichen Plattformoptionen an einem großen Bildschirm
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Zwei Welten, zwei Werkzeugkästen, doppelte Kosten

Die meisten Hybridlandschaften sind nicht geplant worden, sie sind entstanden. Ein Fachbereich hat einen Dienst in der Cloud gebucht, die IT hat eine Verbindung dorthin gelegt, und danach kamen zwei weitere Anwendungen dazu. Was fehlt, ist eine Regel, nach der entschieden wird, wo etwas läuft. Ohne diese Regel wandert alles Neue dorthin, wo gerade der geringste Widerstand ist, und nach zwei Jahren liegen Anwendung, Datenbank und Sicherung an drei verschiedenen Orten, ohne dass jemand das so beschlossen hätte.

Technisch schlägt das zuerst beim Netz auf. Anwendungen, die viele kleine Abfragen gegen eine Datenbank fahren, vertragen keine zusätzlichen Millisekunden. Wird die Anwendung in die Cloud verschoben und die Datenbank bleibt im Rechenzentrum, sinkt der Durchsatz spürbar, ohne dass ein einziges System überlastet wäre. Dazu kommt der Datenverkehr aus der Cloud heraus, der je Gigabyte abgerechnet wird und in keiner Migrationsrechnung steht, weil ihn vorher niemand gemessen hat.

Der teuerste Punkt ist der Betrieb. Wenn die Cloud-Seite mit einem Werkzeug verwaltet wird und das Rechenzentrum mit einem anderen, entstehen zwei Regelwerke für Rechtevergabe, zwei Wege für Aktualisierungen, zwei Überwachungssysteme und zwei Sicherungsstrategien. Das kostet nicht nur Personal, es erzeugt auch Lücken: Ein Server, der in beiden Systemen nicht auftaucht, fällt schlicht durch. Genau solche Server findet man später bei einem Vorfall, und zwar als Einstiegspunkt.

Miniatur-Szene: zwei Plattformen nebeneinander mit unterschiedlichen Cloud-Bausteinen, dazwischen eine Waage

Sechs Fragen vor jeder Aufteilung

  1. 01 Wo liegen die Daten, und wie schnell wachsen sie
  2. 02 Welche Antwortzeit braucht die Anwendung wirklich
  3. 03 Woher kommen Anmeldung und Berechtigungen
  4. 04 Wie viel Datenverkehr läuft zwischen beiden Welten
  5. 05 Wer betreibt es, und mit welchem Werkzeug
  6. 06 Was passiert bei unterbrochener Leitung
Was du mitnimmst

Fünf Regeln, nach denen sich die Aufteilung entscheidet

Die Frage ist nicht, ob Cloud oder Rechenzentrum, sondern welche Last nach welchem Kriterium wohin gehört. Diese fünf Regeln decken den größten Teil der Fälle ab.

Der Datenschwerkraft folgen

Rechenleistung zieht zu den Daten, nicht umgekehrt. Liegen mehrere Terabyte im eigenen Speicher und wachsen täglich, ist die Verlagerung der Auswertung in die Cloud teuer und langsam. Umgekehrt gehört alles dorthin, wo die Daten ohnehin entstehen, etwa bei Anwendungen, deren Eingaben aus dem Netz kommen.

Latenz und physische Bindung ernst nehmen

Steuerungen, Kassensysteme, Laborgeräte und Fertigungsanlagen bleiben vor Ort. Für sie zählt nicht Rechenleistung, sondern eine verlässliche Antwortzeit im einstelligen Millisekundenbereich und Betrieb auch bei unterbrochener Leitung. Die Cloud ergänzt hier sinnvoll um Auswertung und Langzeitspeicherung, sie ersetzt die lokale Steuerung nicht.

Identitäten als gemeinsame Klammer

Eine Person, ein Konto, eine Rechtevergabe. In der Praxis heißt das Active Directory im Haus, per Synchronisierung verbunden mit Entra ID, und Zugriffe in beiden Welten über dieselben Gruppen. Zwei getrennte Benutzerverzeichnisse sind der zuverlässigste Weg zu verwaisten Konten, die niemandem mehr auffallen.

Ein Betriebsmodell für beide Seiten

Azure Arc oder der AWS Systems Manager holen Server außerhalb der Cloud in dieselbe Verwaltung, mit denselben Richtlinien, Aktualisierungen und Berichten. Zusammen mit Infrastruktur als Code entsteht daraus ein Werkzeugkasten statt zweier. Das ist der Punkt, an dem Hybridbetrieb billiger wird statt teurer.

Die Rechnung an der Kante prüfen

Kosten entstehen im Hybridbetrieb selten in der Rechenleistung, sondern an der Verbindung: abgehender Datenverkehr, Gateways, doppelt vorgehaltene Kapazität für den Notfall und Lizenzen, die in beiden Welten gezählt werden. Miss den Datenfluss zwischen den Welten, bevor du eine Anwendung teilst.

Tutorial

Von der Einsortierung bis zum geprobten Ausfall der Leitung

Im deutschen Mittelstand ist Hybrid kein Übergangszustand, sondern das Zielbild, und teuer wird es erst, wenn beide Seiten getrennt verwaltet werden, mit zwei Werkzeugkästen und zwei Mannschaften. Deshalb wird hier zuerst einsortiert, was wohin gehört, dann folgen Netzanbindung und gemeinsame Identität. Danach kommt die Verwaltung beider Seiten mit einem Werkzeugkasten und zum Schluss die Kostenmessung samt Probe des Ausfalls, jeweils mit Azure und AWS nebeneinander.

01

Schritt 1: Anwendungen einsortieren, bevor etwas umzieht

Der Fehler am Anfang ist fast immer derselbe: Es wird die Anwendung verschoben, die technisch am einfachsten aussieht, statt der, bei der es sich lohnt. Eine grobe Einsortierung nach vier Merkmalen reicht für die erste Runde.

Wohin welche Last gehört

Art der AnwendungWo sie hingehörtWarum
Steuerung von Anlagen, Kassen, LaborgeräteRechenzentrum oder StandortAntwortzeit und Betrieb bei unterbrochener Leitung entscheiden, nicht Rechenleistung
Datenbank mit hoher AbfragefrequenzBleibt bei der AnwendungJede zusätzliche Millisekunde pro Abfrage multipliziert sich mit der Anzahl der Aufrufe
Testumgebungen und LastspitzenCloudWerden nur zeitweise gebraucht und lassen sich außerhalb der Nutzung abschalten
Auswertung und LangzeitarchivCloud, wenn die Daten dorthin fließenSpeicher ist günstig, aber der Rückweg der Daten kostet je Gigabyte
Standarddienste wie Postfach und ZusammenarbeitCloudEigenbetrieb bindet Personal ohne fachlichen Vorteil gegenüber dem eingekauften Dienst
Alles mit besonderer RechtsbindungEinzelfallprüfungEntscheidend sind Zweck und Rechtsgrundlage, nicht der Speicherort allein

Miss vor jeder Aufteilung den Datenfluss zwischen den Bestandteilen einer Anwendung. Anwendungsserver und Datenbank tauschen oft ein Vielfaches dessen aus, was am Ende beim Benutzer ankommt, und genau dieser Verkehr entscheidet über Antwortzeit und Rechnung. Wenn du die Zahl nicht hast, hilft eine Woche Messung an der Firewall mehr als jede Schätzung. Anwendungen, die sich nicht sauber trennen lassen, ziehen entweder ganz um oder bleiben ganz da, aber sie werden nicht halbiert.

02

Schritt 2: Die beiden Welten verbinden

Für den Anfang reicht fast immer eine verschlüsselte Verbindung über das Internet. Eine dedizierte Leitung lohnt sich erst, wenn Datenmenge, Antwortzeit oder eine zugesicherte Verfügbarkeit es verlangen. Beide Anbieter bieten denselben Aufbau unter anderen Namen.

Azure: Gateway, Gegenstelle und Verbindung
az network vnet-gateway create \
  --name vpngw-hub --resource-group rg-hybrid \
  --vnet vnet-hub --gateway-type Vpn --vpn-type RouteBased \
  --sku VpnGw2AZ --public-ip-address pip-vpngw

az network local-gateway create \
  --name lgw-rechenzentrum --resource-group rg-hybrid \
  --gateway-ip-address 203.0.113.10 \
  --local-address-prefixes 10.10.0.0/16

az network vpn-connection create \
  --name rz-nach-azure --resource-group rg-hybrid \
  --vnet-gateway1 vpngw-hub --local-gateway2 lgw-rechenzentrum \
  --shared-key '<geheimnis>'

Das Gateway braucht ein eigenes Subnetz mit dem festen Namen GatewaySubnet. Plane es großzügig, denn nachträglich vergrößern lässt es sich nur, wenn das Gateway abgebaut wird, und das bedeutet eine Unterbrechung der Verbindung.

AWS: Gegenstelle und Verbindung am Transit Gateway
aws ec2 create-customer-gateway \
  --type ipsec.1 --public-ip 203.0.113.10 --bgp-asn 65000

aws ec2 create-vpn-connection \
  --type ipsec.1 \
  --customer-gateway-id cgw-0a1b2c3d \
  --transit-gateway-id tgw-0f9e8d7c

# Verbindungszustand beider Tunnel pruefen
aws ec2 describe-vpn-connections \
  --query 'VpnConnections[].VgwTelemetry[].{ip:OutsideIpAddress,status:Status}' \
  --output table

AWS baut je Verbindung zwei Tunnel auf. Nutze beide, sonst verlierst du die Redundanz, für die du bezahlst. Auf der eigenen Seite braucht das ein Gerät, das beide Tunnel gleichzeitig hält, und ein Routingprotokoll, das im Fehlerfall umschwenkt.

03

Schritt 3: Identitäten über beide Welten hinweg

Ein Konto, eine Sperrung, eine Rechtevergabe. Alles andere führt dazu, dass ein ausgeschiedener Mitarbeiter auf einer Seite gesperrt ist und auf der anderen weiterarbeiten könnte.

Synchronisierung zwischen Active Directory und Entra ID prüfen
# Zeitplan und letzter Lauf
Get-ADSyncScheduler

# Einzelnen Abgleich anstossen, nur Aenderungen
Start-ADSyncSyncCycle -PolicyType Delta

# Fehler der letzten Laeufe ansehen
Get-ADSyncConnectorRunStatus

# Aus Azure heraus: welche Konten kommen aus dem Verzeichnis
az ad user list --query "[?onPremisesSyncEnabled].{name:displayName, upn:userPrincipalName}" -o table

Der Abgleich läuft standardmäßig alle 30 Minuten. Rechne bei Sperrungen mit dieser Verzögerung und sperre bei einem Austritt zusätzlich die Anmeldesitzungen, sonst bleibt ein bereits ausgestelltes Token noch gültig.

04

Schritt 4: Beide Seiten mit einem Werkzeugkasten verwalten

An diesem Punkt entscheidet sich, ob der Hybridbetrieb billiger oder teurer wird als vorher. Ziel ist, dass ein Server dieselbe Behandlung bekommt, unabhängig davon, in welchem Rechenzentrum er steht.

Server aus dem eigenen Haus in die Cloud-Verwaltung holen
# Azure Arc: Server anbinden
azcmagent connect \
  --resource-group rg-hybrid \
  --tenant-id <mandanten-id> \
  --subscription-id <abo-id> \
  --location westeurope

az connectedmachine list --resource-group rg-hybrid \
  --query '[].{name:name, os:osName, status:status}' -o table

# AWS Systems Manager: welche Server melden sich
aws ssm describe-instance-information \
  --query 'InstanceInformationList[].{id:InstanceId,typ:ResourceType,ping:PingStatus}' \
  --output table

Beide Wege bringen Aktualisierungen, Richtlinienprüfung und Fernzugriff für Server außerhalb der Cloud. Der Aufwand liegt nicht im Agenten, sondern darin, die ausgehenden Verbindungen und Namensauflösung sauber freizugeben.

Beschreibe danach beide Seiten in derselben Sprache. Terraform oder OpenTofu erzeugen nicht nur Ressourcen in der Cloud, sondern sprechen über Anbieter auch mit Virtualisierung, DNS und Ticketsystemen im eigenen Haus. Damit liegt der Soll-Zustand an einer Stelle und ist überprüfbar. Für die Netzanbindung im Detail, also Adressplanung, Routing und Namensauflösung über die Grenze hinweg, geht Rechenzentrum an die Cloud anbinden deutlich tiefer.

05

Schritt 5: Kosten messen und den Notfall proben

Im Hybridbetrieb entstehen Kosten an Stellen, die in keiner Planung stehen. Und die Verbindung zwischen beiden Welten ist ein Ausfallpunkt, den die meisten erst im Ernstfall bewusst wahrnehmen.

Ausgehenden Datenverkehr und Gateways sichtbar machen
# AWS: Kosten der letzten Monate nach Dienst
aws ce get-cost-and-usage \
  --time-period Start=2026-05-01,End=2026-08-01 \
  --granularity MONTHLY --metrics UnblendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Azure: Verbrauch nach Ressourcengruppe
az consumption usage list --start-date 2026-05-01 --end-date 2026-08-01 \
  --query "[].{name:instanceName, kosten:pretaxCost, einheit:currency}" -o table

Achte besonders auf die Posten für abgehende Daten, für NAT-Dienste und für Gateways. Sie tauchen selten in Migrationsrechnungen auf, sind aber im Hybridbetrieb dauerhaft und wachsen mit jeder zusätzlich geteilten Anwendung.

Was vor dem produktiven Hybridbetrieb geprüft sein muss

  • Ausfall der Verbindung einmal bewusst herbeiführenErst dabei zeigt sich, welche Anwendung ohne Gegenseite weiterläuft und welche stehen bleibt. Ein Fertigungsstandort, der ohne Cloud-Anmeldung niemanden mehr einloggen lässt, ist ein Betriebsrisiko, kein Detail.
  • Namensauflösung in beide Richtungen prüfenNamen aus dem eigenen Haus müssen in der Cloud auflösbar sein und umgekehrt. Ohne bedingte Weiterleitung funktioniert die Verbindung auf Netzebene und trotzdem nichts darüber.
  • Sicherung und Wiederherstellung über die Grenze hinweg testenEine Sicherung, die in der Cloud liegt und nur über dieselbe Leitung zurückkommt, ist im Ernstfall entweder zu langsam oder zu teuer. Beides merkt man erst beim ersten echten Rückweg.
  • Lizenzbedingungen für beide Seiten klärenServerlizenzen und Datenbanken werden je nach Vertrag doppelt gezählt, wenn dieselbe Last vorübergehend an beiden Orten läuft. Bestehende Lizenzen lassen sich teilweise anrechnen, aber nur mit Nachweis.
  • Zuständigkeit je System eindeutig benennenWenn beide Mannschaften glauben, die andere kümmere sich, bleibt ein System ungepatcht. Eine Liste mit einem Namen je System verhindert genau die Lücke, die später bei einem Vorfall auffällt.
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Gut zu wissen

Häufige Fragen zu Hybrid Cloud

Noch etwas offen? Wir sind ohne Warteschleife für dich da.

Frag uns direkt
Ab wann lohnt sich eine dedizierte Leitung statt einer VPN-Verbindung?
Der Wechsel lohnt an drei Punkten: wenn regelmäßig große Datenmengen fließen und die Internetleitung dabei an ihre Grenze kommt, wenn die Schwankung der Antwortzeit den Betrieb stört, oder wenn eine zugesicherte Verfügbarkeit vertraglich gefordert ist. Unterhalb dieser Schwellen ist eine verschlüsselte Verbindung über das Internet völlig ausreichend und deutlich schneller eingerichtet. Wichtig ist in beiden Fällen die Redundanz: Eine dedizierte Leitung ohne zweiten Weg ist verfügbarkeitstechnisch schlechter als zwei unabhängige VPN-Tunnel.
Wo fallen im Hybridbetrieb Kosten an, die niemand eingeplant hat?
Fast immer an der Kante zwischen beiden Welten. Abgehender Datenverkehr aus der Cloud wird je Gigabyte abgerechnet, NAT-Dienste und Gateways laufen rund um die Uhr, und für den Notfall vorgehaltene Kapazität wird oft doppelt bezahlt. Dazu kommen Lizenzen, die bei paralleler Nutzung an beiden Orten gezählt werden. Miss deshalb vor der Aufteilung, wie viel Verkehr zwischen den Bestandteilen einer Anwendung tatsächlich fließt. Diese eine Messung verhindert die meisten unangenehmen Überraschungen auf der ersten Rechnung.
Können wir unser Active Directory im eigenen Haus behalten?
Ja, und für die meisten Häuser ist das auch der richtige Weg. Dateifreigaben, Druckdienste, Gruppenrichtlinien und ältere Anwendungen setzen darauf auf und lassen sich nicht kurzfristig ablösen. Die Verbindung entsteht über eine Synchronisierung nach Entra ID, sodass dieselben Konten in beiden Welten gelten. Wichtig ist, hochprivilegierte Konten nicht mitzuspiegeln und für die Cloud eigene Notfallkonten vorzuhalten. Ob und wann sich ein vollständiger Wechsel lohnt, ist eine eigene Entscheidung und hängt vor allem an den verbliebenen Altanwendungen.
Brauchen wir für Hybrid zwei getrennte Betriebsmannschaften?
Nein, und genau daran entscheidet sich die Wirtschaftlichkeit. Wenn Cloud-Seite und Rechenzentrum mit getrennten Werkzeugen, getrennten Regelwerken und getrennten Zuständigkeiten laufen, zahlst du den Betrieb zweimal und bekommst zusätzlich Lücken zwischen den Bereichen. Der bessere Weg ist ein gemeinsamer Werkzeugkasten: Server aus beiden Welten in derselben Verwaltung, Infrastruktur als Code für beide Seiten, eine Überwachung und ein Sicherungskonzept. Dafür muss das Team beide Welten kennen, was die eigentliche Investition ist.
Was ist der Unterschied zwischen Hybrid und Multi-Cloud?
Hybrid verbindet das eigene Rechenzentrum mit einer Public Cloud, Multi-Cloud verbindet mehrere Public Clouds miteinander. Die Fragestellungen überschneiden sich beim Netz und bei den Identitäten, unterscheiden sich aber im Zweck: Hybrid entsteht meist aus physischer Bindung oder rechtlichen Vorgaben, Multi-Cloud aus dem Wunsch nach Unabhängigkeit oder aus Zukäufen. Viele Häuser haben beides gleichzeitig, ohne es so zu nennen. Die Abwägung für den Parallelbetrieb mehrerer Anbieter behandelt die Seite zur Multi-Cloud-Strategie.

Zuletzt geprüft am 26. Juli 2026.

Das sagen Teilnehmer

Echte Stimmen aus unseren IT-Kursen

Sehr kompetenter Dozent der gut auf alle Fragen eingegangen ist.
Rückmeldung aus dem Kurs „Kubernetes Grundkurs“
Erwartungen wurden erfüllt. Angekündigte Themen in hinreichender Tiefe bearbeitet. Zudem gutes Zeitmanagement.
Rückmeldung aus dem Kurs „Source Code Management und CI / CD (DO4)“
Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Cloud-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Aufteilung geklärt, jetzt den Betrieb dahinter aufbauen

Für den hybriden Windows-Betrieb bringen AZ-800 und AZ-801 dein Team auf den Stand, für die Netzanbindung AZ-700 und Networking Essentials for Cloud Applications on AWS. Wer den häufigsten konkreten Hybridfall vor sich hat, findet im Exchange Hybrid Aufbaukurs genau diesen Weg. Sag uns, wie eure Aufteilung aussehen soll, dann stellen wir die passende Reihenfolge zusammen.