Bild von Molnia
Beim Betrieb von Amazon-S3-Buckets sind exakte Speichermetriken entscheidend für Kostenmanagement und Kapazitätsplanung. Doch die ausgewiesenen Speichergrößen weichen mitunter voneinander ab – das sorgt für Verwirrung und kann zu Fehlern in der Kostenschätzung führen. Dieser Artikel beschreibt einen realen Kundenfall, in dem verschiedene AWS-Tools für denselben S3-Bucket stark unterschiedliche Speichergrößen meldeten, und zeigt, wie sich der tatsächliche Speicherverbrauch korrekt ermitteln lässt.
Bei der Überprüfung der S3-Speichermetriken eines bestimmten Buckets stieß einer unserer Kunden auf eine erhebliche Diskrepanz:
- S3-Metriken & CloudWatch: über 220 TB Speicher gemeldet
- AWS CLI & S3-Option "Calculate total size": weniger als 8 TB Speicher angezeigt
Dieser 27-fache Unterschied bei der ausgewiesenen Speichergröße warf sofort Fragen zur Datenqualität und zu möglichen Kostenfolgen auf.
Bei der Analyse stellten wir folgende Bucket-Einstellungen fest:
- Storage Class: alle Objekte in S3 Standard
- Versioning: für den Bucket nicht aktiviert
- Lifecycle-Regel: konfiguriert, um Objekte nach 45 Tagen zu löschen
Diese Einstellungen erklärten den enormen Unterschied bei den gemeldeten Speichergrößen zunächst nicht – also haben wir genauer nachgeforscht.
Zur Bestätigung der Diskrepanz prüften wir zuerst den S3-Bucket und die CloudWatch-Metriken:
- S3-Konsole: Speichermetriken des Buckets gesichtet
- CloudWatch: zugehörige Metriken für den Bucket untersucht
Beide Quellen meldeten übereinstimmend über 200 TB an Daten im Bucket.
S3-Bucket-Metriken
CloudWatch-Metriken
Um der Sache weiter auf den Grund zu gehen, haben wir den Speicher des Buckets mit zwei zusätzlichen Methoden gemessen:
- Funktion "Calculate total size" in der S3-Konsole
- AWS-CLI-Befehl zum Auflisten der Bucket-Inhalte
Sowohl "Calculate total size" als auch der AWS-CLI-Befehl ergaben 7,5 TB Speicher und über 6 Millionen Objekte im Bucket.
"Calculate total size" auf den S3-Bucket angewendet.
Ergebnis von "S3 Calculate Total"
AWS-CLI-Befehl zur Berechnung der Bucket-Größe:
aws s3 ls — summarize — human-readable — recursive s3://
Dieser CLI-Befehl listet alle Objekte im angegebenen Bucket auf und liefert eine Zusammenfassung der Gesamtgröße.
Ausgabe der AWS CLI
Der krasse Gegensatz zwischen den gemeldeten Speichergrößen gab uns ein Rätsel auf: Wie kann ein und derselbe Bucket so unterschiedliche Datenmengen anzeigen? Die Diskrepanz musste geklärt werden, denn sie kann Kostenmanagement und Speicherplanung erheblich beeinflussen. Wir gingen wie folgt vor:
- S3 Storage Lens aktivieren: Wir empfahlen dem Kunden, Amazon S3 Storage Lens zu aktivieren – eine leistungsstarke Analysefunktion für Cloud-Speicher. Sie liefert organisationsweite Einblicke in die Nutzung von Objektspeicher und in Aktivitätstrends.
- Auf die Datenerfassung warten: Wichtig zu wissen: Es kann bis zu 24 Stunden dauern, bis S3 Storage Lens Metriken erfasst und veröffentlicht.
- Ergebnisse auswerten: Sobald die Daten verfügbar waren, haben wir das S3-Storage-Lens-Dashboard sorgfältig ausgewertet. Die Erkenntnisse daraus waren für unsere Untersuchung Gold wert.
S3 Storage Lens zeigt die Gesamtgröße der Incomplete Multipart Uploads.
S3 Storage Lens zeigte: Ursache der Diskrepanz waren S3 Incomplete Multipart Uploads.
S3 Incomplete Multipart Uploads sind Teile von Objekten, die zwar teilweise hochgeladen, aber nie abgeschlossen wurden. Entscheidend dabei: Diese unvollständigen Uploads belegen Speicher und verursachen Kosten – obwohl sie in den Standard-Bucket-Listings nicht auftauchen.
Die Incomplete Multipart Uploads umfassten über 200 TB. Die Abweichung zwischen den Tools entsteht, weil weder die Funktion "Calculate total size" in der S3-Konsole noch die AWS CLI Incomplete Multipart Uploads berücksichtigen.
Mit dieser Erkenntnis ließ sich der deutliche Unterschied zwischen den gemeldeten Speichergrößen erklären – und ein klarer Weg zur Optimierung der S3-Speichernutzung des Kunden aufzeigen.
Um den Kunden beim Aufräumen des Buckets zu unterstützen, richteten wir die S3-Lifecycle-Regel "delete-incomplete-mpu-7-days" ein, die Incomplete Multipart Uploads automatisch entfernt.
S3-Lifecycle-Regel zum Löschen von Incomplete Multipart Uploads
Nachdem die Lifecycle-Regel "delete-incomplete-mpu-7-days" einige Tage gelaufen war und die CloudWatch-Metriken nachgezogen hatten, prüften wir die Bucket-Metriken erneut. Die Lifecycle-Regel hatte funktioniert und sämtliche Incomplete Multipart Uploads entfernt. Bei der anschließenden Kontrolle mit denselben Tools meldeten alle Quellen einheitliche Werte für den Bucket.
S3-Bucket-Metriken nach Anwendung der Lifecycle-Regel
CloudWatch-Metriken nach Anwendung der Lifecycle-Regel
"Calculate total size" in S3 nach Anwendung der Lifecycle-Regel "delete-incomplete-mpu-7-days".
"Calculate total size" auf den S3-Bucket angewendet.
S3 "Calculate total size" nach Anwendung der Lifecycle-Regel
Skript mit AWS CLI zur Berechnung der Bucket-Größe nach Anwendung der S3-Lifecycle-Regel
Diese Fallstudie ist nur ein Beispiel für die komplexen Herausforderungen, denen Unternehmen beim Betrieb ihrer AWS-Umgebungen begegnen. Dank unserer Expertise rund um AWS-Services und unserer Erfahrung im Auswerten und Interpretieren von Cloud-Metriken konnten wir die eigentliche Ursache der Speichergrößen-Diskrepanz identifizieren und eine wirksame Lösung umsetzen. Damit war nicht nur das akute Problem gelöst – der Kunde hat zugleich ein deutlich tieferes Verständnis seiner S3-Nutzung und -Kosten gewonnen.
Bei DoiT International unterstützen wir Unternehmen dabei, sich in komplexen Cloud-Umgebungen zurechtzufinden, Probleme zu beheben und ihre AWS-Infrastruktur zu optimieren. Ob ähnliche Diskrepanzen bei Speichermetriken oder andere Cloud-Themen: Unser Expertenteam steht bereit. Lassen Sie sich von Cloud-Komplexität nicht ausbremsen. Kontaktieren Sie DoiT noch heute und besprechen Sie mit uns, wie Sie Ihre Cloud-Umgebung effizienter und kostenoptimierter aufstellen – damit Sie den maximalen Wert aus Ihrem AWS-Investment ziehen.