Die Wahl zwischen Hyperscaler und eigenem Rechenzentrum ist keine strategische Grundsatzentscheidung. Sie ist einer Architekturentscheidung nachgelagert. Erst wenn feststeht, welche Systeme unabhängig vom Standort betrieben, verlagert oder ersetzt werden können und welche Funktionen vor Ort verfügbar bleiben müssen, lässt sich sinnvoll entscheiden, aus welcher Infrastruktur sie bezogen werden.

Die Plattform allein erzeugt keinen Nutzen. Ein Hyperscaler kann Rechenleistung kurzfristig bereitstellen, Dienste automatisieren und Kapazitäten flexibel anpassen. Diese Vorteile entstehen aber nur, wenn Anwendungen und Betriebsprozesse darauf ausgelegt sind. Der Accelerate State of DevOps Report 2024 von DORA und Google Cloud kommt zu einem entsprechend klaren Ergebnis: Flexible Cloud-Infrastruktur kann die organisatorische Leistung verbessern. Eine Migration in die Cloud, bei der diese Flexibilität nicht genutzt wird, kann dagegen schädlicher sein, als im klassischen Rechenzentrum zu bleiben.

Wer einen bestehenden Server lediglich in eine andere Infrastruktur verschiebt, hat damit noch keine anpassungsfähige Architektur geschaffen. Abhängigkeiten, starre Kapazitäten und schwer veränderbare Betriebsprozesse bleiben erhalten. Hinzu kommen neue Anforderungen an Netzverbindungen, Identitäten und die Kontrolle verteilter Dienste. Die Cloud ist in diesem Fall nur ein anderer Standort für die selbe Konstruktion.

Der kommerzielle Lock-in verliert an Bedeutung

Lange wurde gegen Cloud-Plattformen vor allem mit dem Anbieter-Lock-in argumentiert. Ein Wechsel sei teuer, vertraglich erschwert oder durch hohe Entgelte unattraktiv. Der europäische Data Act greift genau diese Hindernisse auf.

Die Verordnung gilt seit dem 12. September 2025. Anbieter von Datenverarbeitungsdiensten müssen Hindernisse für den Wechsel zu einem anderen Anbieter oder zurück in eine eigene Infrastruktur abbauen. Während des Übergangszeitraums dürfen sie nur Kosten berechnen, die unmittelbar mit dem Wechsel zusammenhängen. Ab dem 12. Januar 2027 sind Wechselentgelte nach Artikel 29 Absatz 1 vollständig untersagt. Die Regeln erfassen nach Darstellung der Bundesnetzagentur zum Anbieterwechsel nach dem Data Actsowohl neue als auch bereits bestehende Verträge.

Damit verschwindet nicht jede Form der Abhängigkeit. Derentscheidende Lock-in liegt künftig aber noch deutlicher dort, wo er technisch schon immer lag: in der eigenen Architektur. Anwendungen können an proprietäre Datenbanken, Identitätsdienste, Schnittstellen oder Automatisierungen gebunden sein. Daten können zwar exportierbar sein, ohne dass die zugehörige Anwendung auf einer anderen Plattform ohne erheblichen Umbau lauffähig wäre. Ein rechtlich möglicher Anbieterwechsel ist deshalb noch kein technisch einfacher Wechsel.

Die zentrale Frage lautet folglich nicht, welcher Anbieter heute als dauerhaft richtige Plattform erscheint. Sie lautet, ob die Umgebung so gebaut ist, dass Dienste ersetzt, verschoben oder vorübergehend parallel betrieben werden können. Wer diese Wechselfähigkeit nicht einplant, erzeugt die stärkste Bindung selbst.

Die Anbieterfrage ist eine Scheindebatte

Sind Anwendungen portabel, Schnittstellen dokumentiert und Daten in nutzbaren Formaten verfügbar, wird der Infrastrukturbetreiber zur Bezugsquelle. Dann kann eine Funktion aus einem Hyperscaler, einem klassischen Rechenzentrum oder aus einer lokalen Umgebung erbracht werden. Entscheidend bleibt, ob Leistung, Verfügbarkeit, Sicherheit und Betriebsmodell zum konkreten Prozess passen.

Aus der Betriebspraxis zeigt sich, dass Migrationen deshalb längst nicht nur in eine Richtung verlaufen. Systeme wechseln aus klassischen Rechenzentren zu Hyperscalern, zwischen verschiedenen Hyperscalern oder zurück in ein Rechenzentrum. Hyperscaler eignen sich besonders dort, wo Kapazitäten kurzfristig verändert werden müssen. Nach unserer Erfahrung liegt ihr Kostenniveau dabei häufig über statischer Infrastruktur. Das ist kein allgemeingültiger Kostenvergleich, sondern ein Grund, Skalierbarkeit nur dort einzukaufen, wo sie tatsächlich genutzt wird.

Dasselbe gilt für die Gegenüberstellung zentraler und lokaler Server. Eine zentrale Umgebung reduziert die Hardware an den einzelnen Standorten und vereinfacht Wartung und Aktualisierung. Gleichzeitig steigt die Abhängigkeit von Netzwerkverbindungen; die zentrale Plattform kann zum gemeinsamen Ausfallpunkt werden und Latenz wirkt sich unmittelbar auf den Normalbetrieb aus. Lokale Systeme bieten kurze Zugriffswege und können einen Standort bei Verbindungsstörungen handlungsfähig halten. Dafür müssen Daten synchronisiert,Hardware an mehreren Orten gepflegt und Änderungen verteilt ausgerollt werden.

Keine dieser Varianten ist für sich die richtige. Die Architektur muss bestimmen, welche Abhängigkeit für den jeweiligen Prozess vertretbar ist.

Hybrid entsteht aus der betrieblichen Restmenge

Die Grenze zwischen zentraler und lokaler Infrastruktur zeigt sich am deutlichsten bei einem Leitungsausfall. Alles, was dann am Standort weiter funktionieren muss, bildet die lokale Restmenge. Sie ergibt sich nicht aus einer Vorliebe für eigene Hardware, sondern aus dem Betriebsprozess und aus regulatorischen oder technischen Bindungen.

In Arztpraxen ist diese Restmenge konkret sichtbar. Die seit Oktober 2025 umzusetzende Fassung der KBV-IT-Sicherheitsrichtlinie enthält erstmals Anforderungen an Cloud-Dienste. Gleichzeitig gelten die Anforderungen aus Anlage 5 für dezentrale Komponenten der Telematikinfrastruktur unabhängig von der Praxisgröße. Die KBV nennt auf ihrer Informationsseite insbesondere Kartenterminals und Konnektoren als Komponenten,die in der Praxis stehen und geschützt werden müssen.

Anlage 5 verlangt unter anderem den Schutz dieser Komponenten vor unberechtigtem physischem Zugriff, die Absicherung der Verbindung zu einem gehosteten Konnektor durch einen VPN-Tunnel sowie die sichere Aufbewahrung der Administrationsdaten. Sie regelt damit ausdrücklich eine Infrastruktur, die zumindest teilweise physisch oder funktional an den Standort gebunden bleibt.

Kartenlesegerät, Konnektor beziehungsweise TI-Gateway und die zugehörigen Authentisierungsmittel sind damit kein Argument gegen zentrale Plattformen. Sie markieren die Lücke, die eine rein zentrale Architektur nicht schließen kann. Oberhalb dieser lokalen Restmenge können Anwendungen, Datenverarbeitung und zentrale Dienste dorthin wandern, wo sie am sinnvollsten betrieben werden. Voraussetzung ist, dass der Ausfall der Verbindung nicht unkontrolliert den gesamten Standort stilllegt.

Hybrid ist deshalb kein halbherziger Kompromiss zwischen Cloud und eigenem Rechenzentrum. Es ist die Konsequenz einer sauberen Trennung: lokal bleibt, was physisch gebunden oder für den autonomen Standortbetrieb erforderlich ist; zentrale Funktionen werden dort bezogen, wo Betrieb,Skalierung und Austauschbarkeit am besten zusammenpassen.

Die belastbare Entscheidung lautet daher nicht „Hyperscalermoder Rechenzentrum“. Sie lautet: Welche Funktionen müssen am Standort verfügbar bleiben, welche dürfen von der Verbindung abhängen und wie wird verhindert,dass eine Plattform technisch unverzichtbar wird? Ist das beantwortet, ergibt sich die Bezugsquelle aus der Architektur.

‍

FAQ: Hyperscaler oder eigenes Rechenzentrum

Bedeutet Wechselfähigkeit, dass jede Anwendung jederzeit verschoben werden können muss?

Nein. Vollständige Portabilität ist nicht für jede Anwendung wirtschaftlich oder technisch sinnvoll. Entscheidend ist, Bindungen bewusst zu wählen, Datenzugriff und Schnittstellen zu dokumentieren und für geschäftskritische Dienste einen realistischen Wechselpfad vorzusehen.

Macht der Data Act einen Anbieterwechsel automatisch einfach?

Nein. Der DataAct reduziert vertragliche und finanzielle Hindernisse und verpflichtet Anbieter zur Unterstützung von Wechselprozessen. Er beseitigt jedoch keine selbst geschaffenen technischen Abhängigkeiten innerhalb einer Anwendung oder Betriebsarchitektur.

Ist eine hybride Architektur grundsätzlich ausfallsicherer?

Nicht automatisch. Sie kann die Folgen eines Leitungs- oder Plattformausfalls begrenzen, erhöht aber die Zahl der Übergänge, Systeme und Synchronisationsprozesse. Ausfallsicherheit entsteht erst, wenn klar definiert ist, welche Funktionen lokal weiterlaufen, welche Daten dafür benötigt werden und wie der spätere Abgleich erfolgt.

Wann lohnt sich ein Hyperscaler?

Ein Hyperscaler ist besonders sinnvoll, wenn seine Flexibilität tatsächlich genutzt wird, etwa für schwankende Kapazitäten, automatisierte Bereitstellung oder schnell veränderbare Dienste. Wird dagegen nur eine statische Serverumgebung verschoben, entsteht der erwartete Nutzen nicht zwangsläufig; genau vor dieser Migration ohne Nutzung der Cloud-Flexibilität warnt der DORA Report 2024.

Welche Frage sollte vor jeder Infrastrukturentscheidung beantwortet werden?

Zuerst muss feststehen, was bei Ausfall der Standortverbindung weiter funktionieren muss. Aus dieser betrieblichen Restmenge ergeben sich die lokalen Komponenten; erst für die übrigen Funktionen stellt sich die Frage nach Rechenzentrum, Hyperscaler oder einer Kombination daraus.

‍

‍