Wie entscheidest du über Storage-Klassen und Lifecycle-Regeln bei Object Storage?

Pass die Klasse zum Zugriffsmuster und zur Toleranz beim Abruf. Häufiger Zugriff bleibt Standard, unvorhersehbare Muster passen zu Intelligent Tiering, das Objekte gegen eine kleine Monitoring-Gebühr automatisch verschiebt. Infrequent-Access-Klassen sind billiger im Speichern, berechnen aber den Abruf und haben Mindestlaufzeiten, und Archivklassen sind am billigsten, mit Verzögerung beim Abruf. Nutz Lifecycle-Regeln zum Verschieben und Verfallen, inklusive alter Versionen, und schau vorher auf die Objektanzahl.

Ich schaue, wie oft die Daten gelesen werden und wie lange der Leser warten kann. Heiße Daten bleiben in Standard. Wenn mir niemand das Zugriffsmuster nennen kann, ist Intelligent Tiering die ehrliche Antwort, denn es verschiebt Objekte für dich und die Monitoring-Gebühr ist klein im Vergleich zum falschen Raten. Daten, von denen ich weiß, dass sie selten gelesen werden, gehen in eine Infrequent-Access-Klasse, aber nur, wenn sie über die Mindestlaufzeit hinaus leben, sonst frisst die Gebühr für frühes Löschen die Ersparnis. Archivklassen sind für Compliance-Aufbewahrung, bei der eine Abrufverzögerung von Minuten oder Stunden akzeptabel ist. Die Falle, die ich prüfe, bevor ich irgendeine Lifecycle-Regel schreibe, ist die Objektanzahl, denn Übergänge werden pro Objekt berechnet, ein Bucket mit zweihundert Millionen winzigen Logdateien kann also mehr kosten als sparen. Die sollte man stattdessen aggregieren. Und die größten Gewinne liegen meistens gar nicht bei der Klasse. Das Verfallen nicht aktueller Versionen in einem versionierten Bucket einzuschalten und unvollständige Multipart-Uploads nach einer Woche abzubrechen, hat mir jeweils eine Bucket-Rechnung halbiert, ohne ein einziges lebendes Objekt anzufassen.