Speicher, der nach
Belegung abgerechnet wird

Unterstützt sind Bucket-Policies, ACLs, presignierte URLs, CORS-Konfiguration, Versionierung, Server-Side-Encryption mit verwalteten und eigenen Schlüsseln (SSE-S3, SSE-C), Ereignisbenachrichtigungen an Webhooks sowie S3 Select in der Performance-Klasse.

Nicht unterstützt: S3 Batch Operations, Requester Pays, Intelligent Tiering und Transfer Acceleration. Wer diese Funktionen benötigt, sollte sie vor der Migration aus dem Werkzeug entfernen.

Endpunkt je Region: s3.<region>.entronyx.cloud — beispielsweise s3.fra1.entronyx.cloud

WORM — Write Once, Read Many — heißt: einmal geschrieben, bis zum Fristende nicht mehr veränderbar. Object Lock setzt dafür je Objektversion ein Aufbewahrungsdatum. Solange dieses in der Zukunft liegt, weist der Speicher DELETE und PUT auf dieselbe Version ab — mit HTTP 403, unabhängig von den Rechten des Aufrufers.

Voraussetzung ist ein Bucket mit aktivierter Versionierung; nachträglich lässt sich Object Lock nicht einschalten. Ein Legal Hold wirkt zusätzlich und unbefristet, bis er ausdrücklich aufgehoben wird.

Für die Aufbewahrungspflicht nach GoBD und Abgabenordnung ist der Compliance-Modus mit einer Frist von zehn Jahren die übliche Konfiguration.

Regeln verschieben Objekte zwischen Klassen, löschen abgelaufene Versionen und räumen abgebrochene Multipart-Uploads auf. Ausgewertet wird einmal täglich; der Klassenwechsel ist für Anwendungen transparent, der Schlüssel bleibt gleich.

Eine Regel besteht aus einem Filter (etwa einem Schlüsselpräfix) und einer oder mehreren Aktionen mit Fristen. Wie das in der Praxis aussieht, zeigt das Beispiel unter den vier Karten.

Große Objekte werden in Teilen hochgeladen, die parallel und in beliebiger Reihenfolge übertragen werden dürfen. Abgebrochene Übertragungen lassen sich an der letzten bestätigten Teilnummer fortsetzen.

Unvollständige Uploads belegen Speicher und werden berechnet, bis sie abgeschlossen oder abgebrochen werden. Deshalb gehört in jede Bucket-Konfiguration eine Regel mit AbortIncompleteMultipartUpload — im Beispiel unten nach sieben Tagen.

Ab etwa 100 MB Objektgröße ist der parallele Upload messbar schneller; darunter überwiegt der Verwaltungsaufwand der Teil-Operationen.