S3 Object Storage

Entstehung und Beteiligte

Amazon S3 startete im März 2006 als früher großer Cloud-Objektspeicher. Seine HTTP-basierte API wurde so verbreitet, dass viele andere Produkte eine S3-kompatible Schnittstelle anbieten, obwohl S3 selbst ein AWS-Dienst ist.

Welches Problem sollte gelöst werden?

Webanwendungen benötigten nahezu beliebig skalierbaren Speicher, ohne Dateiserver oder Blockgeräte selbst zu betreiben. Objekte sollten über eindeutige Schlüssel und Web-APIs abrufbar sein.

Technische Hürden und Lösungen

Objektspeicher besitzt keine normalen POSIX-Dateisemantiken. Konsistenz, Versionierung, Lebenszyklus, Berechtigungen und sehr große Namensräume mussten neu gedacht werden. S3-Kompatibilität ist nicht bei jedem Anbieter vollständig identisch.

Standardisierung und Einordnung

Cloud- und Plattformtechnik entstand aus Rechenzentrum, Virtualisierung, verteilten Systemen und automatisierter Softwareauslieferung. Die grundlegenden Probleme sind nicht neu: Ressourcen müssen geteilt, Ausfälle abgefangen, Änderungen reproduzierbar und Lastspitzen bewältigt werden. Neu ist die hohe Automatisierung und die Möglichkeit, Infrastruktur über Programmierschnittstellen in kurzer Zeit zu erzeugen oder zu verwerfen.

Technik im praktischen Betrieb

Im praktischen Cloudbetrieb müssen Automatisierung und Kosten gemeinsam beobachtet werden. Ressourcen entstehen schnell, verschwinden aber nicht immer automatisch. Tags, Limits, Richtlinien und getrennte Konten oder Projekte schaffen Verantwortlichkeit. Verfügbarkeit sollte über mehrere Fehlerdomänen geplant und mit realen Wiederanlaufproben belegt werden. Ein Anbieter übernimmt Gebäude, Hardware und Teile der Plattform; Konfiguration, Identitäten, Daten, Anwendungen und Backups bleiben je nach Dienstmodell ganz oder teilweise beim Kunden.

Warum das Thema heute noch relevant ist

Viele Cloudbegriffe klingen neu, beschreiben aber bekannte verteilte Systeme unter stärkerer Automatisierung. Die Geschichte hilft, Marketing und Architektur zu trennen. Ein Dienst bleibt von Netz, Speicher, Konsens und Identitäten abhängig, auch wenn diese Schichten nicht sichtbar sind. Betreiber sollten deshalb Ausfallmodelle, Datenexport und Abhängigkeiten dokumentieren. Je bequemer ein verwalteter Dienst ist, desto wichtiger wird die Frage, welche Kontrolle bewusst an den Anbieter abgegeben wurde.

Daten und Meilensteine

• 2006 startet Amazon S3.
• Buckets enthalten Objekte mit Schlüsseln und Metadaten.
• Multipart Upload unterstützt sehr große Objekte.
• Objektspeicher eignet sich nicht automatisch als direkter Ersatz für jede Datenbank oder Dateifreigabe.

Objekte, Schlüssel und Buckets

Ein Objekt besteht aus Daten, Metadaten und einem eindeutigen Schlüssel. Buckets bilden den Verwaltungsrahmen. Verzeichnisse werden meist nur durch Schlüsselnamen simuliert.

Zugriff und Versionierung

Access Keys erhalten minimale Rechte auf definierte Buckets und Aktionen. Versionierung schützt frühere Objektstände, erhöht aber Speicherverbrauch. Lifecycle-Regeln verschieben oder löschen alte Versionen kontrolliert.

Kosten und Rückweg

Neben belegtem Speicher können API-Aufrufe und ausgehender Datenverkehr Kosten verursachen. Vor dem Einsatz müssen Restore-Geschwindigkeit, Anbietergrenzen und ein möglicher Export großer Datenmengen betrachtet werden.