Résumé

  • Les parties déjà envoyées à S3 occupent du stockage payant jusqu’à la finalisation ou à l’abandon du transfert. Un échec enregistré dans l’application ne règle pas leur sort.
  • La purge après sept jours est un exemple de configuration pour les compartiments à usage général. Les compartiments de répertoire n’offrent pas ce même mécanisme de cycle de vie.

Il manque souvent une personne à la réunion qui enterre un projet : celle qui sait où sont ses cartons. Dans une entreprise qui expédie de gros fichiers vers Amazon S3, ces cartons peuvent être des fragments de transfert. Le budget de production est clos, le client est passé à autre chose, mais le garde-meuble n’a reçu aucun départ.

Cette scène est hypothétique. Son ressort technique figure, lui, dans la documentation d’AWS : les parties envoyées séparément restent stockées et facturées jusqu’à ce que le transfert soit finalisé ou abandonné. Le système permet de recommencer seulement les parties ratées et de reprendre plus tard. Il n’attache pas, par nature, une date d’expiration à cette attente. La finalisation assemble l’objet ; cet objet a ensuite son propre coût de stockage. Fonctionnement des transferts multipartites.

Une patience qui rend service

Le fournisseur conserve quelque chose d’utile : du travail déjà effectué. Sur une liaison irrégulière, jeter tous les fragments à la première interruption obligerait à refaire le trajet. Garder les morceaux permet d’acheter du temps. Le problème commence lorsque personne ne sait plus ce que ce temps doit permettre.

Une équipe peut raisonnablement vouloir attendre le retour d’un équipement, la disponibilité d’un opérateur ou la reprise d’une livraison. Elle peut tout aussi raisonnablement décider que ce transfert n’aura jamais de suite. S3 n’assiste pas à cette décision. Il connaît l’état du transfert, pas la lassitude du chef de projet.

C’est là que le dossier mérite de sortir du service technique. La dépense achète une possibilité de reprise. Elle devrait donc avoir un propriétaire capable de dire pourquoi cette possibilité vaut encore son prix. Sans lui, le stockage possède une justification passée et une facture présente, combinaison très confortable pour survivre à plusieurs réunions de réduction des coûts.

Sept jours, à condition de les avoir décidés

AWS décrit une action de cycle de vie, AbortIncompleteMultipartUpload, qui rend les transferts incomplets admissibles à l’abandon après un nombre de jours défini depuis leur lancement. S3 les arrête puis supprime les parties. La règle peut viser des transferts déjà présents et futurs ; elle ne supprime pas les objets achevés. Le délai de sept jours montré dans la documentation est un exemple à configurer. Règle de suppression des transferts incomplets.

Il serait commode qu’un exemple de documentation se transforme tout seul en politique d’entreprise. Il faut malheureusement choisir. Un délai bref économise du stockage abandonné, mais peut détruire l’avancement d’un transfert encore attendu. Un délai généreux préserve davantage de possibilités et davantage de loyers.

Le choix doit suivre le travail. Une livraison qui peut reprendre demain et un export dont la source ne reviendra qu’après une intervention n’ont pas le même calendrier. La suppression de ces parties incomplètes n’entraîne pas de frais de suppression anticipée, précise AWS. Le sacrifice économique se trouve ailleurs : dans le travail à refaire si l’on a fermé trop tôt la possibilité de poursuivre.

L’intendance ne se résume pas au bouton

AWS ajoute un détail très concret à l’abandon manuel : des parties déjà en cours d’envoi peuvent encore réussir ou échouer. Plusieurs opérations d’abandon peuvent être nécessaires pour libérer tout le stockage, et le fournisseur recommande de vérifier que la liste des parties est vide. Référence d’AbortMultipartUpload.

Pour un dirigeant, l’intérêt de ce détail tient au partage des responsabilités. Une personne peut arrêter le travail côté métier alors qu’un processus poursuit son activité côté transfert. Quelqu’un doit posséder la fin entière, y compris ce qui arrive encore à quai. Sinon, chaque intervenant a fini son geste et personne n’a fini la dépense.

Même le mot « compartiment » cache une différence de produit. Les compartiments de répertoire conservent eux aussi des parties facturables, mais ne prennent pas en charge les configurations S3 Lifecycle. Il faut terminer ou abandonner leurs transferts en cours avant de supprimer le compartiment. Une politique conçue pour un compartiment à usage général ne fournit donc pas automatiquement le même ménage ailleurs. Particularités des compartiments de répertoire.

Pour chiffrer un gaspillage réel, il manque l’inventaire du compte, l’utilité restante des transferts et les factures ; des reprises toujours nécessaires changeraient le diagnostic. La question de gestion est déjà nette : qui peut justifier la présence de ces morceaux, et qui est autorisé à fermer leur avenir ?

Un transfert réussi obtient facilement une ligne dans le compte rendu. Un transfert abandonné mérite lui aussi une fin vérifiable. Les projets fantômes n’ont pas besoin de salariés pour continuer à louer de la place.