Die 3 Kern-Cloud-Dienste: Compute, Storage und Networking im Enterprise-Betrieb

Hinter der kaum noch überschaubaren Vielfalt hunderter Produktnamen, proprietärer Datenbank-Dienste und spezialisierter KI-Plattformen der großen US-Hyperscaler verbirgt sich eine nüchterne informationstechnische Realität. Jedes Cloud-System weltweit basiert im Kern auf exakt drei physischen Grundbausteinen: Rechenkapazität (Compute), persistente Datenspeicherung (Storage) und programmierbare Netzwerkkonnektivität (Networking).

Ergänzt wird diese fundamentale Infrastruktur-Triade in der Wirtschaftsinformatik durch die drei bekannten Bereitstellungsmodelle Infrastructure as a Service (IaaS), Platform as a Service (PaaS) und Software as a Service (SaaS). Während IaaS den direkten Zugriff auf virtuelle Server, Speicherblöcke und Software-Defined Networks gewährt, kapselt PaaS die Laufzeitumgebung für Entwicklerteams und SaaS liefert schlüsselfertige Geschäftsanwendungen im Browser.

Für CIOs und Enterprise-Architekten im gehobenen Mittelstand entscheidet die architektonische Trennung dieser Schichten über die langfristige Handlungsfähigkeit des Unternehmens. Wer Compute, Storage und Networking als untrennbares proprietäres Bündel eines einzelnen Cloud-Konzerns bezieht, gibt sowohl die Preiskontrolle als auch die technische Portabilität seiner kritischen Geschäftsprozesse aus der Hand.

Die Ökonomie der Kopplung: Storage Gravity und asymmetrische Netzwerkgebühren

Traditionelle Public-Cloud-Architekturen leiden unter einer gezielten Verschmelzung ihrer drei Basisschichten. Bucht ein Unternehmen virtuelle Compute-Instanzen bei einem globalen Hyperscaler, werden diese fast zwangsläufig an herstellerspezifische Block-Storage-Volumes, proprietäre Objektspeicher-Erweiterungen und geschlossene Virtual Private Clouds (VPC) samt kostenpflichtiger NAT-Gateways gebunden.

Diese enge Verzahnung erzeugt im operativen Betrieb zwei gravierende Klumpenrisiken. Kommt es im zentralen Identitäts-, Routing- oder DNS-Steuerungsdienst einer Hyperscaler-Region zu einer Störung, fallen sämtliche dort verankerten Rechenknoten und Speicherzugriffe gleichzeitig aus, selbst wenn die zugrunde liegende Server-Hardware physisch intakt ist.

Noch schwerer wiegt jedoch die kaufmännische Mechanik, die in der Architekturlehre als Datengravitation (Storage Gravity) bezeichnet wird. Während reine Rechenleistung durch moderne Mehrkern-Prozessoren von AMD EPYC und Intel Xeon im Einkauf kontinuierlich günstiger wird, halten proprietäre Cloud-Anbieter ihre Margen über künstlich verteuerte Speicher-IOPS und ausgehende Bandbreiten-Tarife stabil.

Besonders kritisch zeigt sich diese Abhängigkeit bei vermeintlich preiswerten Archiv- und Cold-Storage-Tarifen. Werden petabytegroße Backup-Bestände ohne lokale Spiegelung in proprietären Cloud-Silos abgelegt, führen gedrosselte Abruf-Bandbreiten und hohe Wiederherstellungsgebühren im Ernstfall nach einem Sicherheitsvorfall zu tagelangen Stillständen. Weiterführende Analysen zur Befreiung aus solchen Infrastruktur-Abhängigkeiten bietet unser Dossier zum strategischen Infrastruktur- und Cloud-Exit.

Ergänzende Architektur-Analysen und technische Entscheidungsmatrizen für Ihre IT-Planung finden Sie in unseren weiterführenden Leitartikeln zu Cloud-Merkmale im Enterprise-Einsatz sowie zu Cloud Services im Enterprise-Einsatz.

Disaggregierte Rechenzentrums-Architektur: Die drei Kern-Dienste technisch entkoppeln

Moderne europäische Enterprise-Rechenzentren überwinden die Grenzen starrer Server-Silos und proprietärer Cloud-Suiten durch eine disaggregierte Architektur. Dabei werden Rechenknoten, Speichersysteme und Netzwerk-Fabrics physisch und logisch so voneinander getrennt, dass jede Ressource unabhängig skaliert, aktualisiert und über offene Protokolle angesprochen werden kann.

Gleichzeitig bildet diese saubere Schichtung auf der IaaS-Ebene das tragfähige Fundament für darüberliegende PaaS-Plattformen wie verwaltete Kubernetes-Umgebungen oder Datenbank-Operatoren sowie für souveräne SaaS-Applikationen. Keine Anwendungsschicht ist mehr an die proprietäre Programmierschnittstelle eines einzelnen Infrastrukturlieferanten gefesselt.

1. Compute-Schicht: Zustandslose KVM-Hypervisoren und OCI-Container

In einer entkoppelten Zielarchitektur wird die Compute-Ebene konsequent zustandslos (stateless) ausgelegt. Physische CPU-Kerne und Arbeitsspeicher (RAM) werden über den im Linux-Kernel verankerten Typ-1-Hypervisor KVM (Kernel-based Virtual Machine), etwa unter Proxmox VE oder OpenStack, sowie über standardisierte Container-Laufzeiten nach Spezifikation der Open Container Initiative (OCI) abstrahiert.

Anstelle herstellerspezifischer Maschinenformate kommen offene Abbilder wie qcow2, RAW und unveränderliche OCI-Container-Images zum Einsatz, die über deklarative Werkzeuge wie Kubernetes oder OpenTofu ausgerollt werden. Da die Compute-Knoten selbst keinerlei persistente Geschäftsdaten auf lokalen Festplatten halten, kann ein defekter Server jederzeit ohne Datenverlust ausgetauscht werden.

Fällt ein physischer Rechenknoten aus oder werden kurzfristig zusätzliche CPU-Kapazitäten für rechenintensive Analysen benötigt, startet der Orchestrator die betroffenen Instanzen binnen Sekunden auf einem beliebigen freien Knoten im Cluster neu. Arbeitslasten lassen sich dadurch frei zwischen eigenen Racks, regionalen Colocation-Standorten und europäischen Cloud-Providern verschieben.

„Architektonische Souveränität entsteht nicht durch den Verzicht auf Cloud-Mechanismen, sondern durch die radikale Entkopplung ihrer drei Grundpfeiler: Wenn Compute zustandslos rechnet, Storage offene S3- und NVMe-oF-Protokolle spricht und das Netzwerk über BGP-EVPN autonom routet, wird jeder Provider jederzeit austauschbar.“

Auch Lizenzkosten lassen sich durch diese Trennung präzise steuern. Datenbank-Cluster, die hohe Einzellizenzgebühren pro Prozessorkern verursachen, erhalten dedizierte Compute-Hosts mit wenigen, hochgetakteten CPU-Kernen, während breit skalierende Web- und Microservice-Workloads auf dicht bestückten Mehrkern-Servern ohne Hypervisor-Strafzuschläge konsolidiert werden.

2. Storage-Schicht: Verteilte NVMe-over-Fabrics und S3-Objektspeicher mit Ceph

Die zweite Säule umfasst die persistente Datenhaltung, die im Enterprise-Betrieb nach drei präzisen Zugriffsmustern gegliedert wird: latenzkritischer Blockspeicher (Block Storage) für relationale Datenbanken und virtuelle Maschinen, verteilter Dateispeicher (File Storage) für gemeinsame POSIX-Verzeichnisse sowie hochskalierbarer Objektspeicher (Object Storage) für unstrukturierte Massendaten, KI-Trainingskorpora und unveränderbare Backups.

Als offener Industriestandard hat sich hierfür Ceph in Verbindung mit modernen Enterprise-NVMe-Laufwerken etabliert. Über das RADOS Block Device (RBD) sowie NVMe-over-Fabrics (NVMe-oF mittels TCP oder RDMA) stellt ein disaggregierter Speicherpool den Compute-Knoten hochverfügbare Block-Volumes mit Latenzen im Sub-Millisekundenbereich bereit, ohne dass proprietäre SAN-Controller benötigt werden.

Parallel dazu präsentiert das Ceph RADOS Gateway (RGW) exakt dieselbe standardisierte S3-REST-API nach außen, die moderne Cloud-native Applikationen erwarten. Unternehmen entwickeln ihre Software durchgängig gegen den S3-Standard, speichern ihre kritischen Datenbestände jedoch frei von Transaktionsgebühren und Egress-Zöllen auf eigener Infrastruktur. Den detaillierten technischen Aufbau beschreiben wir im Leitfaden zur Rechenzentrums-Autarkie mit Ceph und NVMe-over-Fabrics.

3. Networking-Schicht: 100/400-GbE Spine-Leaf-Fabrics, BGP-EVPN und eBPF

Das Rückgrat einer disaggregierten Architektur bildet die dritte Säule: ein hochperformantes, vollständig softwaredefiniertes Netzwerk (SDN). Damit zustandslose Compute-Knoten ohne spürbaren Leistungsverlust über das Netzwerk auf entfernte NVMe-Speicherpools zugreifen können, setzen moderne Rechenzentren auf eine blockierungsfreie Spine-Leaf-Topologie mit 100-GbE- oder 400-GbE-Verbindungen und RDMA over Converged Ethernet (RoCEv2).

Auf der logischen Steuerungsebene entkoppelt das Gespann aus VXLAN (Virtual Extensible LAN nach IETF RFC 7348) und BGP-EVPN (Ethernet VPN) die virtuellen Mandantennetze vollständig von der physischen Verkabelung. IP-Adressräume, Routing-Tabellen und Sicherheitszonen wandern dynamisch mit den Workloads mit, selbst wenn sich diese über mehrere Brandabschnitte oder externe Rechenzentren erstrecken.

Innerhalb containerisierter PaaS-Umgebungen übernimmt Cilium auf Basis der Linux-Kernel-Technologie eBPF (Extended Berkeley Packet Filter) das hochperformante Paket-Routing und die Zero-Trust-Mikrosegmentierung direkt auf Systemaufruf-Ebene, während verschlüsselte WireGuard-Mesh-Tunnel und standardisierte Container-Schnittstellen (CSI für Storage, CNI für Networking) alle drei Schichten nahtlos und herstellerneutral verbinden.

Architektur- und Technologie-Matrix: Monolithischer Hyperscaler versus Disaggregierter Open-Stack

Um im Architekturboard zu bewerten, welche Auswirkungen die Kopplung oder Entkopplung der Kern-Dienste auf Betriebskosten, Latenz und regulatorische Unabhängigkeit hat, müssen sowohl die drei physischen Infrastruktur-Säulen als auch die darüberliegenden Abstraktionsschichten (IaaS/PaaS) systematisch verglichen werden.

Die folgende Bloomberg-Radar-Matrix stellt den proprietär gekoppelten Hyperscaler-Stack einer disaggregierten Enterprise-Architektur auf Basis offener Industriestandards gegenüber:

In datenintensiven Schlüsselbranchen entscheidet diese architektonische Entflechtung unmittelbar über die Wettbewerbsfähigkeit. Medienhäuser und Streaming-Anbieter verteilen petabytegroße Video-Archive direkt aus eigenen Ceph-S3-Clustern über neutrale Internetknoten, während Finanzinstitute im Börsenhandel auf dedizierte KVM- und RoCEv2-Fabrics mit deterministischen Mikrosekunden-Latenzen setzen.

Ebenso profitieren Industrie- und Automobilunternehmen bei der Entwicklung autonomer Fahrfunktionen: Statt Terabytes an Rohtelemetrie aus den Fertigungswerken teuer in eine zentrale Public Cloud hoch- und für die lokale Simulation wieder herunterzuladen, verbleibt der Datenkern in disaggregierten NVMe-oF-Speicherpools am Edge und bindet externe Cloud-GPUs nur bei Spitzenlast als zustandslose Rechenknoten ein.

Vollkostenrechnung über 60 Monate: Integrierter Hyperscaler versus entkoppelter Enterprise-Stack

Wie stark sich die Entkopplung von Compute, Storage und Networking betriebswirtschaftlich auswirkt, zeigt eine reale Vollkostenrechnung (Total Cost of Ownership, TCO) über 60 Monate. Betrachtet wird ein mittelständisches Technologieunternehmen mit einer Dauerlast von 150 produktiven vCPU-Kernen, 512 Gigabyte RAM, 200 Terabyte aktivem Block- und Objektspeicher sowie 30 Terabyte monatlichem ausgehendem Datenverkehr.

Im ersten Szenario (integrierter Hyperscaler-Betrieb) schlagen die reservierten Compute-Instanzen mit monatlich rund 8.500 Euro zu Buche. Für 200 Terabyte redundanten Block- und S3-Speicher inklusive provisionierter IOPS-Transaktionen fallen weitere 6.800 Euro pro Monat an, während Egress-Traffic, Load Balancer und NAT-Gateways monatlich 4.200 Euro kosten.

Damit summiert sich die monatliche Cloud-Rechnung im gekoppelten Modell auf 19.500 Euro. Über den Betrachtungszeitraum von fünf Jahren (60 Monate) fließen exakt 1.170.000 Euro als reiner Betriebsaufwand (OPEX) ab, ohne dass dem Unternehmen am Ende des Zeitraums ein einziger physischer Vermögenswert oder eine portierbare Plattformarchitektur gehört.

Im zweiten Szenario errichtet das Unternehmen einen disaggregierten Open-Source-Stack in einem zertifizierten europäischen Tier-3-Colocation-Rechenzentrum. Die einmalige Anschaffung (CAPEX) von vier redundanten Enterprise-Serverknoten mit AMD-EPYC-Prozessoren, 2 Terabyte ECC-RAM, 100-GbE-RoCEv2-Switchen und schnellen Enterprise-NVMe-Drives für den Ceph-Pool erfordert ein Investitionsbudget von 110.000 Euro.

Hinzu kommen monatlich 2.400 Euro für Rack-Stellfläche, klimatisierten Redundanzstrom und eine ungedrosselte 10-Gbit/s-Internet-Flatrate am neutralen Peering-Knoten ohne jegliche Egress-Volumenberechnung sowie 1.500 Euro monatlich für Hersteller-Subscriptions und Hardware-Wartung. Über 60 Monate liegen die Gesamtkosten bei 344.000 Euro, was einer Netto-Einsparung von 826.000 Euro (über 70 Prozent) entspricht. Vertiefende Kalkulationsmodelle bietet unser 5-Jahres-TCO-Vergleich zwischen Rechenzentrums-Eigenbetrieb und Hyperscalern.

Die Make-or-Buy Sourcing-Weiche und regulatorische Durchsetzung unter dem EU Data Act

Die architektonische Trennung der drei Kern-Dienste bedeutet keineswegs, dass jedes Unternehmen wieder eigene Serverräume im Keller betreiben muss. Vielmehr eröffnet die Standardisierung der Schnittstellen dem CIO eine flexible Make-or-Buy-Sourcing-Weiche, die sich präzise an der vorhandenen Teamstärke orientiert.

Erstens (Eigenbetrieb): Organisationen mit eigenem Linux- und Netzwerk-Engineering betreiben ihren disaggregierten KVM-, Ceph- und BGP-EVPN-Stack auf eigener Hardware in europäischen Colocation-Rechenzentren. Sie profitieren von maximaler Kostendegression ab dem zwölften Betriebsmonat und vollständiger physischer Kontrolle über sämtliche Speicher- und Schlüsselmodule.

Zweitens (Co-Managed): Unternehmen, die von gemeinschaftlich genutzten Infrastruktur-Ressourcen und branchenweiten Referenzarchitekturen profitieren möchten, bündeln ihre Compute- und Storage-Bedarfe in einem föderierten Verbundmodell. Wie solche geteilten Plattformen auf Basis offener Standards rechtssicher organisiert werden, zeigt unser Leitfaden zum Aufbau einer souveränen Community Cloud für regulierte Branchen.

Drittens (Managed Service): Mittelständler mit schlanker IT-Abteilung beziehen Compute, Ceph-Storage und Kubernetes als schlüsselfertig gemanagte IaaS- und PaaS-Dienste von zertifizierten europäischen Cloud-Anbietern. Entscheidend ist hierbei die vertragliche und technische Vorgabe, dass ausschließlich offene Upstream-APIs (S3, CSI, OpenTofu) ohne proprietäre Provider-Erweiterungen zum Einsatz kommen.

Diese architektonische Vorsorge wird durch das europäische Wirtschaftsrecht massiv gestärkt. Mit der europäischen Datenverordnung (EU Data Act, Verordnung (EU) 2023/2854) hat der Gesetzgeber verbindliche Regeln für den Wechsel zwischen Datenverarbeitungsdiensten (Cloud-Switching) geschaffen und die schrittweise Abschaffung von Wechsel- und Egress-Gebühren bis Januar 2027 gesetzlich verankert.

Allerdings nützt der gesetzliche Anspruch auf gebührenfreien Datenabzug wenig, wenn Anwendungen auf PaaS-Ebene so tief mit proprietären Datenbank- oder Netzwerkdiensten eines Hyperscalers verwoben sind, dass ein Umzug einem kompletten Neubau gleicht. Erst die konsequente Trennung nach BSI IT-Grundschutz (SYS.1.1 für Server, APP.4.3 für Datenbankspeicher und NET.1.1 für Netzarchitektur) sowie DORA Artikel 28 macht die gesetzliche Wechselpflicht in der Praxis innerhalb weniger Tage vollziehbar.

Der 4-Phasen-Umsetzungsfahrplan: Vom gekoppelten Cloud-Silo zur disaggregierten Architektur

Die Überführung einer historisch gewachsenen, eng gekoppelten Cloud- oder Virtualisierungslandschaft in einen entkoppelten Drei-Säulen-Stack erfolgt im laufenden Betrieb über vier klar abgegrenzte Phasen. Jede Etappe liefert bereits eigenständige Kostenvorteile und reduziert das Ausfallrisiko.

Phase 1 (Monat 1 bis 2): Schnittstellen-Audit und Abbau proprietärer PaaS-Kopplungen

Zu Beginn inventarisiert das Architektur-Team sämtliche bestehenden Workloads hinsichtlich ihrer Bindung an proprietäre Cloud-Dienste wie AWS EBS, Azure VNet-Gateways oder herstellerspezifische Nachrichtenwarteschlangen. Ziel dieser Phase ist eine verbindliche Entkopplungs-Matrix, die für jede Applikation offene Zielprotokolle (OCI-Container, PostgreSQL, S3-API, Standard-BGP) definiert.

Phase 2 (Monat 3 bis 4): Aufbau des carrier-neutralen Netzwerk-Overlays (Networking)

Bevor Daten oder Server bewegt werden, errichtet das Netzwerk-Team eine providerunabhängige Transport- und Routing-Schicht auf Basis von BGP-EVPN, VXLAN und verschlüsselten WireGuard- oder IPsec-Verbindungen. Durch die Anbindung an neutrale Peering-Knoten können alte und neue Standorte bereits mit stabilen Latenzen und einheitlichen Sicherheitsrichtlinien (Cilium eBPF) miteinander kommunizieren.

Phase 3 (Monat 5 bis 8): Etablierung des disaggregierten Ceph- und NVMe-oF-Speicherpools (Storage)

Im dritten Schritt wird der unabhängige Storage-Cluster über eine redundante 100-GbE-Spine-Leaf-Fabric in Betrieb genommen und per S3-API sowie CSI-Treiber bereitgestellt. Über asynchrone Hintergrund-Replikation fließen Objekt- und Blockdaten schrittweise aus den teuren Hyperscaler-Silos in den eigenen Ceph-Pool ab, sodass die Datengravitation kontrolliert aufgelöst wird.

Phase 4 (Monat 9 bis 12): Umzug der zustandslosen Compute-Workloads und Legacy-Abschaltung

Sobald die Datenbestände im souveränen Speicherpool synchronisiert sind, werden die als OCI-Container oder KVM-Instanzen standardisierten Compute-Workloads in kurzen Wartungsfenstern auf die neuen Rechenknoten umgeschaltet. Anschließend werden die nicht mehr benötigten Hyperscaler-Instanzen, NAT-Gateways und Altverträge sauber gekündigt und zurückgebaut.

Fünf Kontrollfragen für Vorstand und IT-Leitung zur Cloud-Architektur

1. Wie hoch ist der prozentuale Anteil von Storage-IOPS und Netzwerk-Egress an Ihrer aktuellen Cloud-Rechnung?

Lassen Sie sich vom FinOps- oder Einkaufsteam die monatlichen Cloud-Ausgaben strikt getrennt nach reinem Compute, Speicherhaltung (inklusive Snapshot- und IOPS-Aufschlägen) sowie Datenübertragungsgebühren vorlegen. Übersteigen Speicher- und Netzwerkkosten dauerhaft 40 Prozent der Gesamtrechnung, finanziert die Auslagerung in einen disaggregierten Ceph- und Colocation-Stack die eigene Hardware meist binnen 14 Monaten.

2. Können Ihre produktiven Compute-Knoten innerhalb von 15 Minuten auf einem anderen Provider neu gestartet werden?

Prüfen Sie, ob Ihre geschäftskritischen Anwendungen tatsächlich als zustandslose KVM-Images oder OCI-Container vorliegen und über deklarativen Infrastructure-as-Code (etwa OpenTofu und Ansible) bereitgestellt werden. Wenn der Neustart auf einer alternativen Infrastruktur an proprietären IAM-Rollen oder Cloud-spezifischen Startskripten scheitert, besteht ein akuter technischer Lock-in.

3. Unterstützt Ihr Rechenzentrums-Netzwerk verlustfreie 100-GbE-Fabrics für entkoppelten Storage-Traffic?

Eine physische Trennung von Rechen- und Speicherknoten erfordert zwingend ein blockierungsfreies Backend-Netzwerk mit deterministischen Latenzen. Stellen Sie sicher, dass Ihre Switch-Architektur durchgehend 100 GbE (oder mindestens redundante 25 GbE), Jumbo-Frames sowie RoCEv2 und BGP-EVPN beherrscht, damit disaggregierter NVMe-oF-Speicher genauso schnell reagiert wie lokal verbaute Festplatten.

4. Sind sämtliche PaaS-Dienste Ihrer Entwicklerteams über offene CNCF-Standards abstrahiert?

Hinterfragen Sie kritisch den Einsatz proprietärer Serverless-Funktionen und Cloud-Datenbanken, die zwar kurzfristig den Einrichtungsaufwand senken, aber langfristig jede Portabilität unterbinden. Durch den Einsatz standardisierter Kubernetes-Operatoren auf Basis der Cloud Native Computing Foundation (CNCF) bieten Sie Ihren Entwicklern denselben PaaS-Komfort ohne jede Anbieterfessel.

5. Nutzen Ihre Cloud-Verträge bereits aktiv die Kündigungs- und Wechselrechte des EU Data Act?

Beauftragen Sie Ihre Rechtsabteilung gemeinsam mit der IT-Architektur, sämtliche laufenden Cloud-Verträge auf Konformität mit Artikel 23 bis 29 der Verordnung (EU) 2023/2854 zu prüfen. Verankern Sie vertraglich den Wegfall jeglicher Datenexportgebühren sowie die verpflichtende Bereitstellung offener Migrationsschnittstellen innerhalb der gesetzlichen Übergangsfrist von 30 Kalendertagen.

Strategisches Fazit: Wer die drei Grundsäulen trennt, beherrscht die Cloud

Die Komplexität moderner Cloud-Kataloge darf den Blick des Managements nicht für die physikalischen und ökonomischen Grundgesetze der Informationstechnik verstellen. Ob KI-Training, globale Transaktionsdatenbank oder hochverfügbare ERP-Plattform: Jede digitale Wertschöpfung ruht am Ende auf dem präzisen Zusammenspiel von Compute, Storage und Networking.

Unternehmen, die ihre Infrastruktur von der künstlichen Verklammerung proprietärer Hyperscaler befreien und auf eine disaggregierte Architektur mit zustandslosen KVM-/OCI-Rechenknoten, verteiltem Ceph-NVMe-Speicher und offenem BGP-EVPN-Networking umstellen, gewinnen ihre strategische Souveränität zurück. Sie senken ihre Fünfjahreskosten um über 70 Prozent, erfüllen die strengen Nachweispflichten von BSI IT-Grundschutz, DORA und EU Data Act aus dem Design heraus und verwandeln ihre IT-Basis in einen dauerhaft wandlungsfähigen Wettbewerbsvorteil.

Häufig gestellte Fragen (FAQ) zu Compute, Storage und Networking