Cycle de vie S3 : transitions, expiration et versions

Une politique de cycle de vie S3 définit quand Amazon S3 doit déplacer des objets vers une autre classe de stockage ou les faire expirer. Pour la concevoir, partez des données : combien de temps faut-il les conserver, dans quel délai faut-il pouvoir les récupérer et que peut-on supprimer définitivement ?

Ce guide concerne les compartiments S3 à usage général. Il présente un exemple JSON limité à un préfixe et les vérifications à effectuer avant d'activer une règle. Pour comparer les options de stockage, consultez notre guide du stockage cloud Amazon.

Ce que contrôle une politique de cycle de vie S3

Un compartiment possède une configuration de cycle de vie contenant une ou plusieurs règles. Chaque règle sélectionne les objets concernés, possède un état activé ou désactivé et précise des actions. S3 Lifecycle permet de changer de classe de stockage et de faire expirer des objets. Des actions distinctes gèrent les versions non actuelles et les envois multipart inachevés.

Partez d'un besoin concret : conserver des exports d'application immédiatement accessibles pendant un mois, les archiver ensuite, puis les supprimer à la fin de la durée de conservation approuvée. Ces délais doivent être définis avec le responsable des données. Reprendre les paramètres d'une autre équipe peut supprimer des fichiers encore nécessaires à votre application.

Délimiter les règles avant de choisir les délais

Utilisez un préfixe précis, des étiquettes d'objet, la taille des objets ou une combinaison adaptée. Un préfixe correspond au début d'une clé d'objet ; il ne constitue pas un répertoire de système de fichiers. Par exemple, lifecycle-demo/archive/ sélectionne lifecycle-demo/archive/export.csv.

La documentation des éléments de configuration explique comment combiner les filtres. Un filtre vide s'applique à tout le compartiment. Pour associer un préfixe à des étiquettes ou à des limites de taille, utilisez la structure And documentée. Des champs distincts ne constituent pas automatiquement des conditions alternatives.

Les règles s'appliquent aux objets existants comme aux futurs envois. Activer une expiration après 30 jours peut rendre immédiatement admissibles à la suppression les fichiers correspondants qui ont déjà dépassé cet âge. Avant l'activation, listez les clés et versions concernées et vérifiez des exemples avec le responsable de l'application.

Choisir les transitions selon l'accès et le coût total

Une transition change la classe de stockage d'un objet dans S3. Elle ne déplace pas cet objet vers un système de sauvegarde indépendant. Comparez les classes de stockage aux besoins du traitement :

• S3 Standard-IA : accès peu fréquent et récupération immédiate, avec des frais de récupération et une durée minimale de stockage de 30 jours.
• S3 Glacier Instant Retrieval : accès immédiat à des données rarement consultées, avec un minimum de 90 jours.
• S3 Glacier Flexible Retrieval : archives à restaurer avant leur consultation, avec un minimum de 90 jours.
• S3 Glacier Deep Archive : archives de longue durée à restaurer avant leur consultation, avec un minimum de 180 jours.

La durée minimale de stockage est une condition de facturation, pas une garantie de conservation. Incluez les requêtes de transition, la récupération, la restauration et les frais de suppression anticipée dans votre estimation. Déplacer un fichier plusieurs fois peut coûter plus cher que le laisser dans sa classe initiale.

Cette durée minimale facturée diffère aussi du délai d'attente avant une transition. Le 16 juillet 2026, AWS a supprimé l'attente de 30 jours pour passer de S3 Standard à Standard-IA ou One Zone-IA. La transition à 30 jours de l'exemple ci-dessous est un calendrier choisi, pas une attente actuellement obligatoire.

Si les habitudes d'accès changent, évaluez séparément S3 Intelligent-Tiering. Son classement fondé sur les accès diffère d'une règle de cycle de vie fondée sur l'âge. Avant de choisir un niveau d'archivage, mesurez le délai jusqu'à l'utilisation effective d'un fichier restauré par l'application, traitements compris.

Le seuil par défaut pour les petits objets

Avec le comportement actuel par défaut, les transitions excluent les objets de moins de 128 KB, selon l'unité indiquée par AWS. AWS a modifié ce comportement en septembre 2024. Une configuration plus ancienne peut conserver le comportement précédent jusqu'à sa modification. Des filtres de taille personnalisés et le paramètre de transition par défaut de l'API peuvent modifier le résultat.

Ce seuil concerne les transitions. Il ne protège pas les petits objets d'une règle d'expiration qui les sélectionne. Pour estimer les coûts, comptez les objets en plus du volume total. Des millions de petits fichiers ne produisent pas le même nombre de requêtes que quelques grandes archives.

Exemple de politique S3 limité à un préfixe de test

Le JSON suivant est destiné à un compartiment de test à usage général dont le versionnement n'a jamais été activé. Utilisez uniquement des fichiers que vous pouvez perdre. La première règle fait passer les objets concernés à Standard-IA après 30 jours, puis à Glacier Flexible Retrieval après 90 jours, avant leur expiration après 365 jours. Ces âges illustrent le fonctionnement ; ils ne constituent pas des durées de conservation recommandées pour des données clients.

La seconde règle nettoie les envois inachevés sous le préfixe de démonstration. Enregistrez cette configuration dans lifecycle.json si vous l'utilisez avec un SDK AWS ou la CLI. AWS fournit aussi des exemples de règles de transition et d'expiration.

{
  "Rules": [
    {
      "ID": "demo-archive-and-expire",
      "Status": "Enabled",
      "Filter": {"Prefix": "lifecycle-demo/archive/"},
      "Transitions": [
        {"Days": 30, "StorageClass": "STANDARD_IA"},
        {"Days": 90, "StorageClass": "GLACIER"}
      ],
      "Expiration": {"Days": 365}
    },
    {
      "ID": "demo-abort-incomplete-uploads",
      "Status": "Enabled",
      "Filter": {"Prefix": "lifecycle-demo/"},
      "AbortIncompleteMultipartUpload": {"DaysAfterInitiation": 7}
    }
  ]
}

Les trois âges de la première règle sont calculés depuis la création de l'objet, et non depuis la transition précédente. La seconde règle compte le temps depuis le lancement de l'envoi. L'expiration ordinaire des objets ne supprime pas les envois multipart inachevés. Inversement, l'annulation d'un envoi inachevé ne supprime pas les objets dont l'envoi est terminé. Choisissez un délai de nettoyage supérieur au temps nécessaire aux envois légitimes. Consultez les consignes AWS sur le nettoyage multipart.

L'exemple a été analysé et vérifié localement par rapport au schéma de requête Botocore. Il n'a pas été appliqué à un compartiment AWS. Les transitions effectives, les autorisations, la facturation et les délais de suppression nécessitent encore un test isolé.

Le versionnement change le résultat de l'expiration

Vérifiez l'état du versionnement avant d'adapter cet exemple. Dans un compartiment non versionné, l'expiration supprime définitivement l'objet. Lorsque le versionnement est activé, une expiration ordinaire conserve la version de données. S3 fait du marqueur de suppression la version actuelle, tandis que la version de données devient non actuelle. Les données peuvent rester stockées et facturées.

L'action NoncurrentVersionExpiration permet de supprimer définitivement les anciennes versions. Leur âge se mesure depuis le moment où elles sont devenues non actuelles, et non depuis leur envoi initial. L'ajout de NewerNoncurrentVersions introduit une condition sur le nombre de versions conservées ; les conditions d'âge et de nombre doivent toutes deux être remplies. Consultez le fonctionnement de l'expiration et l'action sur les versions non actuelles avant de l'utiliser.

Suspendre le versionnement ne redonne pas au compartiment le comportement d'un compartiment qui n'a jamais été versionné. L'expiration peut supprimer définitivement un objet dont l'identifiant de version est nul. Écartez ce cas d'un premier essai.

Appliquer et vérifier la configuration

1. Inspectez le compartiment : confirmez le compte, la région, le versionnement, les règles existantes, les objets sélectionnés et les exigences de conservation.
2. Conservez la configuration actuelle : gardez-en une copie vérifiée avant toute modification. L'API PutBucketLifecycleConfiguration remplace la configuration existante ; elle n'ajoute pas simplement une règle. Incluez toutes les règles à conserver.
3. Commencez dans le compartiment de test : dans la console de gestion AWS, ouvrez l'onglet de gestion du compartiment et créez une règle avec le préfixe et les actions prévus. Vérifiez son périmètre avant de l'activer.
4. Relisez les règles enregistrées : contrôlez les préfixes, l'état, les âges et les classes de stockage. Un enregistrement réussi confirme l'acceptation de la configuration, pas la transition d'un objet.
5. Vérifiez le résultat : inspectez les classes de stockage, les versions, les marqueurs de suppression et les envois inachevés. Testez la récupération après une transition et consignez le résultat avant d'élargir le périmètre.

Pour lire la configuration avec la CLI AWS, remplacez la valeur indicative par le nom de votre compartiment de test :

aws s3api get-bucket-lifecycle-configuration --bucket YOUR_PRIVATE_TEST_BUCKET

L'API de lecture de la configuration exige l'autorisation correspondante. Protégez séparément le droit de modifier les règles : interdire la suppression ordinaire d'objets dans une politique de compartiment n'arrête pas une expiration déjà configurée.

Quand une règle semble ne pas fonctionner

Commencez par vérifier le préfixe, l'état de la règle, l'âge et la taille de l'objet, sa classe actuelle et le versionnement du compartiment. AWS calcule l'admissibilité des actions exprimées en jours selon les limites de journées UTC. L'exécution est asynchrone : une date d'admissibilité n'est pas une heure précise de suppression.

Vérifiez aussi les règles contradictoires, l'état de réplication et les durées de rétention ou les gels juridiques Object Lock. Ces éléments peuvent modifier les actions possibles. Consultez le guide de dépannage AWS plutôt que de raccourcir sans cesse le délai d'expiration jusqu'à la disparition des fichiers.

Pour le stockage d'une application, désignez un responsable pour chaque règle et indiquez pourquoi les fichiers sélectionnés peuvent être archivés ou supprimés. Notre guide du stockage cloud pour applications traite des décisions d'accès, de récupération et d'intégration associées. La compatibilité avec l'API S3 ne prouve pas qu'un autre fournisseur implémente ces actions de cycle de vie.

Questions fréquentes

Une politique de cycle de vie remplace-t-elle une politique de compartiment ?

Non. La configuration de cycle de vie programme des actions de stockage. La politique de compartiment contrôle les accès. Examinez les deux pour déterminer qui peut modifier ou supprimer les données.

Désactiver une règle permet-il de récupérer les fichiers supprimés ?

Non. La désactivation ne restaure ni un objet ni une version supprimés définitivement. Conservez des copies de récupération et testez leur restauration séparément.

Peut-on utiliser cet exemple dans un compartiment de répertoire S3 ?

Non. Les compartiments de répertoire prennent en charge un ensemble plus limité de fonctions, dont l'expiration et l'annulation des envois inachevés, mais pas les transitions de classe de cet exemple. Consultez la documentation API propre à ce type de compartiment.