Comment décidez-vous des classes de stockage objet et des règles de cycle de vie ?

Faites correspondre la classe au motif d'accès et à la tolérance au délai de restitution. Les accès fréquents restent en standard ; les motifs imprévisibles conviennent au tiering intelligent, qui déplace les objets automatiquement pour de petits frais de surveillance. Les classes d'accès peu fréquent coûtent moins cher au stockage mais facturent la restitution et imposent des durées minimales, et les classes d'archive sont les moins chères avec des délais de restitution. Utilisez les règles de cycle de vie pour transitionner et expirer, y compris les anciennes versions, et vérifiez d'abord le nombre d'objets.

Je regarde à quelle fréquence la donnée est lue et combien de temps le lecteur peut attendre. La donnée chaude reste en standard. Si personne ne peut me dire quel est le motif d'accès, le tiering intelligent est la réponse honnête, parce qu'il déplace les objets pour vous et les frais de surveillance sont faibles comparés au coût d'une mauvaise supposition. Une donnée que je sais rarement lue part vers une classe d'accès peu fréquent, mais seulement si elle va vivre au-delà de la durée minimale, sinon les frais de suppression anticipée mangent l'économie. Les classes d'archive sont pour la rétention de conformité, quand un délai de restitution de minutes ou d'heures est acceptable. Le piège que je vérifie avant d'écrire la moindre règle de cycle de vie, c'est le nombre d'objets, parce que les transitions sont facturées par objet : un bucket de deux cents millions de petits fichiers de logs peut coûter plus cher à déplacer que ce qu'il fait économiser ; ceux-là, il faut plutôt les agréger. Et les plus gros gains ne viennent en général pas de la classe. Activer l'expiration des versions non courantes dans un bucket versionné, et abandonner les uploads multipart incomplets au bout d'une semaine, ont chacun divisé par deux une facture de bucket chez moi sans toucher un seul objet vivant.