Cloud Intelligence™Cloud Intelligence™

Cloud Intelligence™

AWS S3 Multipart Uploads: versteckte Kosten unvollständiger Uploads vermeiden

By Avi KeinanJun 18, 20215 min read

Diese Seite ist auch in English, Español, Français, Italiano, 日本語 und Português verfügbar.

Beim Upload einer Datei größer als 5 MB in einen AWS S3 Bucket teilt das AWS SDK bzw. die CLI den Vorgang automatisch in mehrere HTTP-PUT-Requests auf. Das ist effizienter, ermöglicht fortsetzbare Uploads – und falls ein Part fehlschlägt, wird nur dieser erneut übertragen, ohne den Gesamtfortschritt zu unterbrechen.

Lassen Sie nach Ihren Uploads zu AWS S3 keine Überreste zurück.

Bei Multipart Uploads lauert allerdings eine Falle:

Wird Ihr Upload abgebrochen, bevor das Objekt vollständig übertragen ist, zahlen Sie für die bereits hochgeladenen Object Parts so lange, bis Sie diese löschen.

Daraus entstehen versteckte Speicherkosten, die nicht sofort auffallen.

Im Folgenden erfahren Sie, wie Sie hochgeladene Object Parts identifizieren und Ihre Kosten senken, wenn unvollständige Multipart Uploads vorliegen.

Bild aus dem Blogbeitrag von Jeff Barr

Wie finde ich hochgeladene Object Parts in der AWS S3 Console?

Und genau hier wird es spannend: Diese Objekte sehen Sie in der AWS S3 Console nicht.

Für diesen Artikel habe ich einen S3 Bucket angelegt und eine 100-GB-Datei hochgeladen. Den Upload habe ich nach 40 GB abgebrochen.

In der S3 Console waren daraufhin 0 Objekte im Bucket zu sehen – die bereits per Multipart übertragenen 40 GB tauchten dort nicht auf.

Anschließend habe ich auf den Tab Metrics geklickt – und dort betrug die Bucket-Größe 40 GB.

Es kann mehrere Stunden dauern, bis aktualisierte Metriken sichtbar werden.

Das heißt: Auch wenn das Objekt in der Console nicht sichtbar ist, weil der Upload nicht abgeschlossen wurde, zahlen Sie weiterhin für die bereits übertragenen Parts.

Wie wird das in der Praxis gehandhabt?

Ich habe mit mehreren Kollegen aus verschiedenen Unternehmen gesprochen, die AWS-Accounts mit erheblicher monatlicher S3-Nutzung betreiben.

Die meisten hatten zwischen über 100 MB und über 10 TB an unvollständigen Multipart Uploads angesammelt. Der Tenor: Je größer die S3-Nutzung und je älter der Account, desto mehr unvollständige Objekte schlummern dort.

Multipart-Größe eines einzelnen Objekts berechnen

Listen Sie zunächst über die AWS CLI die aktuellen Multipart-Objekte mit folgendem Befehl auf:

aws s3api list-multipart-uploads --bucket <bucket-name>

Das Ergebnis ist eine Liste aller unvollständigen Objekte mit mehreren Parts:

Listen Sie anschließend alle Parts des Multipart Uploads mit dem Befehl list-parts und dem Wert "UploadId" auf:

aws s3api list-parts --upload-id 5IBStnpJl6REH... --bucket <bucket-name> --key example.exe

Summieren Sie als Nächstes die Größen (in Byte) aller hochgeladenen Parts und rechnen Sie das Ergebnis mit jq (einem JSON-Prozessor für die Kommandozeile) in GB um:

jq '.Parts | map(.Size/1024/1024/1024) | add'

Möchten Sie ein Multipart-Upload-Objekt manuell löschen, nutzen Sie folgenden Befehl:

aws s3api abort-multipart-upload --bucket <bucket-name> --key example.exe --upload-id 5IBStnpJl6REH...

So vermeiden Sie Kosten für unvollständige Multipart Uploads

Auf Bucket-Ebene können Sie eine Lifecycle-Regel einrichten, die unvollständige Multipart-Objekte nach einigen Tagen automatisch löscht.

"Eine S3 Lifecycle-Konfiguration ist ein Satz von Regeln, der Aktionen definiert, die Amazon S3 auf eine Gruppe von Objekten anwendet." (AWS-Dokumentation).

Im Folgenden zwei Lösungen:

  • eine manuelle Lösung für bestehende Buckets und
  • eine automatische Lösung für neu angelegte Buckets.

Multipart Uploads in bestehenden Buckets löschen

Bei dieser Variante richten Sie eine Object-Lifecycle-Regel ein, um alte Multipart-Objekte aus einem bestehenden Bucket zu entfernen.

Achtung: Gehen Sie beim Definieren einer Lifecycle-Regel sorgfältig vor. Ein Fehler in der Definition kann bestehende Objekte in Ihrem Bucket löschen.

Öffnen Sie zunächst die AWS S3 Console, wählen Sie den gewünschten Bucket aus und wechseln Sie zum Tab Management.

Klicken Sie unter Lifecycle rules auf Create lifecycle rule.

Vergeben Sie einen Namen für die Lifecycle-Regel und legen Sie als Geltungsbereich alle Objekte im Bucket fest.

Aktivieren Sie das Kontrollkästchen "I acknowledge that this rule will apply to all objects in the bucket".

Wechseln Sie als Nächstes zu Lifecycle rule actions und aktivieren Sie das Kontrollkästchen "Delete expired delete markers or incomplete multipart upload".

Aktivieren Sie das Kontrollkästchen "Delete incomplete multipart uploads" und stellen Sie die Number of days nach Ihrem Bedarf ein (drei Tage reichen meiner Erfahrung nach aus, um laufende Uploads abzuschließen).

Nach erfolgreicher Umsetzung der Schritte werden die hochgeladenen Multipart-Dateien gelöscht – allerdings nicht sofort, sondern mit etwas Verzögerung.

Zwei Hinweise:

  • Löschvorgänge sind kostenlos.
  • Sobald die Lifecycle-Regel definiert ist, fallen für die zur Löschung vorgesehenen Daten keine Kosten mehr an.

Lifecycle-Regel für neue Buckets erstellen

Mit dieser Variante richten Sie eine Lifecycle-Regel ein, die automatisch bei jedem neu angelegten Bucket angewendet wird.

Dafür kommt ein schlankes Lambda-Automatisierungsskript zum Einsatz, das bei jedem neu erstellten Bucket ausgelöst wird. Diese Lambda-Funktion legt eine Lifecycle-Regel an, die alle Multipart-Objekte löscht, die älter als 3 Tage sind.

Hinweis: Da EventBridge nur in der Region läuft, in der es erstellt wurde, müssen Sie die Lambda-Funktion in jeder Region bereitstellen, in der Sie tätig sind.

S3 Management Console – Video ansehen

So setzen Sie diese Automatisierung um

  1. Aktivieren Sie einen AWS CloudTrail Trail. Sobald der Trail konfiguriert ist, können Sie über AWS EventBridge eine Lambda-Funktion auslösen.
  2. Legen Sie eine neue Lambda-Funktion mit Python 3.8 als Runtime an.
  3. Fügen Sie den unten stehenden Code (GitHub Gist) ein.

4. Wählen Sie create function.

5. Scrollen Sie zum Seitenanfang, klicken Sie unter Trigger auf "Add trigger" und wählen Sie als Trigger-Konfiguration EventBridge.

Erstellen Sie anschließend eine neue Regel und vergeben Sie Namen und Beschreibung.

6. Wählen Sie als Regeltyp Event pattern und in den beiden folgenden Feldern Simple Storage Services (S3) sowie AWS API call via CloudTrail.

Wählen Sie im Feld Detail unter Operation den Eintrag CreateBucket.

Scrollen Sie nach unten und klicken Sie auf Add.

7. Scrollen Sie zum Tab Basic settings, wählen Sie Edit → IAM role und hängen Sie die unten angegebene Policy an.

Diese Policy erlaubt der Lambda-Funktion, eine Lifecycle-Konfiguration für alle Buckets im AWS-Account anzulegen.

{
    "Version": "2012-10-17",
    "Statement": [\
        {\
            "Sid": "VisualEditor0",\
            "Effect": "Allow",\
            "Action": "s3:PutLifecycleConfiguration",\
            "Resource": "*"\
        }\
    ]
}

8. Legen Sie einen Bucket an, um zu prüfen, ob die Lambda-Funktion korrekt arbeitet.

9. Fertig! Ab jetzt legt die Lambda-Funktion bei jedem neu angelegten Bucket (in der konfigurierten Region) automatisch eine Lifecycle-Regel an.

Vielen Dank fürs Lesen! Bleiben Sie mit uns in Kontakt – im DoiT Engineering Blog, auf dem DoiT LinkedIn-Kanal und auf dem DoiT Twitter-Kanal. Karrieremöglichkeiten finden Sie unter https://careers.doit-intl.com.