S3-Speicherkostenoptimierung in der Praxis: Von Abrechnungsdimensionen bis zu 7 konkreten Maßnahmen

Viele Teams starren bei der S3-Rechnung nur darauf, „wie viele TB gespeichert sind“. Die tatsächlichen S3-Kosten setzen sich jedoch meist aus vier Gebührenkategorien zusammen: Speicherkapazität, Anzahl der Anfragen, Datentransfer und Verwaltungsfunktionen. Auch die Optimierung sollte aus diesen vier Dimensionen heraus betrachtet und aufgeschlüsselt werden, anstatt einfach alle Buckets in eine kältere Speicherklasse zu verschieben.

Die folgenden Preise gelten beispielhaft für us-east-1, die tatsächlichen Preise hängen von der jeweiligen AWS-Region ab: S3 Standard kostet für die ersten 50TB ca. $0.023/GB-month; Standard-IA ca. $0.0125/GB-month; Glacier Instant Retrieval ca. $0.004/GB-month; Glacier Deep Archive ca. $0.00099/GB-month. Obwohl Deep Archive deutlich günstiger erscheint, hat es eine Mindestspeicherdauer, Wiederherstellungszeiten und Wiederherstellungsgebühren, weshalb man nicht blind dorthin migrieren sollte.

1. Zuerst die Herkunft der Kosten klären

Es empfiehlt sich, die Kosten im Cost Explorer zunächst nach Usage type aufzuschlüsseln:

• TimedStorage-ByteHrs: Speicherkapazität für Objekte.
• Requests-Tier1/Tier2: PUT-, LIST-, GET- und andere Anfragen.
• DataTransfer-Out-Bytes: Transfer in das öffentliche Internet oder in andere Regionen.
• Monitoring-Automation, Inventory, StorageLens: Verwaltungs- und Analysefunktionen.

Ein häufiges Missverständnis: Die Speichergebühren sind zwar niedrig, aber es gibt viele LIST/GET-Anfragen, oder der Zugriff aus einem privaten Subnetz auf S3 erfolgt über ein NAT Gateway, was die Netzwerkrechnung in die Höhe treibt. Betrachten Sie bei der S3-Optimierung nicht nur die Bucket-Größe.

2. Intelligent-Tiering und Lebenszyklusregeln

Wenn die Zugriffsmuster auf Objekte unvorhersehbar sind, ist S3 Intelligent-Tiering ein risikoarmer Ausgangspunkt. Es verschiebt Objekte automatisch zwischen den Ebenen Frequent, Infrequent und Archive Instant. Zwischen den automatischen Ebenen fallen keine Wiederherstellungsgebühren an, jedoch wird eine Überwachungs- und Automatisierungsgebühr erhoben, die typischerweise bei $0.0025/1,000 objects-month liegt. Bei sehr kleinen Objekten in riesiger Anzahl lohnt sich diese Verwaltungsgebühr unter Umständen nicht.

Lebenszyklusregeln eignen sich für Daten mit klaren Zugriffsmustern, wie z. B. Protokolle, Backups oder Trainingsdaten:

{
  "Rules": [
    {
      "ID": "logs-to-glacier",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Transitions": [
        { "Days": 30, "StorageClass": "STANDARD_IA" },
        { "Days": 90, "StorageClass": "GLACIER_IR" },
        { "Days": 180, "StorageClass": "DEEP_ARCHIVE" }
      ],
      "Expiration": { "Days": 730 }
    }
  ]
}

Beachten Sie die Mindestspeicherdauer: Standard-IA erfordert in der Regel 30 Tage, Glacier Instant Retrieval / Flexible Retrieval 90 Tage und Deep Archive 180 Tage. Objekte mit einem kurzen Lebenszyklus sollten nicht zu früh in kältere Klassen verschoben werden.

3. Glacier IR und Deep Archive: Nur für wirklich „kalte“ Daten

Glacier Instant Retrieval eignet sich für Archive, auf die selten zugegriffen wird, die aber Lesevorgänge im Millisekundenbereich erfordern, wie z. B. Compliance-Abfragen oder historische Berichte. Deep Archive eignet sich für Daten, auf die fast nie zugegriffen wird und bei denen eine Wiederherstellungszeit von mehreren Stunden akzeptabel ist, wie z. B. mehrjährige Backups.

Das Entscheidungskriterium ist denkbar einfach: Nur wenn ein Objekt mit hoher Wahrscheinlichkeit innerhalb der nächsten 6 Monate nicht gelesen wird, lohnt sich die Evaluierung von Deep Archive. Wenn die Fachseite keine Wartezeiten bei der Wiederherstellung akzeptieren kann, sollte man eine Migration nicht nur der schöneren Rechnung wegen erzwingen.

4. Bereinigen alter Versionen und unvollständiger Multipart Uploads

Nach dem Aktivieren von Versioning erzeugt das Löschen eines Objekts lediglich einen delete marker; die alten Versionen werden weiterhin in Rechnung gestellt. Die „Geisterkosten“ vieler Buckets stammen von solchen historischen Versionen.

Sie können die Versionen zunächst auflisten:

aws s3api list-object-versions --bucket my-bucket --prefix app/

Verwenden Sie anschließend Lebenszyklusregeln, um nicht-aktuelle Versionen zu bereinigen:

{
  "Rules": [
    {
      "ID": "expire-old-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": { "NoncurrentDays": 30 },
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    }
  ]
}

AbortIncompleteMultipartUpload wird leicht übersehen. Wenn das Hochladen einer großen Datei fehlschlägt, können die Fragmente (Parts) für lange Zeit in S3 verbleiben und weiterhin Kosten verursachen.

5. Anfrageoptimierung: LIST ist teurer als man denkt

In S3 Standard kosten Anfragen wie PUT/COPY/POST/LIST typischerweise ca. $0.005/1,000 requests, während GET-Anfragen ca. $0.0004/1,000 requests kosten. Die Einzelpreise wirken gering, doch bei Hunderten Millionen Objekten können scannende LIST-Operationen extrem teuer werden und zudem das System verlangsamen.

Praktische Empfehlungen:

• Vermeiden Sie es, ListObjectsV2 wie eine Datenbankabfrage zu verwenden.
• Beziehen Sie Datum, Mandant und fachliche Präfixe in das Design der Objektschlüssel (Keys) ein, um unnötige Scans zu reduzieren.
• Verwenden Sie S3 Inventory als Ersatz für vollständige LIST-Scans.
• Fassen Sie kleine, häufig aufgerufene Objekte zusammen oder verwenden Sie Caching, um GET-Stürme zu vermeiden.

6. VPC-Endpoints nutzen, um Umwege über das NAT Gateway zu vermeiden

Wenn EC2-Instanzen, ECS-Tasks oder Lambda-Funktionen in privaten Subnetzen auf S3 zugreifen und das Routing über ein NAT Gateway erfolgt, fallen NAT-Datenverarbeitungsgebühren an. In us-east-1 liegen die üblichen Preise für ein NAT Gateway bei ca. $0.045/hour zuzüglich $0.045/GB processed. Bei 1TB Datenvolumen pro Monat belaufen sich allein die NAT-Verarbeitungsgebühren auf ca. $45.

Konfigurieren Sie beim Zugriff auf S3 und DynamoDB bevorzugt einen Gateway-VPC-Endpoint:

aws ec2 create-vpc-endpoint \
  --vpc-id vpc-xxxx \
  --service-name com.amazonaws.us-east-1.s3 \
  --route-table-ids rtb-xxxx \
  --vpc-endpoint-type Gateway

Ein Gateway Endpoint selbst verursacht in der Regel keine stündlichen Gebühren und reduziert den Datenverkehr über das NAT Gateway. Überprüfen Sie nach der Anpassung die Route Table, um sicherzustellen, dass die S3-Präfixliste auf den Endpoint verweist.

7. Komprimierung: Anwendungsseitige Komprimierung vs. transparente Gateways

Komprimierung ist die direkteste Methode zur Kapazitätsoptimierung, hängt jedoch stark vom Datentyp ab. Parquet, ORC, bereits mit gzip komprimierte Protokolle, Bilder und Videos sind in der Regel schon komprimiert, weshalb hier der Nutzen gering ist. Bei JSON, CSV, Textprotokollen, unkomprimierten Objekten und manchen Backup-Dateien können sich hingegen signifikante Einsparungen ergeben.

Der Vorteil der anwendungsseitigen Komprimierung liegt in der einfachen Architektur ohne zusätzliche Gateways. Die Nachteile sind notwendige Codeänderungen, das Handling von Kompatibilitätsfragen und die Migration historischer Daten. Eine Alternative sind transparente Komprimierungs-Gateways: Die Anwendung nutzt weiterhin die S3-API und wird auf das Gateway verwiesen, welches die Daten komprimiert, bevor sie in S3 geschrieben werden.

S4 (Squished S3) gehört zur letztgenannten Kategorie. Es handelt sich um ein EC2 AMI mit integriertem NVIDIA nvCOMP GPU-Codec, das auf GPU-Instanzen wie g4dn/g5/g6 läuft. Sobald der S3-Client auf dieses transparente Gateway ausgerichtet ist, lassen sich die in S3 gespeicherten Bytes für komprimierbare Daten typischerweise um 50% bis 80% reduzieren, ohne dass der Anwendungscode geändert werden muss. Diese Lösung eignet sich nicht für jedes Szenario: Wenn die Daten bereits komprimiert sind, die Objekte sehr klein sind oder die Anzahl der Anfragen extrem hoch ist, während die Kapazität gering bleibt, fällt der Nutzen gering aus. Ein lohnendes Szenario ist: Es liegen große Mengen an Text- oder halbstrukturierten Daten in S3, die Kapazitätskosten stellen das Hauptproblem dar, und eine Anpassung der Anwendung soll vermieden werden.

Für eine erste grobe Schätzung können Sie das S4-Kostenkalkulationstool nutzen. Es erfordert kein Hochladen der eigenen Rechnungs-CSV, sondern kann auch mit Beispieldaten getestet werden.

Fazit: Erst messen, dann die Strategie anpassen

Empfohlene Reihenfolge der Umsetzung:

1. Ermitteln Sie mit dem Cost Explorer die primären S3-Nutzungstypen (Usage Types).
2. Analysieren Sie Buckets, Präfixe, Versionen und die Verteilung der Objektgrößen mit S3 Storage Lens.
3. Bereinigen Sie zuerst historische Versionen und unvollständige Multipart Uploads.
4. Richten Sie anschließend Lebenszyklusregeln, VPC-Endpoints und Anfrageoptimierungen ein.
5. Evaluieren Sie abschließend Komprimierungsverfahren oder alternative Architekturen.

S3-Kostenreduzierung ist nicht so einfach wie „alles in kältere Speicherklassen verschieben“. Der wirklich effektive Ansatz besteht darin, Datenzugriffsmuster, Objektgrößen, Abfragepfade und Aufbewahrungsfristen ganzheitlich zu betrachten.

Offenlegung: Der Autor dieses Artikels ist Mitarbeiter von abyo software (Entwickler von S4, einem Produkt zur Kostenoptimierung im AWS Marketplace).