S3 API als Schnittstelle für Zugriff auf Object Storage

Storage-Klassen in Amazon S3 und ihre technische Wirkung

Amazon S3 trennt API-Zugriff und interne Datenhaltung über Storage-Klassen, die Verfügbarkeit, Fehlertoleranz, Mindesthaltedauer, Abrechnungsgrenzen für Objektgrößen sowie Abruf- und Restore-Mechaniken festlegen. S3-Standard gilt als Default, sofern ein Upload keine Storage Class übergibt.

AWS bietet für S3-Standard eine geplante Haltbarkeit von 99,999999999 Prozent (11 Neunen) und eine geplante Objektverfügbarkeit von 99,99 Prozent pro Jahr. Der Cloud-Anbieter hält für S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA sowie S3 Glacier Instant Retrieval, S3 Glacier Flexible Retrieval und S3 Glacier Deep Archive eine Speicherung über mindestens drei Availability Zones fest.

S3 Standard-IA richtet sich auf langlebige Daten mit seltenen Zugriffen und Millisekunden Latenz. AWS nennt eine geplante Verfügbarkeit von 99,9 Prozent und eine geplante Haltbarkeit von 99,999999999 Prozent bei Speicherung über mindestens drei Availability Zones. Abrechnung und Lifecycle folgen Randbedingungen, die AWS als Mindestabrechnung von 128 KB pro Objekt und Mindesthaltedauer von 30 Tagen dokumentiert. Bei Löschung, Überschreiben oder Transition vor Ablauf der Frist berechnet AWS eine anteilige Restgebühr. AWS koppelt Abrufe an Retrieval Fees und verlagert Kostentreiber damit vom reinen Storage in Richtung Zugriff.

S3 One Zone-IA nutzt eine einzelne Availability Zone und verliert Schutz gegen den physischen Verlust der Zone. AWS nennt eine geplante Verfügbarkeit von 99,5 Prozent und ordnet den Speicherort einer Availability Zone zu. Die Klasse bindet eine Mindestabrechnung von 128 KB sowie eine Mindesthaltedauer von 30 Tagen an und koppelt Abrufe an Retrieval Fees. Der Anbieter beschreibt fehlende Resilienz gegen den Verlust der Availability Zone bei Katastrophenszenarien und setzt damit eine klare Trennung zwischen kostenseitig attraktivem Storage und Risikoprofil auf Zonenebene.

S3 Intelligent-Tiering im Detail

S3 Intelligent-Tiering verschiebt Objekte abhängig von Zugriffssignalen zwischen Access Tiers innerhalb einer Storage Class und berechnet eine monatliche Monitoring and Automation Charge. AWS beschreibt automatische Tiers für Frequent Access, Infrequent Access und Archive Instant Access. Nach 30 Tagen ohne Zugriff verschiebt der Dienst Objekte in den Infrequent Access Tier. Nach 90 Tagen ohne Zugriff verschiebt der Dienst Objekte in den Archive Instant Access Tier. Amazon nennt dazu optionale Archive Access und Deep Archive Access Tiers, die eine Asynchronität beim Zugriff voraussetzen und über Restore-Operationen arbeiten. Für Intelligent-Tiering gibt es keine Retrieval Fees und die Tierbewegungen innerhalb der Storage Class laufen bei AWS ohne zusätzliche Tiering Charges.

Intelligent-Tiering bindet Auto-Tiering an Objektgrößen. AWS macht dabei klar, dass ein Objekt unter 128 KB nicht unter Auto-Tiering fällt und im Frequent Access Tier verbleibt. AWS beschreibt im Pricing zudem, dass ein Objekt unter 128 KB speicherbar bleibt, aber außerhalb der Auto-Tiering Bewertung liegt und ohne Monitoring Charge läuft. Damit treibt eine Micro-Object-Last eher Request-Kosten und Metadatenlast als Tiering-Einsparungen.

S3 Glacier Instant Retrieval verbindet Archivpreise mit unmittelbarem Objektzugriff und bietet Millisekunden als mittlere Abrufzeit. Eine Mindesthaltedauer von 90 Tagen ist in AWS üblich sowie eine Mindestabrechnung von 128 KB. AWS koppelt Abrufe an Retrieval Fees.

S3 Glacier Flexible Retrieval und S3 Glacier Deep Archive klassifiziert AWS als Archivspeicher ohne Echtzeitzugriff. Der Cloud-Anbieter beschreibt für Flexible Retrieval Abrufzeiten im Bereich von Minuten bis 12 Stunden und nennt eine Mindesthaltedauer von 90 Tagen. Deep Archive ordnet AWS-Abrufzeiten im Bereich von 9 bis 48 Stunden zu und nennt 180 Tage Mindesthaltedauer. Löschung, Überschreiben oder Transition vor Ablauf der Mindesthaltedauer sind an anteilige Restgebühren gekoppelt.

Für Flexible Retrieval stehen mehrere Abrufvarianten zur Verfügung. Expedited Retrieval liefert Daten innerhalb weniger Minuten. Standard Retrieval bewegt sich im Stundenbereich. Bulk Retrieval erreicht Zeitfenster zwischen fünf und zwölf Stunden und verursacht keine zusätzlichen Abrufgebühren. Deep Archive nutzt Standard Retrieval mit zweistelligen Stundenwerten sowie Bulk Retrieval mit Laufzeiten bis zu 48 Stunden.

Der Restore-Vorgang legt eine temporäre Kopie des archivierten Objekts an, die für einen frei definierbaren Zeitraum bereitsteht. Die Abrechnung erfasst neben dem Archivspeicher auch diese temporäre Kopie nach der S3 Standard Storage Rate. Zusätzlich fällt ein Metadaten-Overhead von 40 KB pro archiviertem Objekt an, aufgeteilt auf Anteile zu S3-Standard- und Glacier-Tarifen.

Die Glacier-Storage-Klassen bleiben technisch Teil von Amazon S3 und unterscheiden sich vom eigenständigen Amazon-Glacier-Dienst. Objekte verbleiben im S3 Namespace, der Zugriff erfolgt über Konsole, API oder SDK. Für archivierte Daten fungiert Restore als notwendige Vorstufe vor einem GET-Zugriff.

Haltbarkeit, Verfügbarkeit und SLA als Rahmenbedingungen

Für S3 Standard, S3 Intelligent-Tiering, S3 Standard-IA sowie die Glacier-Storage-Klassen gilt eine redundante Ablage über mehrere Geräte in mindestens drei Availability Zones je Region. Eine Availability Zone umfasst ein oder mehrere physisch getrennte Rechenzentren mit eigener Energieversorgung, Netzwerk- und Konnektivitätsstruktur. Die Zonen liegen in räumlicher Distanz zueinander, innerhalb einer Region mit bis zu 100 Kilometern Abstand.

Haltbarkeit basiert auf Mechanismen zur Erkennung und Reparatur verlorener Redundanz sowie auf regelmäßigen Integritätsprüfungen über Checksummen. Die Architektur berücksichtigt parallele Geräteausfälle und toleriert den vollständigen Verlust einer Availability Zone für S3 Standard, Intelligent-Tiering, Standard-IA sowie sämtliche Glacier-Varianten.

Das Service Level Agreement (SLA) definiert Verfügbarkeitszusagen über eine Monthly Uptime Percentage und verknüpft diese mit Service Credits. Die Berechnung der Error Rates erfolgt in Fünf-Minuten-Intervallen auf Basis interner Serverfehler. Für S3 Standard, Glacier Flexible Retrieval und Glacier Deep Archive greifen Service Credits bei Unterschreiten von 99,9 Prozent Monatsverfügbarkeit. Für Intelligent-Tiering, Standard-IA, One Zone-IA und Glacier Instant Retrieval beginnt die Gutschrift ab 99,0 Prozent, mit weiteren Abstufungen bei geringeren Werten.

Lifecycle und Intelligent-Tiering als Datensteuerung

S3 Lifecycle implementiert Regeln für Transition und Expiration. Beide Vorgänge laufen asynchron, sodass zwischen Erreichen der Regelbedingungen und tatsächlicher Ausführung eine zeitliche Differenz auftreten kann. Abrechnungsänderungen knüpfen grundsätzlich an das Erreichen der Regelkriterien an, auch wenn die physische Aktion noch aussteht. Eine Ausnahme gilt bei Transition in Intelligent-Tiering, bei der die Anpassung erst nach abgeschlossener Verschiebung greift.

Die Lifecycle Engine arbeitet mit UTC-Tagesgrenzen. Transition- und Expiration-Daten runden auf Mitternacht des Folgetags. Das Objektalter berechnet sich relativ zur Erstellzeit in UTC. In versionierten Buckets ersetzt eine Expiration-Angabe der aktuellen Version das Objekt durch einen Delete Marker. Frühere Versionen bleiben als Noncurrent Versions erhalten und fließen in Objektstatistiken ein.

Transitions unterliegen festen Pfaden und Mindestaufbewahrungszeiten. Eine Verschiebung in Standard-IA oder One Zone-IA ist innerhalb der ersten 30 Tage nach Objekterstellung gesperrt. Für Noncurrent Versions gilt ebenfalls eine Mindestdauer von 30 Tagen. Objekte unter 128 KB fallen standardmäßig nicht unter Transition, sofern kein Object-Size-Filter gesetzt ist. Seit September 2024 verhindert eine Default-Regel die automatische Transition kleiner Objekte ohne explizite Filterdefinition. Objekte mit Pending Replication Status bleiben von Transition ausgeschlossen. Bei Unterschreitung der Mindestdauer berechnet das Abrechnungsmodell die Restzeit als Mindestgebühr.

Für Archivklassen verknüpft Lifecycle Transition mit Restore und Copy. Flexible Retrieval und Deep Archive erlauben keinen unmittelbaren Zugriff und verlangen vorab einen Restore, der eine temporäre Kopie erzeugt. Deep Archive kennt ausschließlich Einbahn-Pfade. Eine Rückführung in andere Klassen erfordert Restore und anschließendes Copy-Overwrite. Die Verschlüsselung bleibt über den gesamten Transition-Prozess erhalten.

Versionierung und Object Lock für Unveränderlichkeit

Versioning speichert mehrere Objektversionen unter demselben Key und erlaubt die Wiederherstellung älterer Zustände nach Überschreiben oder Löschung. Ohne explizite Version-ID liefert ein Request die zuletzt geschriebene Version. Versioning ergänzt Replication und Object Lock als Schutzmechanismus.

Lifecycle-Regeln interagieren mit Versioning über Delete Marker und Noncurrent-Version-Aktionen. Eine Expiration in einem versionierten Bucket erzeugt einen Delete Marker als neue aktuelle Version. Ältere Versionen verbleiben als Noncurrent Versions. Für deren Verwaltung stehen NoncurrentVersionExpiration und NoncurrentVersionTransition zur Verfügung, einschließlich permanenter Löschung abgelaufener Noncurrent Versions.

Object Lock implementiert ein WORM-Modell auf Basis von Versioning. Retention Periods und Legal Holds beziehen sich stets auf einzelne Objektversionen. Versioning bleibt Voraussetzung, und Lock-Informationen liegen in den Metadaten der jeweiligen Version. Retention und Legal Hold blockieren keine Erstellung neuer Versionen. Zwei Modi stehen zur Verfügung. Compliance verhindert jede Löschung oder Verkürzung der Retention, auch für den Root-Account. Governance erlaubt einen Override durch Nutzer mit entsprechenden Sonderrechten.

Legal Hold wirkt zeitlich unbegrenzt und unabhängig von Retention Periods. Die Aufhebung erfolgt ausschließlich durch explizite Entfernung. Ein Delete ohne Version-ID erzeugt weiterhin einen Delete Marker. Ein Delete mit Version-ID gegen eine geschützte Version führt zu einer Zugriffsverweigerung.

Nach Aktivierung bleibt Object Lock dauerhaft mit dem Bucket verknüpft. Eine Deaktivierung ist ausgeschlossen, ebenso die Suspendierung von Versioning. Buckets mit Object Lock eignen sich nicht als Ziel für Server Access Logs.

MFA Delete erweitert das Versioning-Subresource und bindet das Löschen einzelner Versionen sowie Änderungen am Versioning-Status an eine Multifaktor-Authentifizierung. Diese Funktion lässt sich nicht mit Lifecycle-Konfigurationen kombinieren und nutzt dieselbe API wie die Versioning-Aktivierung.

Serverseitige Verschlüsselung und Replikation im Betrieb

Amazon S3 verschlüsselt neue Objekte serverseitig standardmäßig mit SSE-S3. Für jedes Objekt erzeugt das System einen eigenen Schlüssel, verschlüsselt diesen zusätzlich mit einem rotierenden Master-Key und nutzt AES-GCM mit 256 Bit. Die Verschlüsselung umfasst Objektinhalte, nicht jedoch alle Metadaten. Kennzeichnungen zur Verschlüsselung erscheinen in CloudTrail, S3 Inventory, S3 Storage Lens, der Konsole und in API-Antworten.

SSE-KMS verlagert die Schlüsselverwaltung in AWS KMS und nutzt Envelope Encryption. Der KMS-Schlüssel muss im selben Region-Scope wie der Bucket liegen. Für die Nutzung fallen zusätzliche KMS-Kosten an. Data-Key-Erzeugung und Entschlüsselung unterliegen restriktiven Key-Policies. Eine Umstellung der Default Encryption auf SSE-KMS wirkt nur auf neue Objekte. Bestehende Daten lassen sich über Copy-Operationen oder S3 Batch Operations neu verschlüsseln. S3 Bucket Keys reduzieren direkte KMS-Requests und senken dadurch den internen Aufrufverkehr signifikant.

S3 Replication kopiert Objekte asynchron zwischen Buckets innerhalb einer Region oder über Regionsgrenzen hinweg. Same-Region Replication und Cross-Region Replication decken unterschiedliche Szenarien ab. Live Replication erfasst neue oder aktualisierte Objekte, Batch Replication bezieht bestehende Daten ein. Die Zielklasse kann von der Quellklasse abweichen.

Versioning bleibt Voraussetzung auf Source- und Destination-Bucket. Die Replikationskonfiguration verlangt passende Berechtigungen und zusätzliche Einstellungen bei Object-Lock-Buckets. Eine Deaktivierung von Versioning auf dem Quell-Bucket führt zu einem Fehler, solange eine aktive Replication Configuration existiert. Auch eine Suspendierung auf dem Ziel-Bucket unterbricht den Kopiervorgang und markiert betroffene Objekte mit einem Fehlerstatus.

S3 Replication Time Control ergänzt die Standardreplikation um eine SLA-gestützte Zielgröße. 99,99 Prozent neu hochgeladener Objekte erreichen das Ziel innerhalb von 15 Minuten.

Die Kombination aus Replikation und Verschlüsselung erfordert zusätzliche Konfiguration. Objekte mit SSE-KMS oder DSSE-KMS erfordern eine zusätzliche Konfiguration für die Replikation. Eine explizite Aktivierung in der Replikationskonfiguration sowie ein symmetrischer Customer-Managed-Key im Region-Scope des Ziel-Buckets bleiben erforderlich. Die Validität des KMS-Schlüssels prüft PutBucketReplication nicht. Aktivierte Default Encryption im Ziel-Bucket kann zudem Auswirkungen auf ETags haben, falls Quellobjekte unverschlüsselt vorliegen.