WISSEN > GLOBAL FILESYSTEM -> CLOUD & HYBRID STORAGE
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Cloud & Hybrid Storage
Architekturansätze zwischen Rechenzentrum und Cloud
Das sollten Sie mitnehmen:
- Der Datenpfad entscheidet, nicht der Speicherort.
Maßgeblich ist, welche Komponenten für einen erfolgreichen I/O erreichbar sein müssen.
- Ein Cache ist noch kein Leistungsversprechen.
Erst seine Schreibsemantik zeigt, ob eine bestätigte Änderung bereits persistent im Backend liegt.
- Günstige Kapazität ist nicht gleichwertig verfügbare Kapazität.
Ausgelagerte Daten können Rehydrierungszeiten von Stunden erfordern.
- Replikation ersetzt kein Backup.
Eine automatisch replizierte Löschung wirkt auch auf den Kopien.
- Kosten folgen dem Zugriffsmuster.
Requests, Egress und Mindestaufbewahrungsdauern bestimmen das Kostenprofil stärker als die belegte Kapazität.
Cloud & Hybrid Storage
Inhaltsverzeichnis
Cloud Storage verändert eine grundlegende Eigenschaft klassischer Storage-Infrastrukturen: Speicherkapazität muss nicht mehr dort installiert werden, wo sie genutzt wird. Sie kann als externer Dienst bereitgestellt und über ein Netzwerk angesprochen werden.
Daraus folgt jedoch nicht, dass sich lokaler Storage und Cloud Storage technisch wie ein gemeinsamer Speicher verhalten. Sobald Daten Rechenzentrumsgrenzen überschreiten, werden Netzwerk, Datenpfad, Protokoll, Konsistenz, Datenbewegung und Failure Handling zu Bestandteilen der Storage-Architektur. Die entscheidende Frage lautet deshalb nicht, wo die Daten liegen, sondern welchen Weg Daten und Metadaten zwischen Anwendung, lokalem Rechenzentrum und Cloud nehmen – und was geschieht, wenn eine der beteiligten Komponenten nicht erreichbar ist.
- "Hybrid" ist ein Etikett, keine Architektur
- Vor der Architektur steht die Wahl des Zugriffsmodells
- Der direkte Cloud-Zugriff verlagert die Latenz in den Anwendungspfad
- Ein Gateway verlagert Komplexität, statt sie aufzulösen
- Tiering verschiebt das Problem in den Recall
- Replikation erzeugt Kopien, keine Entlastung
- Mehrere Standorte machen den Namespace zum eigentlichen Problem
- Mehr Bandbreite behebt kein Latenzproblem
- Der Cache ist selbst eine zustandsbehaftete Komponente
- Durability schützt weder vor Ausfall noch vor Löschung
- Als Backup-Ziel entscheidet der Restore, nicht das Backup-Fenster
- Das Zugriffsmuster bestimmt die Kosten, nicht die Kapazität
- Datenhoheit endet nicht am Storage-Standort
- Die Architekturmodelle im Vergleich
- Die Anforderung steht vor dem Produkt
- Fazit
- Quellen
"Hybrid" ist ein Etikett, keine Architektur
NIST definiert Cloud Computing unter anderem über On-Demand Self-Service, Broad Network Access, Resource Pooling, Rapid Elasticity und Measured Service. Eine Hybrid Cloud besteht nach derselben Definition aus mindestens zwei eigenständigen Cloud-Infrastrukturen, die technisch so verbunden sind, dass Daten oder Anwendungen zwischen ihnen portiert werden können.
Im Storage-Umfeld wird der Begriff Hybrid Storage deutlich weiter verwendet. Gemeint sind dann auch Architekturen, in denen klassischer On-Premises-Storage mit einem Cloud-Dienst verbunden wird, ohne dass die lokale Seite die NIST-Kriterien einer Cloud erfüllen würde. Für die technische Betrachtung ist deshalb weniger das Etikett entscheidend als die Architektur dahinter. Die gängigen Modelle reichen vom direkten Zugriff einer Anwendung auf Cloud Storage über den Umweg eines lokalen Caches bis hin zu Tiering und Replikation zwischen einem bestehenden System und einem Cloud-Dienst. Sie unterscheiden sich erheblich darin, wann Daten das WAN durchlaufen und welche Komponenten für einen erfolgreichen I/O verfügbar sein müssen.
Vor der Architektur steht die Wahl des Zugriffsmodells
Cloud Storage ist kein einzelner Storage-Typ. Vor jeder Architekturentscheidung muss deshalb geklärt werden, welches Zugriffsmodell die Anwendung überhaupt benötigt.
Block Storage stellt Volumes bereit, während Dateisystem und Datenorganisation oberhalb dieser Ebene liegen. Ein Cloud Block Device ist allerdings nicht automatisch ein über das WAN nutzbares SAN-Volume; üblicherweise wird es innerhalb der Provider-Infrastruktur an dessen Compute-Ressourcen angebunden. File Storage stellt einen hierarchischen Namespace über SMB oder NFS bereit und ist dann relevant, wenn Anwendungen klassische File-System-Semantik erwarten – bei entfernter Bereitstellung mit der Einschränkung, dass jede Protokolloperation über das Netzwerk läuft. Object Storage adressiert Daten als Objekte über APIs, verbreitet über die S3 API; ein Objekt besitzt typischerweise Key, Nutzdaten und Metadaten, weshalb sich File-System-Operationen nicht ohne Weiteres darauf abbilden lassen.
Auch innerhalb von Object Storage lässt sich das Verhalten einer Plattform nicht allein aus der API-Bezeichnung ableiten. Amazon dokumentiert für S3 starke Read-after-Write-Konsistenz für Objektoperationen, während Bucket-Konfigurationen einem Eventual-Consistency-Modell folgen: Ein gelöschter Bucket kann kurzzeitig noch in der Liste erscheinen, und nach erstmaliger Aktivierung von Versioning empfiehlt AWS eine Wartezeit von 15 Minuten vor Schreiboperationen. Google Cloud Storage dokumentiert ebenfalls starke Konsistenz für Object Read-after-Write und Listings, benennt als eventual consistent aber das Gewähren und Entziehen von Zugriffsrechten sowie das Neuanlegen zuvor gelöschter Buckets. S3-Kompatibilität allein beschreibt daher weder sämtliche Funktionen noch sämtliche Semantiken einer Plattform.
Der direkte Cloud-Zugriff verlagert die Latenz in den Anwendungspfad
Das einfachste Modell verzichtet vollständig auf eine lokale Storage-Schicht: Die Anwendung spricht den Cloud-Dienst unmittelbar über das Netzwerk an. Der Vorteil liegt in der geringen Zahl zusätzlicher Infrastrukturkomponenten – Kapazität wird beim Provider bereitgestellt und muss nicht zunächst im eigenen Rechenzentrum installiert, betrieben und erweitert werden.
Technisch entsteht dafür eine direkte Abhängigkeit vom Netzwerkpfad. Jeder I/O, den die Anwendung nicht selbst cacht, muss die Verbindung zum Cloud-Dienst durchlaufen. Damit werden Round Trip Time, verfügbare Bandbreite, Parallelisierung, Request-Größe, die Anzahl der Requests, das Verhalten bei Verbindungsabbrüchen, die Retry-Mechanismen der Anwendung sowie API-Limits zu Faktoren der Storage-Architektur. Anwendungen, die ursprünglich für lokalen File- oder Block-Storage entwickelt wurden, treffen diese Faktoren härter als cloud-nativ entwickelte, die ihre I/O-Architektur gezielt auf Object APIs, Parallelisierung und asynchrone Verarbeitung ausrichten können. Dieser Unterschied lässt sich nachträglich selten durch Infrastrukturmaßnahmen ausgleichen.
Ein Gateway verlagert Komplexität, statt sie aufzulösen
Eine zweite Architektur fügt zwischen Client und Cloud Storage eine lokale Instanz ein. Dieses Gateway kann ein File-Protokoll lokal bereitstellen, während die persistente Datenhaltung im Hintergrund auf Object Storage erfolgt. Aus Sicht des Clients existiert damit ein klassischer File Service über SMB oder NFS, während auf der Backend-Seite eine Object API verwendet wird.
Die technische Komplexität verschwindet dadurch nicht, sie verlagert sich in das Gateway. Dieses muss festlegen, welche Daten lokal gehalten werden, wann Daten in die Cloud übertragen werden, wie Änderungen synchronisiert und Metadaten gespeichert werden, wie Cache Eviction funktioniert, welches Verhalten bei WAN-Ausfall gilt, wie Konflikte behandelt werden – und wann ein Write gegenüber dem Client als abgeschlossen gilt.
Gerade der letzte Punkt entscheidet über das tatsächliche Verhalten der Architektur. Bestätigt ein System einen Write bereits nach der lokalen Speicherung, ist die wahrgenommene Write-Latenz gering; zu diesem Zeitpunkt muss die Änderung jedoch noch nicht im entfernten Storage angekommen sein. Bestätigt das System den Write erst nach erfolgreicher persistenter Speicherung im Backend, wird die entfernte Verbindung Bestandteil jeder einzelnen Write-Latenz. In der Projektpraxis prüfen wir diesen Punkt regelmäßig als Erstes, weil er sich aus Datenblättern selten und aus Marketingmaterial praktisch nie erschließen lässt. Die Existenz eines Caches sagt für sich genommen wenig über Performance, Konsistenz oder Ausfallsicherheit aus – entscheidend ist seine konkrete Semantik.
Tiering verschiebt das Problem in den Recall
Beim Tiering bleibt ein lokales Storage-System bestehen, und Daten werden abhängig von definierten Regeln zwischen Storage-Klassen verschoben, etwa vom Performance Tier über einen Capacity Tier bis in einen Cloud Tier. Die Entscheidung kann vom Alter der Daten abhängen, von ihrem Zugriffsmuster oder von beidem.
Cloud-Plattformen verwenden vergleichbare Mechanismen zwischen ihren eigenen Storage-Klassen. Microsoft Azure Blob Storage unterscheidet Hot-, Cool-, Cold- und Archive-Tiers, die sich nicht nur bei den Storage-Kosten unterscheiden, sondern auch hinsichtlich Zugriffskosten, Mindestaufbewahrungszeiträumen und – beim Archive Tier – der Zugriffslatenz. Ein archivierter Blob kann nicht direkt gelesen werden, sondern muss zunächst in einen Online-Tier rehydriert werden; Microsoft dokumentiert dafür je nach gewählter Priorität bis zu 15 Stunden. Die Metadaten des Objekts bleiben währenddessen lesbar. Der Namespace-Eintrag existiert also weiter, während die Nutzdaten nicht verfügbar sind.
Damit wird ein Architekturprinzip sichtbar, das über den konkreten Anbieter hinausreicht: Billigere Kapazität ist nicht notwendigerweise gleichwertig verfügbare Kapazität. Bei einem Tiering-Konzept muss deshalb definiert werden, was beim erneuten Zugriff auf ausgelagerte Daten geschieht – ob ein vollständiges Objekt zurückgeholt wird oder partiell gelesen werden kann, wie lange der Recall dauert, wo die Zuordnung zwischen Namespace und ausgelagerten Daten liegt, was bei Ausfall des Cloud-Tiers passiert und welche Kosten häufige Recalls verursachen. Die Qualität einer Tiering-Architektur lässt sich aus diesen Gründen nicht anhand des Preises pro gespeichertem Terabyte beurteilen.
Replikation erzeugt Kopien, keine Entlastung
Eine weitere Möglichkeit besteht darin, Daten nicht auszulagern, sondern eine zusätzliche Kopie in einer anderen Umgebung zu erzeugen. Die lokale Kopie bleibt vollständig erhalten. Das unterscheidet Replikation fundamental vom Tiering: Dort wird die Platzierung eines Datenbestands verändert, hier existieren mehrere Kopien nebeneinander.
Auch bei der Replikation entscheidet die Semantik. Bei synchroner Replikation gilt ein Write erst dann als abgeschlossen, wenn die erforderlichen Replikate den Schreibvorgang bestätigt haben; die Entfernung zwischen den Systemen wirkt damit unmittelbar auf die Write-Latenz. Bei asynchroner Replikation bestätigt das primäre System einen Write, bevor die entfernte Kopie aktualisiert wurde. Geografische Distanz wird dadurch beherrschbar, gleichzeitig entsteht ein Zeitraum, in dem Primary und Replica unterschiedliche Datenstände besitzen können. Für Disaster Recovery folgt daraus unmittelbar die Frage nach dem Recovery Point Objective.
Auch große Cloud-Plattformen nutzen unterschiedliche Modelle abhängig von der Failure Domain. Microsoft dokumentiert für Azure Storage synchrone Replikation innerhalb der lokalen beziehungsweise zonalen Redundanzmodelle und asynchrone Replikation in eine geografisch entfernte Secondary Region bei den Geo-Redundanzoptionen. Innerhalb der Sekundärregion wird anschließend wieder synchron repliziert – die Asynchronität betrifft also genau den Übergang zwischen den Regionen.
Mehrere Standorte machen den Namespace zum eigentlichen Problem
Die bisher beschriebenen Modelle verbinden jeweils eine lokale Umgebung mit einem Cloud-Dienst. Sobald mehrere Standorte auf denselben Datenbestand zugreifen sollen, steht nicht mehr die Anbindung eines einzelnen Rechenzentrums im Vordergrund, sondern die Frage, wie ein gemeinsamer Namespace über verteilte Standorte hinweg konsistent bleibt.
Der Datenpfad ähnelt zunächst dem Gateway-Modell, doch referenzieren mehrere solcher Instanzen denselben Datenbestand: Die autoritative Kopie liegt im Object Storage, während jeder Standort lokal denjenigen Teil vorhält, der dort benötigt wird. Damit entsteht eine Ebene, die im Einzelstandort-Gateway nicht existiert – die Koordination zwischen den Standorten.
Daraus ergeben sich Fragen, die keine der vorherigen Architekturen stellt. Wie schnell wird eine Änderung an Standort A für Standort B sichtbar? Erfährt Standort B davon, weil er in einem definierten Intervall den zentralen Bestand abfragt, oder weil eine Änderung eine Benachrichtigung auslöst? Die beiden Mechanismen unterscheiden sich nicht graduell, sondern strukturell: Intervallbasierte Verfahren begrenzen die Sichtbarkeitsverzögerung durch die Länge des Intervalls, ereignisgesteuerte durch die Laufzeit der Benachrichtigung. Welches Verfahren eine Plattform verwendet, gehört in die Herstellerdokumentation geprüft. Hinzu kommt die Frage gleichzeitiger Zugriffe: Bearbeiten zwei Standorte dieselbe Datei, muss die Architektur festlegen, ob ein standortübergreifendes Locking existiert, ob konkurrierende Änderungen zu getrennten Versionen führen oder ob ein Konflikt überhaupt erkannt wird.
Auch das Ausfallverhalten unterscheidet sich. Verliert ein Standort die WAN-Verbindung, kann er häufig weiterhin auf lokal vorgehaltene Daten zugreifen; die währenddessen entstehenden Änderungen bleiben jedoch für die übrigen Standorte unsichtbar und müssen nach Wiederherstellung der Verbindung mit deren zwischenzeitlichen Änderungen in Einklang gebracht werden. Der Gewinn an Flexibilität wird damit durch höhere Komplexität im Konsistenz- und Konfliktverhalten erkauft.
Mehr Bandbreite behebt kein Latenzproblem
Bandbreite und Latenz werden bei Hybrid Storage häufig gemeinsam betrachtet, beschreiben technisch aber unterschiedliche Eigenschaften. Bandbreite begrenzt, welche Datenmenge pro Zeiteinheit übertragen werden kann; Latenz beschreibt die Zeit, die eine Kommunikation zwischen zwei Endpunkten benötigt.
Für eine Datenmenge D und eine effektiv nutzbare Übertragungsrate B beträgt die theoretische reine Transferzeit mindestens t = D / B. Bei 100 TB Daten und einer dauerhaft vollständig nutzbaren 1-Gbit/s-Verbindung ergibt sich bereits theoretisch:
8 × 10¹⁴ Bit ÷ 10⁹ Bit/s = 800.000 Sekunden
Das entspricht rund 9,3 Tagen kontinuierlicher Übertragung – ohne Protokoll-Overhead, konkurrierenden Traffic, Rate Limits, Wiederholungen oder geringere tatsächlich erreichbare Durchsätze.
Für kleine, voneinander abhängige Operationen dominiert dagegen die Round Trip Time. Benötigt ein Workflow nacheinander mehrere entfernte Operationen, wird die Gesamtdauer von der Summe dieser RTTs bestimmt, obwohl nur eine geringe Datenmenge übertragen wird. Das erklärt, warum ein Upgrade der WAN-Bandbreite nicht jedes Performanceproblem beseitigt – und warum wir in der Analyse zwischen Durchsatz- und Latenzproblemen trennen, bevor über Leitungskapazität gesprochen wird.
Der Cache ist selbst eine zustandsbehaftete Komponente
Caching versucht dieses Problem zu entschärfen. Bei einem Cache Hit bleibt der Datenpfad lokal, bei einem Cache Miss durchläuft er Cache, WAN und Cloud Storage in beide Richtungen. Die erreichbare Performance hängt deshalb nicht von der Cache-Größe ab, sondern von der Hit Rate und damit vom tatsächlichen Zugriffsmuster. Ein Cache für 10 TB vor einem 500-TB-Datenbestand kann sehr wirksam sein, wenn sich nahezu alle aktiven Zugriffe auf diese 10 TB konzentrieren – und weitgehend wirkungslos bleiben, wenn die Zugriffe gleichmäßig über den gesamten Bestand verteilt sind.
Caching wirft zugleich neue Fragen auf. Beim Read Cache ist zu klären, welche Daten lokal gehalten und wann sie verdrängt werden, beim Write Cache, wann ein Write als persistent gilt. Für lokal geänderte, aber noch nicht übertragene Daten muss das Verhalten bei einem Ausfall definiert sein. Der Cache ist damit keine transparente Beschleunigungsschicht, sondern eine zustandsbehaftete Komponente mit eigenen Anforderungen an Konsistenz und Failure Handling.
Durability schützt weder vor Ausfall noch vor Löschung
Availability beschreibt, ob ein Dienst beziehungsweise Daten zu einem bestimmten Zeitpunkt erreichbar sind; Durability beschreibt die Wahrscheinlichkeit, dass gespeicherte Daten langfristig erhalten bleiben. Ein Storage-Dienst kann deshalb über eine sehr hohe Durability verfügen und dennoch zeitweise nicht erreichbar sein. Ebenso wenig ist Replikation mit Backup gleichzusetzen: Wird eine Löschung automatisch repliziert, wirkt sie auch auf den Kopien, während ein Backup einen separaten, wiederherstellbaren Datenstand bereitstellt. Redundancy, Replication, Backup und Immutability müssen deshalb getrennt betrachtet werden.
Welche Fehlerdomänen tatsächlich abgedeckt sind, hängt zudem von Storage-Klasse und Konfiguration ab. Azure Storage zeigt das deutlich: Bei LRS liegen die Replikate innerhalb eines einzelnen physischen Standorts der Primärregion, während ZRS Daten über drei Availability Zones einer Region verteilt und geo-redundante Varianten die Failure Domain um eine weitere Region erweitern. Für eine Architekturentscheidung reicht die Aussage, die Daten lägen in der Cloud, deshalb nicht aus. Relevant ist, welche Fehlerdomänen gleichzeitig ausfallen können, ohne dass Daten verloren gehen oder der Service nicht mehr verfügbar ist. Bei Hybrid Storage kommt eine Domäne hinzu, die in reinen Cloud- oder reinen On-Premises-Architekturen nicht existiert: die Verbindung zwischen den Umgebungen. Eine Architektur kann folglich beeinträchtigt sein, obwohl sowohl der lokale Storage als auch der Cloud-Dienst vollständig funktionieren.
Als Backup-Ziel entscheidet der Restore, nicht das Backup-Fenster
Cloud Storage wird häufig als Ziel für Backup-Daten eingesetzt. Technisch ist das ein anderer Anwendungsfall als die Erweiterung des produktiven Storage: Die Anwendung greift im regulären Betrieb nicht auf die Cloud-Kopie zu, weshalb die Cloud-Latenz für den produktiven I/O-Pfad kaum eine Rolle spielt.
Entscheidend werden stattdessen Backup Window, Änderungsrate, verfügbare Upload-Bandbreite, Retention, Immutability, Restore-Durchsatz, mögliche Retrieval-Zeiten und die Kosten der Rückübertragung. Besonders der Restore wird bei der Architekturplanung leicht unterschätzt. Ein Backup kann zuverlässig innerhalb eines akzeptablen Backup Windows übertragen werden und trotzdem ein ungeeignetes Recovery-Verhalten besitzen – etwa dann, wenn die Daten in einer Storage-Klasse mit den in Kapitel 5 beschriebenen Rehydrierungszeiten liegen. Für Disaster Recovery ist deshalb nicht nur relevant, wie schnell Daten in die Cloud gelangen, sondern ebenso, wie schnell sie wieder herauskommen.
Das Zugriffsmuster bestimmt die Kosten, nicht die Kapazität
Bei lokalem Storage werden Kosten stark durch Anschaffung, Wartung, Rechenzentrumsfläche, Energieaufnahme und Betrieb bestimmt. Cloud Storage verschiebt einen Teil dieses Modells in nutzungsabhängige Kosten, weshalb die Rechnung aus Datenmenge und Preis pro Terabyte nicht genügt. Je nach Anbieter und Service werden zusätzlich Storage-Klasse, Anzahl und Art der Requests, Datenübertragung und Egress, Retrieval, Mindestaufbewahrungsdauer, vorzeitiges Löschen, Replikation und ergänzende Netzwerkservices relevant.
Azure dokumentiert für seine Blob-Tiers einen bewussten Trade-off zwischen Storage- und Zugriffskosten: Kältere Tiers reduzieren die Kapazitätskosten, während Zugriffe teurer werden. Hinzu kommen Mindestaufbewahrungsdauern – auf General-Purpose-v2-Konten 30 Tage für Cool und 90 Tage für Cold –, bei deren Unterschreitung eine vorzeitige Löschung zusätzlich berechnet wird. Die wirtschaftlich geeignete Storage-Klasse hängt damit unmittelbar vom Zugriffsmuster ab. Ein selten gelesener Datenbestand besitzt ein anderes Kostenprofil als ein gleich großer Bestand, der kontinuierlich gelesen, verändert oder zwischen Cloud und Rechenzentrum bewegt wird.
Eine Betrachtung, die nur die Rechnungsseite kennt, greift allerdings zu kurz. Die Auslagerung von Kapazität senkt Energiebedarf und Kühllast nicht, sie verlagert beide in ein anderes Rechenzentrum. Für die eigene Fläche ist das ein realer und im Rahmen des Energieeffizienzgesetzes berichtsrelevanter Entlastungseffekt; für die Gesamtbilanz ist es keiner. Wer Hybrid-Architekturen mit Nachhaltigkeitsargumenten begründet, sollte diesen Unterschied benennen, statt ihn hinter Effizienzkennzahlen verschwinden zu lassen: Ein verbesserter PUE-Wert beschreibt das Verhältnis von Gesamt- zu IT-Aufnahme und sagt nichts darüber aus, ob die absolute Aufnahme steigt – bei wachsenden Datenbeständen tut sie das in aller Regel.
Datenhoheit endet nicht am Storage-Standort
Bei Cloud- und Hybrid-Storage wird Datenhoheit häufig auf die geografische Storage Location reduziert. Der physische Speicherort ist relevant, beschreibt aber nur einen Teil der Architektur. Zusätzlich ist zu klären, wer die Infrastruktur betreibt und wer die Control Plane kontrolliert, wo Identitäten verwaltet werden und wer über administrative Berechtigungen verfügt, wie das Key Management erfolgt, welche Subprozessoren beteiligt sind und welche Abhängigkeiten von proprietären APIs oder Managementdiensten bestehen. Data Residency und Digital Sovereignty sind damit keine Synonyme: Eine Architektur kann Daten ausschließlich in einer bestimmten Region speichern und trotzdem wesentliche technische oder organisatorische Abhängigkeiten von einem externen Provider besitzen.
Eng damit verbunden ist die Frage, wie leicht sich Daten zwischen Systemen bewegen lassen. Ein standardisiertes Zugriffsprotokoll erleichtert diese Aufgabe, garantiert aber keine Portabilität: Neben den Nutzdaten können Metadaten, Object Tags, Versionen, ACLs, Retention und Lifecycle Policies, Identity-Modelle, Event-Mechanismen sowie herstellerspezifische API-Erweiterungen betroffen sein. Die SNIA adressiert das mit der Cloud Data Management Interface (CDMI), deren Version 2.0.0 als ISO/IEC 17826:2022 international standardisiert ist und eine providerunabhängigere Managementebene über On-Premises-, Hybrid- und Cloud-Deployments hinweg beschreibt; eine Folgeversion 3.0 wird derzeit erarbeitet, ist aber noch nicht als ISO-Standard veröffentlicht. Dass sich die SNIA daneben weiterhin mit Multi-Vendor-S3-Interoperabilität und den dafür notwendigen Testverfahren befasst, zeigt die praktische Relevanz der Unterschiede zwischen Implementierungen. Zu prüfen ist deshalb nicht, ob zwei Systeme dieselbe API verstehen, sondern welche der benötigten Funktionen portabel sind.
Die Architekturmodelle im Vergleich
Architektur
Aktive Daten
Lokaler Zugriff
WAN-Abhängigkeit
Typischer Trade-off
Direkter Cloud-Zugriff
Cloud
nein
hoch
einfache Bereitstellung vs. entfernter Datenpfad
Gateway + Cache
Cloud + Cache
für gecachteDaten
abhängig von Cache und Write-Semantik
lokale Performance vs. Cache-/Konsistenzkomplexität
Cloud Tiering
lokal + Cloud Tier
für lokale Daten
beim Recall
lokale Performance vs. Recall-Verhalten
Replikation
mehrere Kopien
möglich
abhängig von Replikationsmodell
zusätzliche Resilience vs. Kapazitäts- und Synchronisationsaufwand
Verteilter Namespace
Cloud + Caches je Standort
für lokal vorgehaltene Daten
für Sichtbarkeit standortübergreifender Änderungen
standortübergreifende Zusammenarbeit vs. Konsistenz- und Konfliktkomplexität
Cloud Backup
produktiv lokal, Backup Cloud
produktiv lokal
primär für Backup/Restore
entkoppelter Produktivpfad vs. Recovery-Datenbewegung
Die Tabelle zeigt vor allem eines: „Hybrid Storage" beschreibt noch keinen konkreten Datenpfad. Zwei Lösungen können beide unter diesem Begriff vermarktet werden und sich technisch dennoch fundamental unterscheiden.
Die Anforderung steht vor dem Produkt
Vor der Auswahl eines Hybrid-Storage-Modells untersuchen wir deshalb nicht Produkte, sondern Anforderungen. Beim Datenbestand geht es um Größe, Wachstum und tägliche Änderungsrate, beim I/O-Profil um sequenzielle oder zufällige Zugriffe, um Dateigrößen und Parallelität. Bei der Latenz ist zu klären, welche Operationen tatsächlich latenzkritisch sind und ob die Anwendung entfernte Requests parallelisieren kann. Bei der Datenbewegung, wie viel täglich zwischen Rechenzentrum und Cloud übertragen wird und ob im Recovery-Fall der gesamte Bestand zurückgeführt werden muss.
Hinzu kommen die Konsistenzanforderung – wie schnell Änderungen an anderen Systemen oder Standorten sichtbar werden müssen –, das erwartete Verhalten bei WAN-, Standort-, Gateway-, Region- oder Provider-Ausfall sowie die konkreten RPO- und RTO-Vorgaben. Für die Souveränität sind Storage Location, Administration, Identitäten, Schlüsselkontrolle und Providerabhängigkeit zu klären. Und bei den Kosten ist nicht die gespeicherte Kapazität zu bewerten, sondern das erwartete I/O- und Datenbewegungsprofil.
Fazit
Sobald Anwendungen, Gateways, Storage-Systeme und Cloud-Dienste miteinander verbunden werden, bestimmen Datenpfad, Latenz, Bandbreite, Cache-Verhalten, Konsistenz und Failure Domains, wie sich die Gesamtarchitektur verhält. Jeder der beschriebenen Mechanismen löst dabei ein Problem und erzeugt ein anderes – der Cache verlagert Latenz gegen Konsistenzaufwand, Tiering Kapazität gegen Recall-Zeit, asynchrone Replikation Distanz gegen Datenaktualität.
Die Entscheidung sollte deshalb nicht mit der Frage „Cloud oder On-Premises?" beginnen. Technisch präziser ist die Frage, welche Daten wann, an welchem Ort und mit welcher Latenz verfügbar sein müssen – und welchen Datenpfad das erfordert. Erst aus dieser Antwort ergibt sich, welche Kombination aus lokalem Storage, Cloud Storage, Caching, Tiering und Replikation für den jeweiligen Workload sinnvoll ist.
Quellen
Mell, Peter; Grance, Timothy: The NIST Definition of Cloud Computing. NIST Special Publication 800-145, National Institute of Standards and Technology, September 2011.
ISO/IEC 17826:2022: Information technology — Cloud Data Management Interface (CDMI) Version 2.0.0. Edition 3, Mai 2022.
Storage Networking Industry Association (SNIA): Multi-cloud White Paper, Version 1.2, Oktober 2022.
SNIA Cloud Storage Technical Work Group: Introduction to the SNIA Cloud Data Management Interface (CDMI) 3.0, 2025.
SNIA Cloud Object Storage Test Tools Technical Work Group: Open-Source Multi-Vendor S3 Interoperability Tools: Ecosystem and Improvements, 2026.
Amazon Web Services: What is Amazon S3? / Amazon S3 data consistency model, Amazon S3 User Guide, abgerufen 25.08.2026.
Microsoft: Access tiers for blob data – Azure Storage, Microsoft Learn.
Microsoft: Azure Storage redundancy, Microsoft Learn.
Microsoft: Azure storage disaster recovery planning and failover, Microsoft Learn.
Google: Cloud Storage consistency, Google Cloud Documentation.
Welche Entscheidung steht bei Ihnen an?
Sie möchten eine bestehende Infrastruktur bewerten, eine neue Architektur planen oder eine konkrete technische Fragestellung klären? Sprechen Sie mit uns über Ihre Anforderungen.
Spezialist für moderne Dateninfrastruktur
