Envoi multipart S3 : taille des parties, reprise et nettoyage

L'envoi multipart S3 transfère un fichier volumineux sous forme de plusieurs parties indépendantes, puis les assemble en un seul objet. Le client peut renvoyer une partie ayant échoué sans retransmettre tout le fichier. Les envois parallèles peuvent aussi améliorer le débit, selon le réseau, le client et la charge de travail.

Ce guide concerne les compartiments à usage général Amazon S3. Il présente un exemple Python et les vérifications nécessaires pour éviter l'accumulation d'envois inachevés. Pour choisir entre S3, disques et fichiers partagés, consultez notre guide du stockage cloud Amazon. Les liens techniques renvoient à la documentation en anglais.

Quand utiliser l'envoi multipart S3 ?

Le guide utilisateur Amazon S3 conseille d'envisager cette méthode à partir d'environ 100 Mo. Utilisez ce repère pour préparer vos tests. Les petits fichiers ne bénéficient pas forcément des requêtes supplémentaires. Pour un gros fichier sur une connexion instable, renvoyer seulement les parties interrompues peut être utile.

Pour un transfert courant depuis un serveur, commencez par une méthode gérée par le SDK AWS. Concevez votre propre parcours si vous devez conserver les sessions d'envoi, gérer un navigateur ou coordonner plusieurs processus. L'envoi multipart S3 est une suite d'opérations API, pas un formulaire HTTP multipart/form-data.

Les étapes d'un envoi multipart

1. Initialiser : demander un nouvel envoi pour un compartiment et une clé d'objet. S3 renvoie un identifiant d'envoi.
2. Envoyer les parties : transmettre chacune avec cet identifiant et son numéro, en conservant l'ETag et la somme de contrôle applicable.
3. Finaliser : soumettre la liste ordonnée des parties pour permettre leur assemblage.

Un client personnalisé fournit les métadonnées et paramètres de chiffrement de l'objet lors de la requête d'initialisation. Conservez ensemble le compartiment, la clé et l'identifiant d'envoi. Le nom du fichier ne suffit pas à identifier une session inachevée.

UploadPart accepte les parties indépendamment. Réutiliser le même numéro dans une session remplace la partie précédente. Un client personnalisé doit donc conserver les bonnes données de finalisation, sans traiter chaque réponse réussie comme une nouvelle partie.

Limites actuelles et choix de la taille des parties

Les limites AWS, vérifiées le 29 octobre 2026, sont les suivantes :

• Un objet de 48,8 Tio au maximum.
• Jusqu'à 10 000 parties, numérotées de 1 à 10 000.
• Des parties de 5 Mio à 5 Gio, sans minimum pour la dernière.

Les unités Mio et Gio utilisent des puissances de 1 024. Avant de commencer, divisez la taille du fichier par celle d'une partie et arrondissez au nombre entier supérieur. Respectez le nombre maximal de parties en tenant compte des plus gros fichiers acceptés par l'application.

Un fichier de 50 Gio découpé en parties de 64 Mio produit ainsi 800 parties. Le parcours de base comporte 802 opérations API : une initialisation, 800 envois et une finalisation, avant les nouvelles tentatives et les vérifications. Ce calcul sert à préparer le transfert ; il ne mesure pas ses performances.

Envoyer un fichier volumineux avec Boto3

Utilisez un compartiment de test privé, un fichier non sensible et un rôle AWS ou profil d'identifiants approuvé. Installez Boto3 dans votre environnement Python. N'insérez pas de clés d'accès dans le script. Remplacez le nom du compartiment et la région ci-dessous, puis placez le fichier de test à l'emplacement sample.bin.

La méthode upload_file gère le transfert. Cet exemple choisit une clé de destination unique à chaque exécution et demande des sommes de contrôle SHA-256 :

from pathlib import Path
from uuid import uuid4

import boto3
from boto3.s3.transfer import TransferConfig

MiB = 1024 ** 2
source = Path("sample.bin")
bucket = "YOUR_PRIVATE_TEST_BUCKET"
key = f"multipart-demo/{uuid4().hex}/{source.name}"

s3 = boto3.client("s3", region_name="us-east-1")
transfer = TransferConfig(
    multipart_threshold=128 * MiB,
    multipart_chunksize=64 * MiB,
    max_concurrency=4,
    preferred_transfer_client="classic",
)

s3.upload_file(
    str(source),
    bucket,
    key,
    Config=transfer,
    ExtraArgs={"ChecksumAlgorithm": "SHA256"},
)
print(f"Upload completed: s3://{bucket}/{key}")

La configuration du transfert distingue le seuil de passage au multipart de la taille de chaque partie. Ici, un fichier de 160 Mio donne deux parties de 64 Mio et une dernière de 32 Mio. La concurrence maximale est de quatre, sans garantir un débit multiplié par quatre.

L'exemple sélectionne explicitement le client de transfert classique pour préciser le contexte d'application des paramètres. Ajustez un seul réglage à la fois avec des fichiers représentatifs. Relevez la durée, les nouvelles tentatives, l'utilisation du processeur et la mémoire avant d'augmenter la concurrence.

Autorisations pour l'envoi et le nettoyage

Limitez l'identité signataire à la destination prévue. Les opérations d'envoi nécessitent l'autorisation s3:PutObject appropriée. Le nettoyage et l'inspection peuvent aussi nécessiter s3:AbortMultipartUpload, s3:ListMultipartUploadParts et s3:ListBucketMultipartUploads. Consultez la correspondance des permissions multipart, avec les politiques du compartiment et les droits d'accès aux clés de chiffrement.

Avec SSE-KMS, les autorisations KMS requises comptent également. Réussir l'initialisation ne prouve pas que les parties suivantes ou la finalisation seront autorisées. Testez le rôle réel de l'application plutôt que le compte d'un administrateur.

Distinguer nouvelle tentative et reprise après redémarrage

Le SDK gère les nouvelles tentatives applicables pendant le transfert. Ce script ne sauvegarde ni l'identifiant d'envoi ni les données des parties pour les réutiliser après l'arrêt du processus. Une nouvelle exécution génère une autre clé et commence un nouveau transfert, sans reprendre la session précédente.

Pour reprendre après un redémarrage, prévoyez des données persistantes : identité du fichier source, destination, identifiant d'envoi, numéros des parties, ETags et informations de contrôle d'intégrité. Vérifiez que le fichier source n'a pas changé avant de réutiliser ses parties. Définissez aussi le processus responsable de la finalisation et le moment où une session abandonnée doit être arrêtée.

L'API ListParts permet l'inspection et utilise la pagination. Conservez vos propres données d'envoi pour la finalisation, puis rapprochez-les des listes retournées. Des pages manquantes ou des requêtes encore en cours peuvent donner une vue incomplète.

Vérifier la finalisation et l'intégrité

Un ETag multipart n'est pas une empreinte MD5 fiable du fichier complet. S3 distingue les sommes de contrôle de l'objet entier des sommes composites ; la somme SHA-256 d'un envoi multipart est composite. Ne la comparez pas directement à l'empreinte SHA-256 ordinaire du fichier local complet. Suivez les règles de contrôle d'intégrité de l'algorithme et de la méthode choisis.

Pour un test limité, téléchargez l'objet finalisé avec un compte autorisé et comparez les octets, ou calculez localement la même empreinte du fichier entier sur les deux copies. Une taille identique ne prouve pas un contenu identique. Prévoyez le trafic et le stockage de vérification dans le budget du test.

Un client appelant directement CompleteMultipartUpload doit examiner le corps de la réponse : un statut HTTP 200 initial peut contenir une erreur. Les SDK AWS gèrent ce cas. Déclarez la tâche réussie seulement après une finalisation réussie, puis conservez la clé et les informations de version utiles à la récupération.

Arrêter les envois inachevés et maîtriser les coûts

Les parties envoyées occupent du stockage facturable jusqu'à la finalisation ou à l'annulation de l'envoi. L'échec d'une tâche applicative ne prouve pas que toutes ses parties ont été supprimées. Consultez la tarification S3 pour les requêtes, le stockage et les éventuels frais de récupération ou de transfert.

Pour inspecter le préfixe de test avec la CLI AWS, utilisez la liste des envois multipart :

aws s3api list-multipart-uploads --bucket YOUR_PRIVATE_TEST_BUCKET --prefix multipart-demo/

Examinez la clé, l'identifiant, l'heure d'initialisation et le propriétaire avant toute suppression. Après avoir arrêté les processus d'envoi du test, annulez uniquement la session jetable identifiée :

aws s3api abort-multipart-upload --bucket YOUR_PRIVATE_TEST_BUCKET --key "EXACT_TEST_KEY" --upload-id "EXACT_TEST_UPLOAD_ID"

La documentation de l'API d'annulation précise que des requêtes déjà en cours peuvent encore aboutir. Vérifiez qu'aucune partie ne subsiste ; une autre annulation peut être nécessaire si des envois concurrents ont continué. Évitez un nettoyage global touchant les sessions encore utilisées par une autre application.

Prévoir une règle de cycle de vie ciblée

Dans un compartiment à usage général, une règle AbortIncompleteMultipartUpload peut rendre les envois inachevés éligibles au nettoyage après un nombre de jours choisi. Ciblez le préfixe approprié et laissez assez de temps aux transferts légitimes de longue durée. Cette règle ne supprime pas les objets finalisés.

Examinez les paramètres de cycle de vie existants avant de l'ajouter. Gardez le nettoyage immédiat après échec dans l'application : la règle sert de recours, sans promettre une suppression à un instant précis.

Ce que les tests de l'exemple ont vérifié

Nous avons exécuté cet exemple localement avec Python 3.12.14 et Boto3/Botocore 1.43.121, des identifiants fictifs, des réponses S3 simulées et des connexions réseau bloquées. Les contrôles ont porté sur un envoi simple de 1 Mio, un envoi multipart de 160 Mio avec des données de finalisation ordonnées, et l'échec simulé d'une partie déclenchant une annulation.

Ces contrôles ne valident pas les permissions AWS réelles, l'acceptation des sommes de contrôle, les nouvelles tentatives réseau, le débit ou le délai des règles de cycle de vie. Avant la production :

• Effectuez des transferts simples et multipart avec le rôle réel de l'application.
• Récupérez le bon objet et comparez son contenu à la source.
• Testez séparément les interruptions réseau, les parties en échec et les redémarrages du processus.
• Vérifiez le nettoyage après échec et inspectez les sessions encore ouvertes.
• Mesurez les coûts et les ressources avec des fichiers et une concurrence représentatifs.

Notre guide du stockage cloud pour applications présente les décisions connexes. Avec un fournisseur compatible S3, vérifiez séparément les limites, les contrôles d'intégrité, le cycle de vie et le comportement du SDK. Cette procédure Amazon S3 ne démontre pas la prise en charge par un autre service ni par les compartiments de répertoire.