Règles de cycle de vie S3 : les patrons qui réduisent la facture de stockage sans danger

Si vous payez Amazon S3 (Simple Storage Service, le stockage d’objets d’Amazon Web Services), quatre règles de cycle de vie donnent l’essentiel des économies. Elles réduisent la facture sans supprimer les données dont vous avez encore besoin. Une règle de cycle de vie est un réglage de compartiment qui demande à S3 de supprimer ou de déplacer les objets une fois qu’ils atteignent un certain âge. La première règle fait expirer les vieux fichiers journaux. La deuxième supprime les versions non courantes, c’est-à-dire les anciennes copies que S3 conserve quand le versionnement est activé et qu’un fichier est remplacé ou supprimé. La troisième annule après sept jours les téléversements multipart incomplets; ce sont de gros envois faits en morceaux qui n’ont jamais abouti, mais qui occupent quand même du stockage facturé. La quatrième déplace les gros objets rarement lus vers une classe de stockage moins chère, avec un filtre de taille pour que les petits fichiers restent en place. Les règles s’exécutent une fois par jour et ne coûtent rien à mettre en place. Les problèmes commencent quand une règle déplace beaucoup de petits objets, entre en conflit avec le versionnement, ou supprime quelque chose dont un processus de restauration avait encore besoin.

Ce qui se passe

Une configuration de cycle de vie est un ensemble de règles attachées à un compartiment. Chaque règle a un filtre (préfixe, étiquettes, taille d’objet, ou une combinaison) et une ou plusieurs actions : Transition déplace les versions courantes vers une autre classe de stockage après N jours, Expiration les supprime, NoncurrentVersionTransition et NoncurrentVersionExpiration font pareil pour les anciennes versions d’un compartiment versionné, et AbortIncompleteMultipartUpload jette les morceaux de téléversements en panne. S3 évalue les règles environ une fois par jour, de façon asynchrone — les actions peuvent traîner après la date d’admissibilité, mais la facturation s’arrête à l’admissibilité pour les expirations, donc le délai ne vous coûte rien.

La mécanique de coûts à connaître : les transitions sont facturées par millier de requêtes, et les transitions vers les classes Glacier coûtent plus cher par requête que celles vers IA. Déplacer des millions de petits objets peut donc coûter plus en frais de requêtes que le changement de classe n’économise — c’est pour ça que le filtre ObjectSizeGreaterThan existe et que le cycle de vie saute maintenant par défaut les transitions d’objets sous 128 Ko. Les durées minimales s’appliquent toujours après une transition : un objet passé en Standard-IA puis supprimé 10 jours plus tard paie quand même le minimum de 30 jours. La référence complète des actions est dans la documentation S3.

Quoi vérifier d’abord

Le versionnement est-il activé? Si oui, expirer une version courante ne fait qu’ajouter un marqueur de suppression — les octets survivent comme versions non courantes jusqu’à ce qu’une règle de versions non courantes les enlève. C’est le rapport « la règle n’a rien fait » le plus fréquent.
Ce qui existe déjà. Les compartiments accumulent des règles de différentes époques; les règles en conflit ou qui se chevauchent sont courantes.
Qui lit les vieilles données. Une règle qui expire les « vieux exports » a déjà brisé plus d’une tâche de rapport trimestriel.
La distribution des tailles d’objets. Elle décide si les transitions économisent ou coûtent de l’argent.

Comment vérifier

Sortez la configuration actuelle et lisez-la avant de toucher à quoi que ce soit :

aws s3api get-bucket-lifecycle-configuration --bucket my-bucket

# État du versionnement — change ce que l'expiration fait vraiment
aws s3api get-bucket-versioning --bucket my-bucket

# Combien se cache dans les versions non courantes et les téléversements incomplets?
# Storage Lens : S3 > Storage Lens > Dashboards > votre tableau de bord
# (voir les métriques d'octets de versions non courantes et de MPU incomplets)

Dans la console, S3 > votre compartiment > Management > Lifecycle rules montre le filtre et les actions de chaque règle. Une fois une règle en vigueur, confirmez le mouvement avec les métriques de stockage par classe sous S3 > votre compartiment > Metrics — la ligne Standard devrait baisser pendant que la classe cible monte.

Le runbook

Avortez les téléversements multipart incomplets partout. Risque nul, économie immédiate sur les compartiments avec du trafic de téléversement — les détails sont dans frais de multipart incomplets et nettoyage. Cette règle a sa place sur chaque compartiment que vous possédez.
Expirez les données avec une fin de vie connue. Journaux, exports temporaires, artéfacts de build. Confirmez d’abord l’exigence de rétention par écrit.
Plafonnez les versions non courantes sur les compartiments versionnés. Gardez ce dont le retour arrière a vraiment besoin — un nombre et un âge — et expirez le reste. Ajoutez le nettoyage ExpiredObjectDeleteMarker pour que les marqueurs de suppression ne s’accumulent pas.

Faites la transition des gros objets froids avec un filtre de taille. Un exemple fonctionnel combinant les quatre patrons :

{
  "Rules": [
    {
      "ID": "abort-incomplete-mpu",
      "Status": "Enabled",
      "Filter": {},
      "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
    },
    {
      "ID": "expire-logs",
      "Status": "Enabled",
      "Filter": { "Prefix": "logs/" },
      "Expiration": { "Days": 90 }
    },
    {
      "ID": "cap-noncurrent-versions",
      "Status": "Enabled",
      "Filter": {},
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30,
        "NewerNoncurrentVersions": 3
      },
      "Expiration": { "ExpiredObjectDeleteMarker": true }
    },
    {
      "ID": "archive-large-exports",
      "Status": "Enabled",
      "Filter": {
        "And": {
          "Prefix": "exports/",
          "ObjectSizeGreaterThan": 131072
        }
      },
      "Transitions": [
        { "Days": 90, "StorageClass": "GLACIER_IR" }
      ]
    }
  ]
}

Appliquez-la avec :

aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket \
  --lifecycle-configuration file://lifecycle.json

Notez que put-bucket-lifecycle-configuration remplace la configuration au complet — fusionnez d’abord avec les règles existantes, n’écrivez jamais par-dessus à l’aveugle.

Attendez un cycle, puis mesurez. Les règles peuvent prendre jusqu’à 48 heures avant d’agir. Vérifiez les métriques par classe et les lignes d’usage de la prochaine facture avant de crier victoire.

Quand ce n’est pas la bonne approche

Les règles de cycle de vie sont le mauvais outil quand le patron d’accès est inconnu — c’est le territoire de l’Intelligent-Tiering. Elles sont le mauvais outil pour un nettoyage ponctuel d’une liste précise d’objets — c’est S3 Batch Operations. Et elles sont dangereuses sur des compartiments qui alimentent de la réplication ou des flux de sauvegarde interrégionale sans vérifier ce que le côté aval s’attend à voir encore exister.

Erreurs courantes

Expirer des versions courantes sur un compartiment versionné et se demander pourquoi la facture n’a pas bougé — les octets sont maintenant des versions non courantes plus des marqueurs de suppression.
Faire passer des millions de petits objets vers Glacier et payer plus en requêtes de transition et en surcoût par objet que le changement de classe n’économise.
Écraser une configuration de cycle de vie existante avec put-bucket-lifecycle-configuration et supprimer en silence les règles de quelqu’un d’autre.
Programmer une transition vers Standard-IA avant le jour 30 — S3 rejette les délais de transition qui violent les contraintes de classe, et les gens perdent du temps sur l’erreur de validation.

Prévention

Gardez les configurations de cycle de vie dans Terraform ou CloudFormation pour que les changements soient révisés et que le comportement « remplace, ne fusionne pas » ne surprenne personne.
Mettez la règle d’avortement des MPU incomplets dans votre module de compartiment pour que chaque nouveau compartiment l’ait par défaut.
Documentez la rétention par préfixe dans le dépôt à côté de la règle — la règle est l’application, pas le registre.
Révisez les règles contre Storage Lens chaque trimestre : les règles qui ne correspondent plus à l’usage du compartiment sont soit du poids mort, soit une fuite lente.

Les règles de cycle de vie sont le rare outil de coûts qui continue de travailler quand tout le monde a cessé d’y penser — à condition que l’interaction avec le versionnement ait été comprise dès le premier jour. Si personne dans votre équipe ne possède vraiment l’environnement AWS de bout en bout, c’est la racine de la plupart de ces problèmes — Stack Harbor opère des comptes AWS au quotidien sous Opérations AWS, et vous pouvez réserver une revue AWS.