Vue d’ensemble
La fonctionnalité « cycle de vie » (ou lifecycle en anglais) permet de stocker des objets de façon économe (parce que le stockage n’est pas gratuit).
Une configuration lifecycle est un ensemble de règles qui va s’appliquer automatiquement et régulièrement à un groupe d’objets dans un compartiment (ou bucket en anglais).
Elle contient une ou plusieurs actions.
un préfixe vide (cad. aucun filtrage)
un préfixe
une ou plusieurs valeurs de tag
à la fois un préfixe et une ou plusieurs valeurs de tag
une limite supérieure ou inférieure de taille d’objet
effacement d’ancien logs
conservation au maximum de n versions d’objet
de façon générale, contrôler la quantité totale de stockage utilisé et donc son coût
bonne pratique d’utiliser lifecycle quand la gestion des versions (versioning) est activée sur un compartiment (bucket).
Actions de transition
Elles définissent à quel moment les objets seront déplacés vers une autre catégorie de stockage.
ATTENTION : non supporté pour l’instant
Actions d’expiration
Elles définissent comment et à quel moment les objets seront expirés (effacés ).
Expiration c.-à-d. effacer les versions courantes d’objet (y compris les marqueurs de suppression expirés en option)
après n jours ( Days ) ou après une date ( Date )
ou seulement effacer les marqueurs de suppression expirés avec ExpiredObjectDeleteMarker
NoncurrentVersionExpiration c.-à-d. effacer les versions non courantes d’objet
après n jours ( Days )
ou en conservant au maximum n versions non courantes ( NewerNoncurrentVersions )
AbortIncompleteMultipartUpload c.-à-d. effacer les chargements partitionnés (multipart uploads en anglais)
après n jours ( Days ) (depuis le démarrage)
les actions d’expiration sont appliquées chaque jour
donc l’effacement peut être retardé
à partir du moment où l’expiration des objets est prévue, ils seront effacés de toute façon
l’expiration fonctionne quel que soit l’état de la gestion des versions d’un compartiment (mais les résultats varient)
Cas d’usage avec AWS CLI
AWS CLI (Command Line Interface) est un outil à code source libre permettant de configurer et d’utiliser le stockage objet en passant des commandes dans un interface textuelle (un shell Linux ou la ligne de commande Windows).
Un guide utilisateur de l’outil est disponible sur https://docs.aws.amazon.com/cli/latest/userguide/ .
Prérequis : aucun
Vous avez seulement besoin d’un bucket pour y appliquer une configuration de cycle de vie.
Effacer les versions courantes
Observons comment Expiration affecte les versions courantes (c.-à-d. quand la metadata IsLatest est vraie (true)).
Configuration de cycle de vie
La configuration de cycle de vie suivante (format json) est appliquée à 3 compartiments (chacun dans un état différent de gestion des versions):
{
le filtre ( Filter ) a un prefix vide afin de traiter tous les objets (d’un compartiment)
le statut ( Status ) est activé (enabled) afin de rendre effective la configuration
l’action est Expiration afin d’effacer les versions courantes
le critère temporel pour l’action est une Date afin de déclencher l’action strictement après cette date (un certain délai est à prévoir)
Expiration est Days. Il permet l’expiration de la version courante après avoir atteint une certaine durée de vie (en jours).
Ceci effacerait les versions courantes âgées de plus de 5 jours:
...
Compartiment avec la gestion des versions non activée
La metadata VersionId est toujours à null (car non requise).
La metadata IsLatest est toujours à vraie (true) (c.-à-d. que la version est courante).
Deleting an object is always permanent.
Avant
le compartiment contient 1 seul objet
{
Après
Compartiment avec la gestion des versions activée
Effacer un objet crée un marqueur de suppression (avec un identifiant de version non nul).
Avant
le compartiment contient 4 objets
obj1
avec 1 version (un upload)
obj2
avec 2 versions (deux uploads successifs): une courante, l’autre non
obj3
avec 2 versions (un upload puis un delete): une non courante avec data et une courante avec un marqueur de suppression (delete marker) sans data
obj4
avec 1 version (un upload, un delete et enfin un delete de la version non courante): un marqueur de suppression sans data
{
Après
le compartiment contient maintenant 3 objets
obj1
est effacé: la version courante est un marqueur de suppression
la data ancienne est conservée en version non courante
obj2
est effacé: la version courante est un marqueur de suppression
la data ancienne est conservée avec 2 versions non courantes
obj3
n’est pas modifié car déjà effacé
il n’y a rien à faire car la version courante est un marqueur de suppression
obj4 , au contraire, avait un seul marqueur de suppression (aussi appelé un marqueur de suppression expiré).
Dans ce cas, le marqueur de suppression a été supprimé (comme s’il n’avait jamais existé).
{
Compartiment avec la gestion des versions suspendue
Effacer un objet crée un marqueur de suppression (avec un identifiant de version null).
Avant
le compartiment contient 6 objets
les 4 premiers objets ont été créés avec la gestion des versions activée
obj1
avec 1 version (un upload)
obj2
avec 2 versions (deux uploads successifs): une courante, l’autre non
obj3
avec 2 versions (un upload puis un delete): une non courante avec data et une courante avec un marqueur de suppression (delete marker) sans data
obj4
avec 1 version (un upload, un delete et enfin un delete de la version non courante): un marqueur de suppression sans data
les 2 derniers objets ont été créés avec la gestion des versions suspendue (l’identifiant de version ( VersionId ) est toujours mis à null)
obj5
avec 1 version (un upload)
obj6
avec 1 version (1 upload et 1 delete): un marqueur de suppression
quand la gestion des versions est suspendue, l’effacement de la version courante est permanente
{
Après
le compartiment contient 6 objets
les 4 premiers objets ont été créés avec la gestion des versions activée
obj1
est effacé: la version courante est un marqueur de suppression
la data ancienne est conservée en version non courante
obj2
est effacé: la version courante est un marqueur de suppression
la data ancienne est conservée avec 2 versions non courantes
obj3
n’est pas modifié car déjà effacé
il n’y a rien à faire car la version courante est un marqueur de suppression
obj4
n’est pas modifié car déjà effacé
puisque ce marqueur de suppression a été créé avec la gestion des versions activée, il a un identifiant de version non nul
puisque le compartiment a maintenant la gestion des versions suspendue, il reste inchangé
les 2 derniers objets ont été créés avec la gestion des versions suspendue
obj5
est effacé: la version courante est un marqueur de suppression
la data ancienne a été supprimée
obj6
n’est pas modifié car déjà effacé
{
Effacer les versions non courantes
Observons comment NoncurrentVersionExpiration affecte les versions non courantes (c.-à-d. quand la metadata IsLatest est fausse (false)).
Configuration de cycle de vie
La configuration de cycle de vie suivante (format json) est appliquée à 3 compartiments (chacun dans un état différent de gestion des versions):
{
le filtre ( Filter ) a un prefix vide afin de traiter tous les objets (d’un compartiment)
le statut ( Status ) est activé (enabled) afin de rendre effective la configuration
l’action est Expiration afin d’effacer les versions courantes
le critère temporel pour l’action est un nombre de jours ( Days ) afin de déclencher l’action strictement après une certaine durée de vie des versions non courantes (un certain délai est à prévoir)
Compartiment avec la gestion des versions non activée
L’expiration des versions non courantes est sans objet dans ce cas.
Compartiment avec la gestion des versions activée
Avant
Voir #Après_2 .
Après
le compartiment est presque vide (seulement des marqueurs de suppression)
obj1
reste effacé: la version courante est un marqueur de suppression (pas de changement)
la version non courante avec de la data a été effacée
obj2
reste effacé: la version courante est un marqueur de suppression (pas de changement)
les 2 versions non courantes avec de la data ont été effacées
obj3
reste effacé: la version courante est un marqueur de suppression (pas de changement)
la version non courante avec de la data a été effacée
{
Compartiment avec la gestion des versions désactivée
ATTENTION : non supporté pour l’instant
Autres options
Effacer les uploads multipart incomplets
Un upload multipart (en plusieurs parties) est une bonne pratique pour un gros objet.
Cela permet d’améliorer le temps de transfert et de mieux récupérer en cas de problème réseau.
Vous pouvez utiliser l’action AbortIncompleteMultipartUpload pour supprimer les uploads multipart non terminés depuis un certain temps ( DaysAfterInitiation ).
{
Effacer les marqueurs de suppression expirés
Quand vous utilisez l’action Expiration avec les paramètres Days et Date, les marqueurs de suppression expirés et concernés sont effacés.
systématiquement tous les marqueurs de suppression expirés indépendamment de leur âge, vous pouvez utiliser le paramètre ExpiredObjectDeleteMarker.
Ce paramètre doit être utilisé seul dans une règle (rule).
{
A propos de sécurité
N’utilisez jamais une Access Key root
Avec une AK root, vous pouvez désactiver le cycle de vie, suspendre la gestion des versions et effacer les versions d’objet.
Réduisez les permissions
Pour un usage normal (PUT d’objets dans un bucket), vous devriez appliquer une policy supprimant (deny) les permissions suivantes:
s3:PutBucketVersioning (pour empêcher la modification du versioning)
s3:DeleteObjectVersion (pour empêcher l’effacement des versions d’objet et des marqueurs de suppression)
s3:PutLifeCycleConfiguration (pour empêcher la modification du cycle de vie)
s3:PutBucketLifecycle (idem mais déprécié)