Storage & Protokolle
Object Storage / S3
Object Storage legt Daten als Objekte (Inhalt, Metadaten, eindeutiger Schlüssel) in einem flachen Namensraum ab, angesprochen über HTTP; Standard ist die S3-API.
- Flacher Namensraum, Buckets
- Skaliert horizontal
- S3-API (HTTP, De-facto-Standard)
- Object Lock (WORM)
- Versionierung, Lifecycle
Object Storage ist neben Block- und Dateispeicher die dritte große Speicherart. Statt Daten in einem Verzeichnisbaum oder als rohe Blöcke abzulegen, speichert er sie als Objekte: Inhalt plus frei definierbare Metadaten plus ein eindeutiger Schlüssel, abgelegt in Behältern namens Buckets. Angesprochen wird alles über eine HTTP-API, und die von Amazon eingeführte S3-API hat sich dafür als De-facto-Standard durchgesetzt.
Dieser Artikel erklärt das Prinzip des flachen Namensraums, den Zugriff über die S3-API und was „S3-kompatibel“ bedeutet, das Konsistenzmodell, Versionierung und Lebenszyklusregeln, die Resilienz über Replikation oder Erasure Coding, die Unveränderlichkeit per Object Lock, die Verschlüsselung und Zugriffskontrolle sowie die architektonischen Grenzen.
1. Objekte statt Dateien oder Blöcke
Ein Objekt besteht aus drei Teilen: den eigentlichen Daten, einem beliebig erweiterbaren Satz Metadaten und einem eindeutigen Schlüssel. Es gibt keinen echten Verzeichnisbaum; was wie ein Pfad aussieht (etwa logs/2026/juni/app.log), ist nur ein flacher Schlüssel mit Schrägstrichen als Namenskonvention. Der Zugriff läuft ausschließlich über HTTP-Operationen (PUT, GET, DELETE, HEAD, LIST), nicht über ein Dateisystem mit open() und seek() und nicht über eine Block-LUN.
2. Die S3-API als De-facto-Standard
Amazon S3 startete 2006 und prägte eine HTTP-API, die heute praktisch jedes Objektspeicher-System nachbildet, von Ceph über MinIO bis zu kommerziellen Appliances. „S3-kompatibel“ ist allerdings ein dehnbarer Begriff: Die Grundoperationen können alle, aber erweiterte Funktionen wie Object Lock, Lifecycle oder bestimmte Richtlinien-Details unterscheiden sich je nach Produkt. Wichtig zur Einordnung: S3 ist ein herstellergeprägtes De-facto-Standard-API, kein formaler ISO- oder IETF-Standard.
3. Konsistenz, Versionierung und Lebenszyklus
Amazon S3 liefert seit Ende 2020 starke Konsistenz: Nach einem erfolgreichen Schreiben sieht der nächste Lesezugriff sofort den aktuellen Stand. Auf eigenen Systemen (etwa Ceph oder MinIO) gilt das jeweilige Produktverhalten, nicht automatisch dasselbe. Mit aktivierter Versionierung bleiben alte Objektstände erhalten, und ein Löschen setzt nur eine Markierung. Lebenszyklusregeln verschieben Objekte automatisch in günstigere Klassen oder löschen sie nach Ablauf, etwa „nach 90 Tagen ins Archiv, nach sieben Jahren löschen“.
4. Resilienz: Replikation oder Erasure Coding
Damit Objekte den Ausfall von Datenträgern überstehen, gibt es zwei Strategien:
| Verfahren | Eigenschaft |
|---|---|
| Replikation | mehrere vollständige Kopien; einfach, schnell, aber hoher Speicheroverhead (z. B. dreifach) |
| Erasure Coding | Aufteilung in Daten- und Paritätsfragmente; deutlich weniger Overhead, dafür mehr Rechenlast bei der Rekonstruktion |
5. Unveränderlichkeit: Object Lock gegen Ransomware
Object Lock setzt das WORM-Prinzip um (write once, read many): Ein Objekt lässt sich für eine festgelegte Frist nicht überschreiben oder löschen. Zwei Modi: Im Governance-Modus dürfen besonders berechtigte Konten die Sperre aufheben, im Compliance-Modus niemand, auch nicht das Administrationskonto. Das ist ein wirksamer Schutz gegen Ransomware und für regulatorische Aufbewahrung, denn selbst ein kompromittierter Backup-Zugang kann gesperrte Sicherungen weder verschlüsseln noch löschen.
Object Lock im Compliance-Modus macht aus einem Backup-Ziel ein unveränderliches: Wer nur schreiben, aber nicht löschen darf, kann von Ransomware nicht um seine Sicherungen gebracht werden.
6. Verschlüsselung und Zugriffskontrolle
Objektspeicher verschlüsselt Daten im Ruhezustand serverseitig (mit verwalteten oder über einen Schlüsseldienst eingebundenen Schlüsseln) und im Transit über TLS. Den Zugriff steuern Bucket-Policies und Identitätsregeln im IAM-Stil. Der häufigste Fehler in der Praxis ist der versehentlich öffentliche Bucket; eine kontoweite Sperre für öffentlichen Zugriff und regelmäßige Audits sind die wirksame Gegenmaßnahme.
Öffentlicher Bucket: der Klassiker-Fehler
Falsch gesetzte Berechtigungen, die einen Bucket öffentlich lesbar machen, gehören zu den häufigsten Cloud-Datenpannen. „Block Public Access“ auf Konto- und Bucket-Ebene und das Erzwingen von TLS per Policy sind Standardabsicherungen.
7. Typische Einsatzfelder
Objektspeicher spielt seine Stärken bei großen Mengen unstrukturierter Daten aus: als Backup- und Archivziel (oft mit Object Lock), für Medien-Assets, Logs, Data Lakes und Analytik sowie als Ablage für Cloud-native Anwendungen und Container-Images. Über S3-kompatible Systeme lässt sich das auch komplett im eigenen Rechenzentrum betreiben.
8. Stärken und Grenzen
| Stärken | Grenzen |
|---|---|
| Skaliert horizontal nahezu unbegrenzt | kein In-Place-Update: Teile eines Objekts nicht änderbar |
| Ideal für unstrukturierte Massendaten und Backup | höhere Latenz, ungeeignet für Datenbanken/VM-Disks |
| Einheitliche S3-API mit breitem Ökosystem | kein POSIX-Dateisystem (open/seek/flock fehlen) |
| Object Lock (WORM) gegen Ransomware und für Compliance | „S3-kompatibel“ heißt nicht überall denselben Funktionsumfang |
| Verschlüsselung, Versionierung, Lifecycle eingebaut | öffentlicher Bucket ist eine häufige Fehlkonfiguration |
Häufige Fragen zu Object Storage / S3
Ein Dateisystem ordnet Daten in einem Verzeichnisbaum und erlaubt POSIX-Operationen wie Öffnen, Suchen und teilweises Überschreiben. Objektspeicher legt Daten in einem flachen Namensraum als Objekte ab, die über HTTP angesprochen und in der Regel komplett geschrieben oder ersetzt werden. Das skaliert besser für unstrukturierte Massendaten, eignet sich aber nicht für latenzkritische, transaktionale Zugriffe.
Object Lock sperrt Objektversionen nach dem WORM-Prinzip für eine festgelegte Frist gegen Überschreiben und Löschen. Im Compliance-Modus kann selbst ein Administrationskonto die Sperre nicht aufheben. Bekommt der Backup-Prozess nur Schreib-, aber keine Lösch- oder Sonderrechte, kann ein kompromittierter Zugang die gesicherten Daten weder verschlüsseln noch löschen.
Auch der Autor ist nur ein Mensch, dem Fehler unterlaufen können. Wenn in diesem Beitrag etwas nicht stimmt oder unklar ist, freuen wir uns über einen kurzen Hinweis über das Kontaktformular unten, wir prüfen und korrigieren das.
Der nächste Schritt
Object Storage / S3 im eigenen Haus richtig einsetzen?
Wir klären, ob und wie der Baustein zu Ihrer Infrastruktur passt, und sagen offen, wann sich der Aufwand lohnt und wann nicht.