Zusammenfassung

  • Eine Löschung ohne Versionskennung setzt bei aktiver S3-Versionierung einen Marker, statt Datenversionen dauerhaft zu entfernen. Ein gewöhnlicher Abruf kann 404 liefern, während ältere Versionen weiter gespeichert werden.
  • Ein abgelaufener Löschmarker ist der Rest nach dem Entfernen aller Datenversionen. Seine Bereinigung ersetzt nicht das Ablaufen nicht aktueller Daten, für das eigene Bedingungen gelten.
  • AWS unterscheidet tatsächlich abgelaufene Objekte mit asynchroner Entfernung ohne die zugehörige Speicherberechnung von lediglich unsichtbaren älteren Versionen. Mindestdauern bestimmter Klassen sind eine weitere Verpflichtung.

Zwei plausible Abschlussberichte

Das Anwendungsteam meldet, ein unerwünschtes Objekt sei nicht mehr nutzbar. Das Wiederherstellungsteam bewahrt seine Geschichte auf. Beide Ergebnisse können beabsichtigt sein. Die Unklarheit beginnt, wenn der erste Bericht zugleich als Beweis für das Ende der Speicherverpflichtung gilt.

AWS beschreibt in der Anleitung zum Löschen von Versionen die gewöhnliche Löschung bei aktivierter Versionierung: Ohne gezielte Versionskennung wird ein Löschmarker eingefügt, während die Datenversionen nicht dauerhaft entfernt werden. Der Marker wird aktuell, der bisherige Inhalt kann als nicht aktuelle Version bleiben.

Die Marker-Dokumentation erklärt dazu die normale Ansicht. Ein Abruf ohne Versionskennung liefert bei aktuellem Marker 404; gewöhnliche Objektlisten zeigen den entsprechenden Schlüssel nicht. Das belegt Abwesenheit für diesen Zugriff, nicht den vollständigen Versionsbestand.

Hier wurde keine Kundenrechnung untersucht, kein verstecktes Entgelt entdeckt und kein Abrechnungsfehler festgestellt. Es geht um eine öffentlich beschriebene Produkteigenschaft. Die Beschaffung muss deshalb zwischen dem Ende gewöhnlicher Nutzung und dem Ende bewusster Aufbewahrung unterscheiden.

Der kleine Marker ist nicht der ältere Inhalt

Laut AWS gelten die normalen Tarife für gespeicherte und übertragene Versionen einschließlich nicht aktueller Daten. Der Wechsel aus der sichtbaren Liste entfernt diese Einheit nicht automatisch aus der Berechnung. Weniger zugängliche Schlüssel beweisen keine entsprechende Verringerung gespeicherter Nutzdaten.

Der Marker selbst trägt keinen Dateninhalt. Seine Speicherung entspricht dem in UTF-8 kodierten Schlüsselnamen und erfolgt in S3 Standard. Diese geringe Belegung ist eine andere Größe als der Umfang älterer Datenversionen. Wer nur Marker zählt oder bereinigt, erklärt damit nicht notwendig den größeren Speicherbestand.

Ein älterer Bestand ist auch nicht automatisch Verschwendung. Er kann die gewünschte Möglichkeit erhalten, eine versehentliche Löschung oder Überschreibung zurückzunehmen. Die wirtschaftliche Frage lautet, wer diese Option noch benötigt und ihre Fortsetzung rechtfertigt. Dieser Artikel bewertet weder ihren Kundennutzen in Geld noch einen tatsächlich erzielten Spareffekt.

„Abgelaufen“ benennt einen Rest

Die Anleitung zur Markerverwaltung definiert einen abgelaufenen Objektlöschmarker als den einzigen verbleibenden Marker, nachdem alle Objektversionen gelöscht wurden. Den Rest zu entfernen ist nicht die Aktion, die die früheren Datenversionen entfernt. Die Definition setzt deren Abwesenheit bereits voraus.

Auch eine wiederholte gewöhnliche Löschung hat einen eigenen Effekt. Ist der Marker schon aktuell und wird seine Kennung nicht angegeben, kommt ein weiterer Marker hinzu. Entfernt man dagegen den aktuellen Marker, kann eine ältere Datenversion wieder aktuell und gewöhnlich sichtbar werden. Die Vorgänge lassen sich nicht wegen ähnlicher Namen als gleicher Kostennachweis behandeln.

Der Artikel führt keine dieser Operationen aus und bietet keine destruktive Anleitung. Für die Abnahme zählt die Erklärung des Berichts: Wurden unsichtbar gewordene Schlüssel, entfernte Marker oder dauerhaft beseitigte Datenversionen gezählt? „Gelöscht“ allein bezeichnet den Übergang nicht eindeutig.

Alter und Anzahl können zusammenwirken

Die Anleitung zum Ablauf von Objekten trennt aktuelle und nicht aktuelle Versionen. Bei aktivierter Versionierung kann der Ablauf der aktuellen Daten einen Marker schaffen und die Daten nicht aktuell machen. Andere nicht aktuelle Versionen laufen dadurch nicht automatisch mit ab.

Die Lifecycle-Konfigurationselemente beschreiben sowohl Tage seit dem Übergang in den nicht aktuellen Zustand als auch die Anzahl neuerer nicht aktueller Versionen. Sind beide Bedingungen konfiguriert, müssen beide Schwellen überschritten werden. Das Alter seit der ursprünglichen Erstellung ist nicht zwangsläufig das Alter als nicht aktuelle Version.

Eine Kurzbeschreibung als „so viele Tage behalten“ kann daher eine bewusst eingesetzte Anzahlbedingung verschweigen. Das dauerhafte Ablaufen nicht aktueller Daten ist durch diesen Mechanismus nicht rückgängig zu machen. Die Regelabnahme entscheidet über Wiederherstellbarkeit ebenso wie über Speicherumfang.

Die Object-Lock-Hinweise liefern eine weitere Grenze. Lifecycle kann weiterhin Marker setzen und Speicherklassen wechseln, aber eine geschützte Version nicht durch eine Ablaufrichtlinie löschen. Marker selbst sind nicht WORM-geschützt. Gewöhnliche Abwesenheit und geschützte Aufbewahrung können somit absichtlich nebeneinander bestehen. Das beweist weder die Vernichtung der geschützten Daten noch ein Versagen ihres Schutzes.

Die physische Warteschlange ist kein Gebührenbeweis

Die Kostenargumentation braucht eine ausdrückliche Einschränkung. AWS sagt, dass tatsächlich abgelaufene Objekte auf ihre asynchrone physische Entfernung warten können, ohne Entgelt für den Ablauf oder die zugehörige Speicherzeit des abgelaufenen Objekts. Eine verzögerte Entfernung allein ist kein Nachweis weiterlaufender Speicherberechnung.

Diese Ausnahme lässt sich aber nicht pauschal auf alle Versionen hinter einem Marker übertragen. Entscheidend ist, ob die jeweilige Version ihre Bedingungen erfüllt hat. Die Anleitung nennt auch ausstehende oder fehlgeschlagene Replikation als Zustände, in denen die betreffende Lifecycle-Aktion nicht erfolgt. Kundenregeln und Versionszustände wurden hier nicht geprüft.

Die S3-Preisseite beschreibt ein anderes Thema: Mindestspeicherdauern von 30 Tagen für Standard-IA und One Zone-IA, 90 Tagen für Glacier Instant Retrieval und Flexible Retrieval sowie 180 Tagen für Deep Archive. Frühe Löschung, Überschreibung oder Klassenwechsel können eine anteilige Gebühr für die verbleibende Mindestdauer erzeugen. Das ist keine universelle 30-Tage-Regel für S3 Standard.

DELETE- und CANCEL-Anfragen sind laut derselben Seite kostenlos. Ein kostenloser Request macht erhaltene Versionen und anwendbare Mindestverpflichtungen nicht kostenlos. Regionale Stückpreise, eine konkrete Rechnung oder Einsparungen werden nicht errechnet.

Der wirtschaftliche Bestand braucht Gründe

Das Storage-Lens-Metrikglossar trennt nicht aktuelle Datenbytes von Markerbytes. Die Zahl aktueller Objekte enthält aktuelle Marker; „aktuell“ darf deshalb nicht einfach als „zugängliche Datei“ gelesen werden. Kostenlose Metriken werden täglich erhoben, nicht als Sofortnachweis jedes Übergangs.

Storage Lens berücksichtigt tatsächlich abgelaufene, noch nicht entfernte Objekte in den betreffenden Metriken nicht. Die Berichtsgrenze ist kein vollständiges Bild physisch vorhandener Bytes und weder eine Rechnung noch eine Echtzeituntersuchung. Mit dieser Einschränkung helfen die Zahlen, die richtigen Erklärungen anzufordern.

Für den Käufer ist die Abnahme eine Zuordnung von Versionszuständen und Gründen: gewünschte Wiederherstellung, Schutz, noch nicht erreichte Bedingungen oder tatsächlicher Ablauf. Eine 404 gehört zu einer anderen Beobachtung. Versionierung ist nützlich, weil Abwesenheit nicht sofort unumkehrbar sein muss. Aus demselben Grund beweist Abwesenheit nicht das Ende der wirtschaftlichen Aufbewahrung.

Quellen