Téléversements multipart S3 : les frais de morceaux incomplets cachés dans votre compartiment et comment les nettoyer

Quand un téléversement multipart commence mais ne se termine jamais, chaque morceau déjà téléversé reste dans le compartiment et est facturé comme du stockage — indéfiniment — tout en restant invisible pour aws s3 ls et pour l’onglet des objets dans la console. Si votre facture S3 dit un chiffre et que votre listage d’objets en additionne un plus petit, les téléversements multipart incomplets sont le premier suspect. Le correctif : deux commandes pour les trouver et les avorter, plus une règle de cycle de vie pour qu’ils ne puissent plus jamais s’accumuler.

Ce qui se passe

Un téléversement multipart est un protocole en trois étapes : CreateMultipartUpload ouvre une session, UploadPart envoie les morceaux, et CompleteMultipartUpload les assemble en objet réel. Le CLI et les SDK l’utilisent automatiquement au-delà de leur seuil (8 Mo par défaut dans le CLI). Si le processus meurt entre l’étape un et l’étape trois — un déploiement annulé, un agent de sauvegarde qui a planté, une instance spot réclamée en plein transfert, un portable fermé sur un aws s3 cp — S3 garde les morceaux et attend une complétion qui ne viendra jamais.

Ces morceaux orphelins sont facturés au tarif normal au Go de la classe de stockage, mais ils ne sont pas encore des objets, donc rien de ce qui liste des objets ne les montrera jamais : ni list-objects-v2, ni la vue des objets dans la console, ni la plupart des navigateurs S3 tiers. Ils apparaissent à exactement trois endroits : l’API ListMultipartUploads, les métriques CloudWatch de taille de compartiment (qui incluent les octets de morceaux), et la métrique de téléversements multipart incomplets de Storage Lens. Les compartiments qui reçoivent de gros téléversements de clients peu fiables — cibles de sauvegarde, ingestion vidéo, zones d’atterrissage de pipelines de données — en accumulent pendant des années. La mécanique est documentée dans la documentation S3.

Quoi vérifier d’abord

• L’écart. Comparez CloudWatch BucketSizeBytes au total d’un listage --summarize; une différence persistante, ce sont des morceaux, des versions non courantes ou des marqueurs de suppression.
• Storage Lens. Le tableau de bord gratuit porte déjà une métrique d’octets de téléversements multipart incomplets par compartiment — la vue la plus rapide sur tout le parc.
• Quels compartiments reçoivent de gros téléversements. Les destinations de sauvegarde et les compartiments d’ingestion sont là où est l’argent.
• Si une règle d’avortement de cycle de vie existe déjà. Quelqu’un en a peut-être ajouté une qui ne couvre qu’un préfixe.

Comment vérifier

Listez les téléversements multipart ouverts dans un compartiment :

aws s3api list-multipart-uploads --bucket my-bucket \
  --query 'Uploads[].[Key,UploadId,Initiated]' --output table

Tout ce qui a été initié il y a des semaines ou des mois est du poids mort. Pour voir combien retient un seul téléversement en panne :

aws s3api list-parts --bucket my-bucket \
  --key backups/full-2026-03-14.tar.gz \
  --upload-id "$UPLOAD_ID" \
  --query 'Parts[].Size' --output text | tr '\t' '\n' | paste -sd+ - | bc

Pour le portrait à l’échelle du compte, ouvrez S3 > Storage Lens > Dashboards > default-account-dashboard et regardez la métrique d’octets de téléversements multipart incomplets — elle existe dans le palier gratuit et se ventile par compartiment. Comparez aux octets totaux du compartiment pour voir lesquels sont les pires.

Le correctif

1. Avortez les téléversements périmés. Chaque avortement supprime tous les morceaux de cette session et arrête la facturation immédiatement :

   aws s3api abort-multipart-upload \
     --bucket my-bucket \
     --key backups/full-2026-03-14.tar.gz \
     --upload-id "$UPLOAD_ID"

   Pour beaucoup de sessions périmées, bouclez sur le listage — mais vérifiez les dates Initiated et sautez tout ce qui date des derniers jours, parce qu’un téléversement légitimement en cours meurt de la même façon quand on l’avorte.

2. Ajoutez la règle de cycle de vie qui rend ça permanent. Une règle, filtre vide, qui s’applique à tout le compartiment :

   {
     "Rules": [
       {
         "ID": "abort-incomplete-mpu",
         "Status": "Enabled",
         "Filter": {},
         "AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
       }
     ]
   }

   Fusionnez-la dans la configuration existante (l’appel put remplace tout — voir Règles de cycle de vie S3) et appliquez avec aws s3api put-bucket-lifecycle-configuration. Sept jours tolère les téléversements reprenables lents tout en plafonnant le gaspillage.

3. Réparez le producteur qui échoue à répétition. Des téléversements incomplets récurrents signifient qu’un client meurt en plein transfert : une fenêtre de sauvegarde trop courte, un agent sans logique de reprise, des instances spot qui téléversent sans point de contrôle. La règle de cycle de vie essuie le plancher; cette étape ferme le robinet.

4. Vérifiez que la facture bouge vraiment. CloudWatch BucketSizeBytes devrait descendre un jour ou deux après les avortements; la ligne de facture suit au cycle suivant.

Quand ce n’est pas la bonne approche

N’avortez pas les téléversements initiés dans les derniers jours sur des compartiments avec de gros transferts actifs — les sessions réellement en cours ressemblent exactement aux mortes dans le listage, et en avorter une force le client à tout recommencer. Si l’écart de facture persiste après le nettoyage des morceaux, les octets restants sont habituellement des versions non courantes sur un compartiment versionné — une autre règle corrige ça. Et si un compartiment héberge légitimement des téléversements reprenables sur plusieurs semaines (rare, mais réel dans les flux médias), réglez DaysAfterInitiation au-dessus de la plus longue session légitime plutôt que de sauter la règle.

Erreurs courantes

• Se fier à aws s3 ls --summarize comme vraie taille du compartiment — il ne compte que les objets courants complétés, jamais les morceaux.
• Faire le nettoyage une fois et sauter la règle de cycle de vie, si bien que la même fuite d’argent rouvre en quelques mois.
• Avorter tout ce qui est dans le listage, incluant le téléversement de sauvegarde d’hier soir encore en cours.
• Ajouter la règle d’avortement avec put-bucket-lifecycle-configuration et effacer les règles existantes du compartiment, parce que l’appel remplace au lieu de fusionner.

Prévention

• Intégrez la règle d’avortement des MPU incomplets dans votre module de compartiment Terraform ou CloudFormation pour que chaque compartiment naisse avec.
• Surveillez la métrique Storage Lens des MPU incomplets chaque mois; une ligne qui monte signifie qu’un client échoue à répétition.
• Donnez aux clients de téléversement un comportement sain de reprise — les réglages de transfert du CLI (patrons de réglage ici) ou les gestionnaires de transfert des SDK.
• Après tout transfert manuel interrompu, prenez les trente secondes pour list-multipart-uploads plutôt que de laisser un souvenir.

C’est le correctif S3 le moins cher qui existe : un listage, une poignée d’avortements, une règle de cycle de vie, et un trou permanent dans la facture se referme. 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.