Objektspeicher ohne Lifecycle-Regeln

S3 Lifecycle Regel Kosten sind die Kosten, die eine fehlende Regel verursacht: ein Bucket ohne Lifecycle-Konfiguration behält jede nicht aktuelle Version, jeden abgebrochenen Multipart-Upload, jede weich gelöschte Datei und jedes Logfile für immer, zum Preis der Klasse, in die es geschrieben wurde. Die Einsparung entsteht, weil eine Lifecycle-Regel diese Objekte nach Alter löscht oder in eine günstigere Speicherklasse verschiebt, ohne dass jemand sie anfasst, und weil die Regel einmal geschrieben jeden Monat wirkt. Die Behebung gehört dem Team, dem der Bucket gehört, weil nur dort bekannt ist, welche Versionen und wie viele Tage eine Wiederherstellung braucht.

Symptom

Die Rechnung zeigt Objektspeicher, der schneller wächst als die Daten, die die Anwendung schreibt. Bei AWS ist das lineItem/UsageType EUC1-TimedStorage-ByteHrs unter AmazonS3, das nicht zwischen aktuellen Versionen, nicht aktuellen Versionen und Upload-Teilen unterscheidet; erst S3 Storage Lens zeigt die Anteile. Bei Azure sind es die Meter Hot LRS Data Stored und ihre Geschwister unter MeterCategory Storage, einschließlich weich gelöschter und versionierter Blobs. In Google Cloud trägt Cloud Storage die SKU Standard Storage je Region, einschließlich nicht aktueller Versionen und weich gelöschter Objekte innerhalb ihrer Frist. Die Klassen und ihre Mechanik stehen in Speicherklassen und Lifecycle; diese Seite behandelt die Lücke, in der keine Regel greift, und die Regel, die sie schließt.

So erkennen Sie es

AWS

Ob ein Bucket eine Regel hat, ob Versionierung läuft und welche Uploads offen sind:

aws s3api get-bucket-lifecycle-configuration --bucket <bucket>
aws s3api get-bucket-versioning --bucket <bucket>
aws s3api list-multipart-uploads --bucket <bucket> --query 'Uploads[].[Key,Initiated,UploadId]' --output table

Die erste Anfrage antwortet mit NoSuchLifecycleConfiguration, wenn keine Regel existiert. Die Anteile zeigt S3 Storage Lens in seinen kostenlosen Metriken: Buckets mit unvollständigen Multipart-Uploads, die älter als sieben Tage sind, nicht aktuelle Versionsbytes, und versionierte Buckets ohne Regel (S3 Storage Lens). Trusted Advisor führt drei Prüfungen dazu: "Amazon S3 Bucket Lifecycle Policy Configured", "Amazon S3 Incomplete Multipart Upload Abort Configuration" und "Amazon S3 version-enabled buckets without lifecycle policies configured" (gelesen am 2026-10-21). In den Abrechnungsdaten ist der Kandidat ein Bucket als lineItem/ResourceId, dessen TimedStorage-ByteHrs monatlich wächst, während die Anfragen gleich bleiben (AWS Cost and Usage Report).

Azure

Die Richtlinie des Speicherkontos und seine Versionierungs- und Soft-Delete-Einstellungen:

az storage account management-policy show --account-name <account> --resource-group <rg>
az storage account blob-service-properties show --account-name <account> --resource-group <rg> \
  --query "{versioning:isVersioningEnabled, softDeleteDays:deleteRetentionPolicy.days, lastAccess:lastAccessTimeTrackingPolicy.enable}"

Ein Konto ohne Richtlinie antwortet mit einem Fehler; ein Konto mit Versionierung und Soft Delete ohne Löschregel für vorherige Versionen behält alles. Die Metrik BlobCapacity je Zugriffsstufe und BlobType zeigt, wie viel in der heißen Stufe liegt; Azure Advisor hat keine Empfehlung zu Lifecycle-Regeln, nur zum Wechsel auf Premium bei hohem Transaktionsanteil. Im Kostenexport ist der Kandidat ein Speicherkonto, dessen Data Stored-Meter in der heißen Stufe wächst, ohne Cool- oder Archive-Meter daneben (Azure-Kostenexporte).

Google Cloud

Die Lifecycle-Konfiguration, Versionierung, Soft-Delete-Frist und Autoclass je Bucket:

gcloud storage buckets describe gs://<bucket> --format="default(lifecycle_config,versioning_enabled,soft_delete_policy,autoclass)"

Ein Bucket ohne lifecycle_config behält alles; nicht aktuelle Versionen bleiben bis zu einer Regel mit isLive: false. Der Recommender google.storage.bucket.SoftDeleteRecommender meldet Buckets, deren Soft-Delete-Frist mehr kostet, als sie schützt (Recommender-Übersicht). Im Abrechnungsexport ist der Kandidat ein Bucket als resource.name, dessen Standard Storage-Nutzung wächst, ohne Nearline- oder Coldline-SKUs daneben (Google-Cloud-Abrechnungsexport).

So beheben Sie es

1. Je Bucket die drei Fragen klären, die die Regel braucht: wie viele nicht aktuelle Versionen und wie viele Tage die Wiederherstellung verlangt, nach wie vielen Tagen ein Objekt kalt wird, und ob Objekte unter 128 KB dabei sind, für die die kälteren Klassen bei AWS eine Mindestgröße berechnen.

2. Die Regel setzen. Bei AWS als JSON mit put-bucket-lifecycle-configuration; dieser Satz bricht offene Uploads nach sieben Tagen ab, löscht abgelaufene Löschmarker, behält drei nicht aktuelle Versionen für 30 Tage und verschiebt Objekte ab 128 KB nach 30 Tagen nach Standard-IA (Lifecycle-Regel für unvollständige Multipart-Uploads):

   {
     "Rules": [
       {"ID": "hygiene", "Status": "Enabled", "Filter": {"Prefix": ""},
        "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7},
        "Expiration": {"ExpiredObjectDeleteMarker": true},
        "NoncurrentVersionExpiration": {"NoncurrentDays": 30, "NewerNoncurrentVersions": 3}},
       {"ID": "tier", "Status": "Enabled", "Filter": {"ObjectSizeGreaterThan": 131072},
        "Transitions": [{"Days": 30, "StorageClass": "STANDARD_IA"}]}
     ]
   }
   

   Bei Azure als Richtlinie mit az storage account management-policy create --account-name <account> --resource-group <rg> --policy @policy.json, mit tierToCool bei daysAfterModificationGreaterThan 30 für Basisblobs und delete bei daysAfterCreationGreaterThan 30 für vorherige Versionen; die Richtlinie läuft binnen 24 Stunden an (Lifecycle-Management). Bei Google Cloud mit gcloud storage buckets update gs://<bucket> --lifecycle-file=lifecycle.json, mit AbortIncompleteMultipartUpload bei age 7, Delete bei isLive false und numNewerVersions 3, SetStorageClass NEARLINE bei age 30 (Object Lifecycle Management).

3. Wo das Zugriffsmuster unbekannt ist, die automatische Stufung statt fester Fristen: S3 Intelligent-Tiering verschiebt Objekte nach 30 Tagen ohne Zugriff in die Infrequent-Access-Stufe und nach 90 in Archive Instant Access, gegen eine monatliche Überwachungsgebühr je Objekt, Objekte unter 128 KB ausgenommen (Intelligent-Tiering); Autoclass in Google Cloud verschiebt nach 30 Tagen nach Nearline und, mit Archive als Endklasse, nach 90 Tagen nach Coldline und nach 365 nach Archive, ohne Abruf- und Frühlöschgebühren, gegen eine Verwaltungsgebühr (Autoclass).

4. Die Regel in die Vorlage schreiben, aus der neue Buckets entstehen, und die Trusted-Advisor-Prüfungen oder eine Storage-Lens-Metrik als Wächter gegen den nächsten Bucket ohne Regel.

Löschungen wirken bei AWS binnen eines Tages, bei Azure und Google Cloud bis zu 24 Stunden nach der Regel; der Betrag sinkt im nächsten Tagesexport.

Risiken und Nebenwirkungen

• Mindestfristen: Standard-IA und One Zone-IA 30 Tage, Glacier Instant Retrieval und Flexible Retrieval 90, Deep Archive 180 bei AWS; Cool 30, Cold 90, Archive 180 bei Azure, anteilig berechnet; Nearline 30, Coldline 90, Archive 365 bei Google Cloud. Ein Objekt, das vor der Frist gelöscht oder zurückgeholt wird, zahlt den Rest.
• Mindestgröße: Standard-IA und Glacier Instant Retrieval berechnen mindestens 128 KB je Objekt, und Intelligent-Tiering überwacht kleinere Objekte nicht; ein Bucket voller Thumbnails spart durch eine Stufung nichts.
• Jede Stufung ist eine Anfrage: S3 berechnet Übergangsanfragen, Azure den Set-Blob-Tier-Aufruf als Schreibvorgang, Google Cloud eine Operation der Klasse A. Millionen kleiner Objekte auf einmal zu stufen kostet im ersten Monat mehr, als es spart.
• Eine Löschregel in einem versionierten Bucket erzeugt bei AWS nur Löschmarker, wenn die Regel für nicht aktuelle Versionen fehlt; Soft Delete bei Azure und Google Cloud hält Gelöschtes für die eingestellte Frist weiter auf der Rechnung.
• Ein Objekt in der Archivstufe ist nicht sofort da: Rehydrierung dauert bei Azure bis zu 15 Stunden, Abrufe aus Glacier Flexible Retrieval und Deep Archive Stunden, jeweils mit Abrufkosten.

So weisen Sie die Einsparung nach

Vorher: je Bucket die gespeicherten Byte-Stunden je Klasse im letzten vollen Monat, TimedStorage-ByteHrs und TimedStorage-SIA-ByteHrs, die Data Stored-Meter je Stufe, die Storage-SKUs je Klasse, dazu die Storage-Lens-Werte für nicht aktuelle Versionen und offene Uploads. Nachher: dieselben Werte im ersten vollen Monat nach der Regel; die Byte-Stunden der heißen Klasse müssen fallen, die der kalten steigen, und die Summe sinken, einschließlich der Übergangsanfragen und Frühlöschgebühren des ersten Monats. Die Schätzung aus Storage Lens oder der eigenen Inventur ist der Wert "geschätzt", die Freigabe des Teams macht ihn akzeptiert, die Regel umgesetzt, und die Rechnung des Folgemonats belegt ihn nach dem Muster von geschätzt, akzeptiert, umgesetzt, verifiziert. Die Zahl der Buckets ohne Regel ist die Kennzahl, die danach null bleibt.

Quellen

Gelesen am 2026-10-21. Lifecycle-Regel für unvollständige Multipart-Uploads, S3 Storage Lens, S3 Intelligent-Tiering, S3-Preise, Mindestfristen und Mindestgrößen, Trusted Advisor, Kostenoptimierungsprüfungen, Azure Blob Storage, Lifecycle-Management, Azure Blob Storage, Zugriffsstufen, Object Lifecycle Management, Lifecycle verwalten, Speicherklassen, Autoclass, Recommender-Übersicht.