WISSEN > OBJECT STORAGE > GRUNDLAGEN
Autor: Dirk Neumann Geschäftsführer ASSISTRA Cloud Services GmbH 17.08.2026
Was ist Object Storage?
Das Objektmodell verstehen und von Cloud, S3 und Immutability abgrenzen
Das sollten Sie mitnehmen:
- Object Storage ist ein Zugriffsmodell, kein Speichermedium.
Der Unterschied zu File und Block liegt in der Schnittstelle, nicht in der Frage, ob darunter Festplatten oder Flash arbeiten.
- Ein Objekt verbindet Nutzdaten, Identifier und Metadaten.
Diese drei Bestandteile bilden die Einheit, die das System verwaltet und adressiert.
- Fehlende Verzeichnishierarchie bedeutet nicht fehlende Struktur.
Konkrete Schnittstellen kennen Container und Präfixe, ohne damit POSIX-Semantik zu übernehmen.
- Object Storage ist weder Cloud noch S3 noch Immutability.
Diese Eigenschaften sind Betriebsmodelle, APIs und Konfigurationsentscheidungen, die getrennt zu bewerten sind.
- Zugriffsprotokoll und Speichermodell müssen nicht identisch sein.
Eine File-Service-Schicht kann Object Storage als Backend nutzen und trotzdem SMB oder NFS bereitstellen.
Das Objektmodell verstehen und von Cloud, S3 und Immutability abgrenzen
Inhaltsverzeichnis
- Object Storage unterscheidet sich nicht im Medium, sondern in der Schnittstelle
- Ein Objekt ist mehr als eine Datei unter anderem Namen
- Der fehlende Verzeichnisbaum bedeutet nicht das Fehlen jeder Struktur
- Der Zugriff erfolgt über APIs, aber Object Storage ist nicht S3
- Was beim Schreiben passiert, entscheidet die Implementierung, nicht das Modell
- Das Objektmodell macht Daten nicht automatisch unveränderlich
- Cloud Storage und Object Storage beschreiben verschiedene Ebenen
- Object Storage kann hinter einer File-Schnittstelle liegen
- Aus dem Begriff allein folgt keine einzige Systemeigenschaft
- Fazit
- Quellen
Object Storage ist ein Speichermodell, bei dem Daten als eigenständige Objekte abgelegt und über einen Identifier beziehungsweise Key adressiert werden. Anders als bei File Storage steht damit nicht die Datei innerhalb einer Verzeichnisstruktur im Mittelpunkt, anders als bei Block Storage nicht ein adressierbarer Speicherbereich.
Der Begriff wird in Ausschreibungen und Architekturdiskussionen häufig weiter gefasst, als er trägt. Er bezeichnet ein Daten- und Zugriffsmodell, nicht ein Betriebsmodell, nicht eine bestimmte API und nicht ein Sicherheitsniveau. Dieser Artikel beschreibt, woraus ein Objekt besteht, wie der Zugriff erfolgt, und wovon Object Storage technisch abzugrenzen ist.
Object Storage unterscheidet sich nicht im Medium, sondern in der Schnittstelle
Die Storage Networking Industry Association beschreibt Object Storage als Methode, Daten als Sammlung einzelner, eindeutig identifizierbarer und unteilbarer Objekte zu speichern und wieder abzurufen. Ein Objekt verbindet dabei die Nutzdaten mit einer eindeutigen Adressierung und zusätzlichen Metadaten, und Anwendungen greifen typischerweise über eine API darauf zu.
Der Vergleich mit den beiden anderen Grundmodellen macht die Abgrenzung deutlich. Ein Block-Storage-System stellt adressierbare Speicherbereiche bereit; ein darüberliegendes Dateisystem oder eine Datenbank organisiert diese Blöcke. Ein File-Storage-System stellt Dateien und Verzeichnisse in einem Namespace bereit, auf den Clients über Protokolle wie SMB oder NFS zugreifen. Bei Object Storage bildet dagegen das Objekt selbst die zentrale logische Speichereinheit, und die Anwendung spricht es über eine Object API an.
[BILD 1] Gegenüberstellung der drei Zugriffspfade: Block (Anwendung – Dateisystem oder Datenbank – Block Device – Blöcke), File (Anwendung – SMB/NFS – Dateisystem – Datei) und Object (Anwendung – Object API – Object Namespace – Objekt). Drei parallele horizontale Bahnen, gleiche Höhe, Object-Bahn farblich hervorgehoben.
Der Unterschied liegt damit nicht primär auf der Ebene der physischen Speichermedien. Wie ein Object-Storage-System seine Daten intern auf HDDs, SSDs oder auf darunterliegenden File- und Block-Systemen ablegt, ist für die Anwendung abstrahiert. Die SNIA weist ausdrücklich darauf hin, dass viele Systeme intern file- oder blockbasierten Storage verwenden und dass diese interne Umsetzung für die Anwendung nicht relevant sein muss. Entscheidend ist die Schnittstelle, über die Daten adressiert und verarbeitet werden.
Ein Objekt ist mehr als eine Datei unter anderem Namen
Vereinfacht besteht ein Objekt aus drei Bestandteilen: den Nutzdaten, einer eindeutigen Adressierung und den zugehörigen Metadaten. Diese Zusammensetzung ist der Kern des Modells und der Grund, warum sich Object Storage nicht auf ein umbenanntes Dateisystem reduzieren lässt.
[BILD 2] Aufbau eines Objekts als dreigeteilter Block: Data, Identifier beziehungsweise Key, Metadata. Metadatenfeld mit angedeuteten Attribut-Wert-Paaren.
Data
Die Nutzdaten bilden den eigentlichen Inhalt des Objekts, etwa Dokumente, Bilder, Videos, Backup-Daten oder beliebige binäre Daten. Für das Object-Storage-System ist die inhaltliche Bedeutung dieser Daten grundsätzlich nicht relevant. Die SNIA formuliert das deutlich: Was ein Objekt enthält, ist für das Speichersystem unwichtig, weil es das Objekt lediglich als Datenmenge verwaltet, die mit einer Objekt-ID verknüpft ist. Ein Objekt kann deshalb ebenso eine einzelne Datei wie ein komplettes Dateisystem, ein Datenbank-Dump oder ein Container-Image aufnehmen.
Identifier beziehungsweise Key
Damit ein Objekt wiedergefunden werden kann, benötigt es eine eindeutige Adressierung innerhalb seines Namensraums. Wie diese Adressierung konkret umgesetzt wird, hängt jedoch von der verwendeten Schnittstelle ab, und genau hier lohnt sich die Trennung zwischen dem allgemeinen Prinzip und einer bestimmten API.
Die Cloud Data Management Interface der SNIA zeigt das anschaulich. Dort besitzt jedes Datenobjekt einen einzelnen, global eindeutigen Object Identifier, der über die gesamte Lebensdauer des Objekts konstant bleibt, und zusätzlich mindestens eine URI-Adresse, über die es angesprochen werden kann. Adressierung über Namen und Adressierung über eine Objekt-ID sind also zwei parallele Wege auf dasselbe Objekt.
Die verkürzte Merkformel, ein Objekt sei nichts weiter als ein Key mit angehängten Daten, ist als Einstieg brauchbar. Sie darf aber nicht als Implementierungsvorschrift für sämtliche Object-Storage-Systeme gelesen werden.
Metadata
Zusätzlich zu den Nutzdaten können Objekte Metadaten tragen. Die SNIA beschreibt Object Metadata als Daten, die zum Objekt gehören, aber über Objekt-ID und Nutzdaten hinausgehen, und die häufig als Attribut-Wert-Paare ausgedrückt werden.
CDMI unterscheidet feiner und trennt unter anderem systemgenerierte Informationen von Metadaten, die durch Benutzer oder Anwendungen gesetzt werden. Für die Architekturbetrachtung ist vor allem eines wichtig: Daten und beschreibende Informationen sind im Objektmodell eng miteinander verbunden und werden gemeinsam verwaltet.
Der fehlende Verzeichnisbaum bedeutet nicht das Fehlen jeder Struktur
Bei einem klassischen Dateisystem ist die hierarchische Struktur ein konstituierendes Element. Verzeichnisse und Unterverzeichnisse bilden einen Namespace, in dem ein Pfad wie /projekte/kunde-a/planung/dokument.pdf sowohl Adresse als auch Ordnungsprinzip ist.
Das grundlegende Object-Storage-Modell setzt eine solche Hierarchie nicht voraus. Die SNIA beschreibt Objekte als individuell über ihre Objekt-ID adressierbar und stellt fest, dass keine der Verzeichnishierarchie eines Dateisystems entsprechende Struktur existiert.
Daraus wird in der Praxis häufig die zu kurz gegriffene Aussage abgeleitet, Object Storage kenne keine Verzeichnisse. Konkrete Schnittstellen stellen sehr wohl Container, Präfixe, Namensräume oder andere Gruppierungsmechanismen bereit. CDMI ist dafür ein gutes Beispiel: Der Standard kennt neben Datenobjekten auch Container Objects, die weitere Objekte aufnehmen und sogar verschachtelt werden können.
Die technisch belastbare Formulierung lautet deshalb anders. Eine solche Gruppierungsstruktur ist nicht automatisch mit der Verzeichnissemantik eines POSIX-, SMB- oder NFS-Dateisystems gleichzusetzen. Wer aus dem Vorhandensein von Präfixen auf gewohntes Verhalten bei Umbenennungen, Sperren oder Berechtigungsvererbung schließt, überträgt Annahmen, die das Modell nicht deckt.
Der Zugriff erfolgt über APIs, aber Object Storage ist nicht S3
Unabhängig von der internen Umsetzung unterstützen Object-Storage-Systeme laut SNIA einfache Schnittstellen zum Erstellen, Lesen und Löschen von Objekten sowie zum Durchsuchen von Metadaten. Als bekannte Beispiele nennt die SNIA ausdrücklich CDMI und S3, die beide über HTTP arbeiten und Object Storage damit für Web- und Cloud-Nutzung attraktiv machen.
An dieser Stelle ist die Unterscheidung zwischen Architekturprinzip und konkreter API entscheidend. S3 ist eine einzelne, weit verbreitete Object-Storage-API, die sich faktisch als Integrationsstandard etabliert hat. CDMI dagegen ist ein herstellerneutraler Standard der SNIA, der als ISO/IEC 17826 international normiert ist; die aktuelle Fassung ist CDMI 2.0.0, standardisiert als ISO/IEC 17826:2022. Die SNIA beschreibt CDMI als RESTful HTTP-basiertes Managementprotokoll für Daten in Cloud-, Hybrid- und On-Premises-Storage-Systemen.
Object Storage ist deshalb nicht mit S3 gleichzusetzen. Diese Unterscheidung ist keine akademische Feinheit: Sie entscheidet darüber, ob eine Architekturbewertung das Speichermodell oder ein bestimmtes API-Verhalten betrifft. [QUERVERWEIS: S3 als gemeinsame Zugriffsschicht]
Was beim Schreiben passiert, entscheidet die Implementierung, nicht das Modell
Aus Sicht einer Anwendung werden Daten zusammen mit den für die jeweilige Schnittstelle notwendigen Informationen an den Object Store übertragen. Das System muss anschließend sicherstellen, dass das Objekt gespeichert und später über seine Adressierung wiedergefunden werden kann. Wie es das intern umsetzt, gehört auf eine zweite Architekturebene.
Ein Object Store kann intern Replikation oder Erasure Coding zur Datenabsicherung einsetzen. Solche Mechanismen gehören jedoch nicht zur Definition eines Objekts. Sie beschreiben die Data-Protection-Architektur eines konkreten Systems und sind separat zu bewerten. [QUERVERWEIS: Scale-out ObjectStorage]
[BILD 3] Fünfstufiges Schichtenmodell von oben nach unten: Anwendung, Object API, Object- und Metadata-Layer, interne Storage-Architektur, physische Speichermedien. Trennlinie zwischen Object API und Object-Layer als Grenze der Anwendungssicht markiert.
Genau diese Trennung entlastet die Anwendung. Sie muss nicht wissen, auf welchem physischen Datenträger die Bestandteile ihrer Daten liegen, welches Kodierungsschema verwendet wird oder wie viele Knoten an einem Schreibvorgang beteiligt waren. Umgekehrt bedeutet das aber auch, dass sich aus dem Begriff Object Storage keine Aussage über die tatsächliche Absicherung eines Systems ableiten lässt.
Das Objektmodell macht Daten nicht automatisch unveränderlich
Hier ist eine terminologische Unterscheidung nötig, die in Ausschreibungen und Sicherheitskonzepten regelmäßig verschwimmt.
Die SNIA beschreibt Objekte als atomare Einheiten. Teilbereiche eines Objekts können gelesen werden, aber häufig besteht keine Möglichkeit, ein Objekt oder Teile davon zu aktualisieren; stattdessen ist ein vollständiges Neuschreiben erforderlich. Löschen wird von den meisten Systemen unterstützt.
Diese Eigenschaft des Objektmodells ist etwas anderes als Immutable Storage oder Object Lock. Dort geht es um Schutzmechanismen, die Veränderung oder Löschung für einen definierten Zeitraum technisch verhindern, typischerweise im Rahmen von Retention-Richtlinien und Versionierung. Ob und wie solche Mechanismen zur Verfügung stehen, hängt von Implementierung und Konfiguration ab, nicht vom Speichermodell.
Wer Object Storage als Backup- oder Archivziel bewertet, muss diese Ebene deshalb ausdrücklich prüfen. Ein System ist nicht dadurch ransomware-resilient, dass es Objekte speichert. [QUERVERWEIS: Ransomware-Schutz für Enterprise Storage]
Die enge Verbindung von Daten und Metadaten gehört zu den wesentlichen Eigenschaften des Objektmodells. Ein Dateisystem besitzt allerdings ebenfalls Metadaten, etwa Dateigröße, Zeitstempel, Eigentümer und Berechtigungen. Der Unterschied besteht also nicht darin, dass nur Object Storage Metadaten kennt.
Der Unterschied liegt in der Erweiterbarkeit. Object Storage kann anwendungs- oder systemspezifische Metadaten unmittelbar im Objektmodell vorsehen, die über klassische Dateiattribute hinausgehen. Damit lassen sich Informationen über Herkunft, Klassifizierung, Aufbewahrung oder Verarbeitungsstatus direkt an das Datum binden, statt sie in einer separaten Datenbank zu führen.
Wie weit das trägt, hängt von der Schnittstelle ab. Die SNIA nennt das Durchsuchen von Metadaten als grundlegende Operation; welche Metadatenfelder eine konkrete Implementierung indiziert, in welchem Umfang sie durchsuchbar sind und ob sie für Policy-Entscheidungen ausgewertet werden können, unterscheidet sich zwischen Systemen jedoch erheblich. Eine pauschale Annahme, jedes Object-Storage-System könne beliebige Metadaten durchsuchen und für Lifecycle-Regeln verwenden, ist bei der Architekturplanung nicht belastbar. [QUERVERWEIS: Metadaten und Klassifizierung für KI]
Cloud Storage und Object Storage beschreiben verschiedene Ebenen
Die beiden Begriffe werden oft synonym verwendet, beschreiben aber unterschiedliche Dinge. Object Storage bezeichnet ein Speicher- und Zugriffsmodell. Cloud Storage bezeichnet ein Bereitstellungs- und Servicemodell.
Die SNIA definiert Cloud Storage als Data Storage as a Service: Storage wird über ein Netzwerk mit definierten Service-Levels, abstrahiertem Management und verbrauchsbasierten Modellen bereitgestellt. Entscheidend ist dabei ausdrücklich das Service- und Schnittstellenmodell, nicht die Geografie. Cloud Storage kann als öffentlicher Dienst, als private oder On-Premises-Plattform im eigenen Rechenzentrum oder in hybriden und Multi-Cloud-Architekturen betrieben werden.
Daraus folgt beides: Ein On-Premises-Object-Storage-System bleibt Object Storage, auch ohne Cloud-Bezug. Und ein Cloud-Storage-Angebot muss nicht Object Storage sein, denn auch File Storage lässt sich als Service bereitstellen. [QUERVERWEIS: Cloud Storage – Block, File und Object im Vergleich]
Object Storage kann hinter einer File-Schnittstelle liegen
Die Trennung von Speicher- und Zugriffsmodell führt zu einer Architekturvariante, die in der Praxis erhebliche Bedeutung hat. Eine Anwendung muss nicht direkt mit der Object API kommunizieren. Zwischen Client und Object Storage kann eine File-Service-Schicht liegen, die nach oben SMB oder NFS bereitstellt und nach unten Objekte schreibt.
[BILD 4] Zweistufige Darstellung: Clients mit SMB- und NFS-Zugriff auf einen File Service, darunter Object Storage als Persistenzebene. Die Protokollgrenze zwischen File Service und Object Storage deutlich markiert.
Wir haben solche Architekturen in Projekten umgesetzt. Object Storage diente dabei als Backend beziehungsweise als Erweiterung von File Services; in einem Fall wurde ein Global File System mit Object Storage in einer Cloud betrieben, in einem anderen mit einer Kombination aus eigenem Rechenzentrum und Cloud Object Storage als Speicherebene. Für die Anwender blieb der Zugriff dabei ein gewohnter File-Zugriff.
Der Architekturpunkt dahinter ist allgemeiner Natur: Das vom Anwender benötigte Zugriffsprotokoll und das darunterliegende Speichermodell müssen nicht identisch sein. Diese Entkopplung ist häufig der eigentliche Grund, warum Object Storage überhaupt in klassischen Unternehmensumgebungen einsetzbar wird.
Die File-Service-Schicht ist dabei keine reine Protokollübersetzung. Sie kann Namespace-, Metadaten-, Caching- oder Synchronisationsfunktionen übernehmen, und genau diese Funktionen bestimmen das Verhalten aus Anwendersicht deutlich stärker als das Object-Backend. Welche Funktionen tatsächlich vorhanden sind, hängt von der jeweiligen Architektur ab. [QUERVERWEIS: Global File System – was ist das?]
Aus dem Begriff allein folgt keine einzige Systemeigenschaft
Aus der Bezeichnung Object Storage lassen sich keine Aussagen über Performance, Verfügbarkeit, Durability, Kosten oder Skalierungsgrenzen eines bestimmten Systems ableiten. Ebenso wenig folgt daraus automatisch Cloud-Betrieb, S3-Kompatibilität, Eignung als Backup- oder Archivziel, Immutability, Erasure Coding oder unbegrenzte Skalierbarkeit. All das sind Eigenschaften, Einsatzmodelle, Schnittstellen oder Implementierungsentscheidungen, die getrennt zu betrachten sind.
Für Architekturentscheidungen ist diese Trennung praktisch relevant. Zwei Systeme können beide zutreffend als Object Storage bezeichnet werden und sich dennoch bei Konsistenzmodell, Metadatenarchitektur, Data Protection, Failure Domains, API-Verhalten und Performance so stark unterscheiden, dass sie für denselben Workload unterschiedlich geeignet sind. Die Modellbezeichnung ist ein Ausgangspunkt der Bewertung, nicht ihr Ergebnis. [QUERVERWEIS: Object Storage wird zur Datenplattform]
Fazit
Object Storage unterscheidet sich von File und Block Storage vor allem durch sein Daten- und Zugriffsmodell. Daten werden als eigenständige Objekte verwaltet und über eine entsprechende Adressierungslogik angesprochen; Nutzdaten, Identifikation und Metadaten bilden gemeinsam das Objekt. Der Zugriff erfolgt typischerweise über APIs und ist von der internen physischen Speicherung abstrahiert.
Für die Architekturplanung ist die Trennung der Ebenen der eigentliche Ertrag dieser Betrachtung. Object Storage beschreibt weder Cloud noch S3 noch Backup, Archivierung oder Unveränderbarkeit. Und eine Anwendung muss nicht zwingend direkt auf eine Object API zugreifen, denn eine File-Service-Schicht kann Object Storage als Backend nutzen und gleichzeitig SMB- oder NFS-Zugriffe bereitstellen.
Ob Object Storage für einen konkreten Workload die richtige Architektur ist, lässt sich aus diesen Grundlagen allerdings noch nicht beantworten. Diese Frage gehört in eine eigene Betrachtung. [QUERVERWEIS: Wann ist Object Storage sinnvoll?]
Quellen
Storage Networking Industry Association (SNIA): What is Object Storage? Aktuelle Online-Fassung, abgerufen am 4. September 2026. https://www.snia.org/education/what-is-object-storage
Storage Networking Industry Association (SNIA): What Is Cloud Storage? Aktuelle Online-Fassung, abgerufen am 4. September 2026. https://www.snia.org/education/what-is-cloud-storage
Storage Networking Industry Association (SNIA): Cloud Data Management Interface (CDMI™). Übersichtsseite zum Standard, abgerufen am 4. September 2026. https://www.snia.org/cdmi
Storage Networking Industry Association (SNIA): Cloud Data Management Interface (CDMI) Specification, Version 2.0.0, Kapitel 8 „Data Objects". Abgerufen am 4. September 2026. http://cdmi.sniacloud.com/cdmi_spec/8-data_objects/8-data_objects.htm
ISO/IEC: ISO/IEC 17826:2022 – Information technology – Cloud Data Management Interface (CDMI) Version 2.0.0. Edition 3, Mai 2022. https://www.iso.org/standard/83451.html
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
