S3 vermietet Platz an Uploads ohne Zukunft

Zusammenfassung

• Bereits übertragene Teile eines S3-Uploads bleiben bis zum Abschluss oder Abbruch gespeichert und kosten Speichergebühren. Ein gescheiterter Anwendungsauftrag beendet diese Speicherung nicht.
• Für allgemeine Buckets lässt sich eine Aufräumfrist einrichten. Die dokumentierten sieben Tage sind ein Beispiel; Directory Buckets unterstützen diese Lifecycle-Konfiguration nicht.

Die Kostenstelle hat keinen Film bekommen. Sie kann trotzdem für dessen Einzelteile zahlen. Bei Amazon S3 beginnt wirtschaftlich relevante Speicherung schon vor dem fertigen Objekt: Ein mehrteiliger Upload legt Teile ab, die auf den Abschluss warten. Wenn niemand mehr abschließen will, wartet der Speicher weiter.

AWS dokumentiert diesen Zustand offen. Teile lassen sich unabhängig übertragen und nach einem Fehler gezielt erneut senden. Erst der Abschluss setzt sie zum Objekt zusammen. Bis zum Abschluss oder Abbruch werden die bereits gespeicherten Teile berechnet; der begonnene Upload hat von sich aus kein Ablaufdatum. AWS-Dokumentation zum mehrteiligen Upload.

Das Angebot ist vernünftig. Wer eine große Datei über eine unzuverlässige Verbindung transportiert, möchte nach einer Unterbrechung nicht wieder bei null anfangen. S3 bewahrt den Fortschritt. Der Käufer bezahlt damit eine Fortsetzungsmöglichkeit. Dass diese Möglichkeit technisch besteht, beantwortet allerdings noch keine Frage nach ihrer verbleibenden Verwendung.

Wer bestellt die nächste Woche Geduld?

Man stelle sich eine Produktionsfirma vor, deren Auftrag mitten in der Übertragung gestrichen wird. Das ist ein Gedankenbeispiel, kein berichteter Kundenfall. Das Team schließt die Aufgabe und plant die nächste Lieferung. Die angekommenen Teile erhalten durch diese Geschäftsentscheidung keinen automatischen Räumungsbefehl.

Bei einem weiter benötigten Auftrag kann dieselbe Geduld wertvoll sein. Vielleicht muss das sendende Gerät zurückkehren, vielleicht steht die Fortsetzung bereits fest. Dann ist gespeicherter Fortschritt ein Mittel zur Lieferung. Nach einer endgültigen Absage fehlt diese Funktion. Die Bytes haben sich nicht verändert, ihr Zweck schon.

Hier liegt eine kleine Beschaffungsentscheidung, die in vielen Kostenmodellen keinen eigenen Namen bekommt: Wie lange kaufen wir die Chance, genau diesen Versuch fortzusetzen? Eine Frist zwingt zur Antwort. Unbegrenztes Warten lässt die letzte technische Entscheidung immer wieder auf Kosten des heutigen Budgets gewinnen.

Ein Beispielwert übernimmt keine Verantwortung

Für allgemeine S3-Buckets beschreibt AWS die Lifecycle-Aktion AbortIncompleteMultipartUpload. Nach einer festgelegten Zahl von Tagen seit Beginn kommt der unvollständige Upload für den Abbruch infrage; S3 beendet ihn und entfernt die Teile. Die Regel erfasst bestehende und spätere Uploads in ihrem Geltungsbereich, nicht die Löschung fertiger Objekte. Sieben Tage sind in der Anleitung ein Beispiel, das konfiguriert werden muss. AWS-Anleitung zur Bereinigung.

Eine kurze Frist beendet aufgegebene Versuche früher. Sie kann ebenso Fortschritt vernichten, dessen Fortsetzung noch sinnvoll war. Eine lange Frist hält mehr Möglichkeiten offen und bezahlt deren Lagerung länger. Die Zahl verdient deshalb eine Begründung aus dem Arbeitsablauf, nicht bloß einen Platz in einer technischen Vorlage.

Bei diesen unvollständigen Teilen fallen laut AWS keine Gebühren für vorzeitige Löschung an. Zu frühes Aufräumen kann dennoch teuer werden: Die Übertragung muss erneut erfolgen, Personal muss sich nochmals darum kümmern, die Lieferung wartet. Umgekehrt beendet ein erfolgreicher Abschluss die gesonderte Teilespeicherung, hinterlässt aber ein fertiges Objekt mit eigenen Speichergebühren.

Der letzte Teil kommt nach dem Schlussstrich

Beim manuellen Abbruch gibt es einen Grund, auf das Ergebnis zu schauen. Bereits laufende Teileübertragungen können danach noch erfolgreich enden oder scheitern. AWS nennt deshalb die Möglichkeit mehrerer Abbrüche, bis der gesamte Teilespeicher freigegeben ist, und empfiehlt die Kontrolle einer leeren Teileliste mit ListParts. API-Beschreibung für AbortMultipartUpload.

Für die Unternehmensführung ist daran die Zuständigkeit interessanter als der Befehlsname. Ein Auftrag kann fachlich beendet sein, während ein sendender Prozess noch arbeitet. Jemand muss beide Enden zusammenführen. Sonst meldet jeder Bereich seinen Schritt als erledigt, ohne dass jemand für den letzten verbleibenden Speicher verantwortlich ist.

Auch die Produktvariante setzt Grenzen. Directory Buckets speichern und berechnen unvollständige Teile ebenfalls, unterstützen aber keine S3-Lifecycle-Konfigurationen. Vor dem Löschen eines solchen Buckets müssen alle laufenden mehrteiligen Uploads abgeschlossen oder abgebrochen werden. AWS zu Directory Buckets. Eine für allgemeine Buckets zugesagte Bereinigung lässt sich daher nicht mit unverändertem Versprechen auf diese Variante übertragen.

Für eine bezifferte Verschwendung fehlen hier der Teilebestand, seine noch bestehenden Zwecke und die tatsächlichen Kundenrechnungen; eine geplante, nützliche Fortsetzung würde die Bewertung ändern. Schon jetzt ist die kaufmännische Frage klar: Welcher Auftrag kauft diese Geduld noch?

Ein fertiges Produkt hat meist einen Abnehmer. Ein aufgegebener Upload braucht wenigstens jemanden, der seine Miete kündigt. Sonst überlebt ausgerechnet das erfolglose Vorhaben seine eigene Budgetbesprechung.