Wenn Ihre S3-Kosten gestiegen sind und Sie der Ursache auf den Grund gehen wollen, ist möglicherweise die Versioning-Funktion Ihres S3-Buckets aktiviert. Kein Grund zur Sorge: Sie können diese Funktion steuern und die volle Kontrolle über Ihren S3-Bucket samt Versioning-Kosten zurückgewinnen. Dieser Artikel zeigt, welche Kosten ein versionierter S3-Bucket verursacht und wie Sie diese wirksam in den Griff bekommen. So optimieren Sie Ihren S3-Bucket und zahlen nur noch für den Speicher, den Sie tatsächlich brauchen.
S3 Versioning ist eine praktische Funktion, mit der Sie mehrere Versionen desselben Objekts in einem Bucket vorhalten. Damit haben Sie jederzeit Zugriff auf frühere Versionen von Objekten, die versehentlich gelöscht oder überschrieben wurden. Mit S3 Versioning lassen sich mehrere Versionen eines Objekts in einem Bucket speichern und bei Bedarf jede beliebige Version wiederherstellen.
Ein Beispiel: Aktivieren Sie S3 Versioning für einen Bucket, wird ein gelöschtes Objekt nicht endgültig entfernt. Stattdessen setzt Amazon S3 einen Delete Marker, der zur aktuellen Objektversion wird. Die vorherige Version können Sie jederzeit wiederherstellen.
Ähnlich beim Überschreiben: Amazon S3 fügt dem Bucket eine neue Objektversion hinzu. Die bisherige Version bleibt erhalten und wird zu einer noncurrent Version, die Sie jederzeit wiederherstellen können. Mehr dazu im Artikel zum Löschen von Objektversionen aus einem Versioning-aktivierten Bucket.
Es gibt viele Gründe, warum Versioning für einen S3-Bucket aktiviert wird. Wichtig zu wissen: Einmal aktiviert, lässt sich Versioning nicht mehr abschalten. Sie können es aber suspendieren und das Versioning Ihres Buckets nachhaltig verwalten. Lassen Sie sich nicht von unerwarteten S3-Kosten ausbremsen – mit den richtigen Schritten bekommen Sie Ihren S3-Bucket und Ihre Versioning-Kosten effizient in den Griff.
Wer mehrere Buckets mit Millionen von Objekten betreibt, verliert schnell den Überblick. Hier hilft AWS Storage Lens: Das Tool zeigt, welche Buckets versionierte Objekte enthalten, wie viele es sind und welcher Anteil Ihrer Objekte noncurrent ist. Außerdem sehen Sie, in welchem Storage Tier die noncurrent Objekte liegen. Details dazu finden Sie im folgenden Artikel zur Nutzung von AWS Storage Lens.
Mit diesen Daten verstehen Sie Ihre Versioning-Kosten schneller und können Ihren Speicher gezielter verwalten – etwa indem Sie Volumen und Storage Tier der noncurrent Versionen im Auge behalten. Die Preise sind identisch mit denen der aktuellen versionierten Kopie. Das folgende Beispiel zeigt, wie sich noncurrent Versionen über die Zeit summieren und die Kosten in die Höhe treiben.
Angenommen, Sie haben ein 4 GiB großes Objekt, das fünfmal pro Tag aktualisiert wird. Das ergibt täglich fünf noncurrent Versionen plus eine aktuelle Version – also sechs insgesamt. Multipliziert mit durchschnittlich 30 Tagen pro Monat ergeben fünf Änderungen pro Tag × 30 Tage = 150 noncurrent Versionskopien. Das summiert sich rasch, und je nach Storage Tier der nicht versionierten Objekte zahlen Sie den entsprechenden Preis.
Noch ein Beispiel: Bei einer 1-MB-Datei mit 200 Kopien (noncurrent Versionen) zahlen Sie für 200 MB Speicher.
Sobald Sie wissen, in welchen Buckets Versioning aktiv ist und welche Objekte bereits noncurrent Versionen haben, lohnt sich ein kurzer Check: Bringen diese Kopien wirklich einen Mehrwert? Fragen Sie sich: "Brauche oder will ich Kopien dieses Objekts?" Lautet die Antwort ja, schließt sich die nächste Frage an: Wie lange müssen die Kopien aufbewahrt werden – und wie viele davon? Aus den Antworten ergeben sich die Aufbewahrungskosten und der Automatisierungsaufwand für die Übergänge der Objekte. Nehmen Sie sich also Zeit, das passende Vorgehen für Ihre Anforderungen zu definieren. Nicht jeder Bucket ist gleich.
Wenn Sie auf einem Bucket kein Versioning brauchen, gehen Sie wie unten beschrieben vor: Versioning suspendieren, nicht versionierte Kopien entfernen und nicht benötigte Delete Marker löschen. So sparen Sie Kosten und erhalten einen quasi-deaktivierten versionierten Bucket.
HINWEIS: Bevor Sie das beschriebene Verfahren ausführen, beachten Sie: Sobald Sie die noncurrent Dateien gelöscht haben, sind alle noncurrent Kopien des Objekts unwiderruflich verloren – eine Wiederherstellung ist nicht möglich. Vergewissern Sie sich daher, dass Sie sich im richtigen S3-Bucket befinden, und überlegen Sie genau, ob Sie die noncurrent Versionen wirklich nicht mehr benötigen, bevor Sie etwas löschen. Testen Sie das Vorgehen am besten zunächst an einem Test-Bucket.
- Suchen Sie in der AWS S3 Console den Bucket, für den Sie Versioning suspendieren möchten, und wählen Sie ihn aus.
- Wechseln Sie in den Tab Properties.
- Suchen Sie im Tab Properties den Abschnitt Versioning und klicken Sie auf Edit.
Properties des S3-Buckets
4. Wählen Sie den Radio Button Suspend.
5. Aktivieren Sie das Kästchen I acknowledge the outcomes of suspending Bucket Versioning.
6. Klicken Sie auf Save changes.
7. Versioning ist nun für den Bucket suspendiert.
- Durch das Suspendieren werden keine neuen Versionen der Objekte mehr erstellt.
- Auf bestehende Objekte im Bucket hat das Suspendieren keinerlei Auswirkungen.
Bucket Versioning Suspend oder Enable
Im nächsten Schritt entfernen Sie die noncurrent Versionen sowie abgelaufene Delete Marker. Gerade bei Millionen von Dateien hat sich die Lifecycle Configuration als gängiger Weg etabliert. In unserem Beispiel nutzen wir den von AWS empfohlenen Ansatz – es gibt aber auch Alternativen. Eine Übersicht finden Sie hier.
Wechseln Sie weiterhin im S3-Bucket in den Tab Management.
Im Management-Bereich gibt es einen Abschnitt namens Lifecycle Rules. Klicken Sie auf Create lifecycle rule.
S3 Management Lifecycle Rules
- Füllen Sie unter Create lifecycle rule die folgenden Felder aus:
Lifecycle rule name: Wählen Sie einen Namen, der den Zweck der Regel klar beschreibt.
Zum Beispiel DeleteNV-1days-DeleteMarker-IMU-7days. Der Name macht deutlich: Nicht versionierte Kopien werden nach einem Tag gelöscht, Delete Markers und unvollständige Multipart Uploads nach sieben Tagen. 2. Wählen Sie unter Choose a rule scope den Radio Button "Apply to all objects in the bucket." Es erscheint ein Hinweisfeld mit einer Warnung. Lesen Sie diese und aktivieren Sie "I acknowledge that this rule will apply to all objects in the bucket." Auf die Option, den Geltungsbereich der Regel mit einem oder mehreren Filtern einzuschränken, gehen wir weiter unten ein. 3. Aktivieren Sie unter Lifecycle rule actions die Kästchen Permanently delete noncurrent versions of objects und Delete expired object delete markers or incomplete multipart uploads. 4. Es erscheinen zwei neue Abschnitte: Permanently delete noncurrent versions of objects sowie Delete expired object delete markers or incomplete multipart upload. 5. Geben Sie unter Permanently delete noncurrent versions of objects im Feld Days after objects become noncurrent den Wert 1 ein. Die Zahl muss größer als null sein. Hier kommt die zuvor diskutierte Frage ins Spiel, wie lange noncurrent Objekte aufbewahrt werden sollen. Das Feld rechts daneben, Number of newer version to retain — Optional, lassen Sie leer. Erinnern Sie sich an die Frage "Wie viele Versionen muss ich aufbewahren?" – genau hier tragen Sie diese Anzahl ein. Es werden dann immer so viele Kopien bzw. noncurrent Versionen vorgehalten. 6. Es folgen die Abschnitte Delete expired object delete marker und Delete incomplete multipart uploads. Aktivieren Sie die Kästchen Delete expired object delete markers und Delete incomplete multipart uploads. Es erscheint ein neues Feld namens Number of days. Geben Sie 7 ein. Damit legen Sie fest, nach wie vielen Tagen unvollständige Multipart Uploads gelöscht werden. So bleibt einem unvollständigen Multipart Upload genügend Zeit, um sich abzuschließen, falls eine Wiederaufnahme nötig ist.
Konfiguration der Lifecycle-Regel
Lifecycle Rule Actions
Sie fragen sich vielleicht, warum wir die Option zum Löschen unvollständiger Multipart Uploads aktiviert haben. Das ist eine einfache und wirkungsvolle Maßnahme zur Kostensenkung – und sie lässt sich automatisch über die Lifecycle-Regel Ihres S3-Buckets einrichten. Denken Sie daran: Für unvollständige Multipart-Upload-Teile zahlen Sie entsprechend der Storage Class, die beim Upload der Teile angegeben wurde. Auch hier hilft S3 Storage Lens, um unvollständige Multipart Uploads zu analysieren. Mehr dazu im folgenden Artikel.
Hier noch weitere Hinweise von AWS zum Löschen noncurrent Versionen von Objekten.
A versioning-enabled bucket has one current version and zero or more noncurrent versions for each object. When you delete an object, note the following:
If you don't specify a version ID in your delete request, Amazon S3 adds a delete marker instead of deleting the object. The current object version becomes noncurrent, and the delete marker becomes the current version.
If you specify a version ID in your delete request, Amazon S3 deletes the object version permanently (a delete marker is not created).
A delete marker with zero noncurrent versions is referred to as an expired object delete marker. (source).
Glückwunsch – Sie haben Ihren versionierten S3-Bucket erfolgreich unter Kontrolle gebracht. Je nach gewählter Lifecycle Configuration sollten Sie nach etwa einer Woche sinkende Kosten sehen. Beachten Sie aber: Lifecycle Rules laufen asynchron, das Entfernen der noncurrent Versionsobjekte kann also etwas dauern. Keine Sorge – AWS berechnet Ihnen die zusätzlichen Tage, die der Vorgang braucht, nicht.
Sie können Versioning jetzt wieder aktivieren, da eine Lifecycle-Management-Regel die noncurrent Versionen automatisch übernimmt. Alternativ lassen Sie Versioning suspendiert, wenn Sie keine Versionen der Objekte benötigen. Bitte beachten Sie: Alle neuen Objekte, die bei suspendiertem Versioning in den S3-Bucket gelegt werden, erhalten einen Null-ID-Marker und kommen für Versioning nicht infrage.
Manchmal benötigen Sie Versioning für einen S3-Bucket, möchten Lifecycle Management aber nur auf bestimmte Objekte anwenden. Lifecycle Management erlaubt es, Regeln auf einzelne Präfixe anzuwenden. Diese Option heißt "Limit the scope of this rule using one or more filters." Mit Filtern legen Sie fest, welche noncurrent Objekte gelöscht werden. Ebenso lassen sich darüber unterschiedliche Lifecycle-Regeln für verschiedene Objekte definieren.
Sie können nach Speicherort filtern. Liegen Ihre Dateien zum Beispiel in einem logs-Ordner, setzen Sie den Filter auf logs/. Die Lifecycle-Regel greift dann für logs/log.txt, logs/temp3.txt und logs/test1.txt – nicht jedoch für ein Objekt namens example.jpg im Stammverzeichnis. Auch nach Dateiendungen, Tags oder Objektgröße können Sie filtern. Weitere Informationen und Beispiele zur Filterung finden Sie im folgenden Artikel.
Sie haben jetzt das nötige Rüstzeug, um S3-Kosten rund um noncurrent Objektversionen aktiv zu steuern. Empfehlenswert ist es, Änderungen immer zuerst in einer Test- oder Entwicklungsumgebung auszuprobieren, bevor sie in Produktion gehen.
Ressourcen:
- Amazon S3 cost optimization for predictable and dynamic access patterns.
- Optimize storage costs with new Amazon S3 Lifecycle filters and actions.
- Examples of S3 Lifecycle Configuration.
- How can I reduce unexpected high costs for Amazon S3?
- Deleting object versions from a versioning-enabled bucket.
- Assessing your storage activity and usage with Amazon S3 Storage Lens.
- Options to delete millions of objects from a versioning-enabled AWS S3 bucket