Aller au contenu

AWS Mis à jour le 2026-10-07

La réplication S3 ne réplique pas : la liste de vérification

Quand la réplication S3 est activée mais que des objets n'arrivent jamais dans le bucket de destination, le statut de réplication d'un seul objet vous met sur la piste. Passez ensuite en revue les causes habituelles, des objets antérieurs à la règle aux permissions manquantes sur les clés de chiffrement ou le rôle.

Quand vous activez la réplication Amazon S3 et que des objets n’apparaissent jamais dans le bucket de destination, ou affichent le statut FAILED, cette liste de vérification vous aide à trouver pourquoi. Dans la plupart des cas, la réplication fait exactement ce que la règle lui demande, et la règle couvre moins de choses que prévu. Quatre causes expliquent presque tous les cas. La réplication ne copie que les objets écrits après la création de la règle, donc les objets plus anciens exigent une tâche de rattrapage distincte appelée S3 Batch Replication. Les objets chiffrés avec SSE-KMS (chiffrement côté serveur avec des clés gérées dans AWS Key Management Service) sont sautés, sauf si la règle les inclut et que le rôle de réplication peut utiliser les deux clés. Le filtre de la règle, qui la limite aux noms d’objets portant un certain préfixe ou une certaine étiquette, peut aussi ne pas correspondre aux objets que vous vérifiez. Enfin, le rôle IAM qu’utilise S3 pour copier les objets (une identité AWS dotée de ses propres permissions) peut manquer d’une permission du côté source ou destination. Commencez par un seul objet manquant, car son champ ReplicationStatus vous indique laquelle de ces pistes suivre.

Ce qui se passe

La réplication est asynchrone et pilotée par règles : le versionnage doit être activé sur les buckets source et destination, une configuration de réplication sur la source nomme une destination et un rôle IAM, et S3 assume ce rôle pour lire les versions de la source et les écrire dans la destination. La plupart des objets se répliquent en quelques minutes ; il n’y a pas de SLA ferme sauf si vous activez Replication Time Control (RTC), qui vise 15 minutes et ajoute un coût par Go et de surveillance.

La liste des exclusions est là où vivent les surprises. La réplication ne touche pas : les objets qui existaient avant la règle (par design), les objets chiffrés SSE-C (jamais réplicables), les objets SSE-KMS sauf si la règle y consent et que le rôle a kms:Decrypt sur la clé source et kms:Encrypt/kms:GenerateDataKey sur la clé destination, les objets que le propriétaire du bucket source ne possède pas (téléversements inter-comptes sous l’ancien régime d’ACL), les objets qui sont eux-mêmes des répliques d’une autre règle (pas de chaînage), et — selon les réglages de la règle — les marqueurs de suppression. Les suppressions de versions précises ne se répliquent jamais, délibérément, pour qu’une source compromise ne puisse pas purger votre réplique.

Chaque objet source porte un ReplicationStatus : PENDING, COMPLETED, FAILED, ou rien du tout. L’absence est la valeur la plus diagnostique — elle signifie qu’aucune règle n’a couvert cet objet en premier lieu.

Quoi vérifier en premier

  • Le versionnage est-il Enabled sur les deux buckets — pas suspendu, d’aucun côté?
  • Les objets manquants ont-ils été écrits avant l’existence de la règle? Comparez le LastModified des objets à la date de création de la règle.
  • Le filtre de la règle (préfixe ou étiquettes) correspond-il vraiment aux clés que vous attendez?
  • Les objets sont-ils chiffrés SSE-KMS, et la règle montre-t-elle la réplication KMS activée?
  • Destination dans un autre compte : la politique du bucket destination permet-elle le rôle de réplication, et la translation de propriété est-elle configurée?

Comment vérifier

Partez d’un objet manquant concret — son statut nomme la classe d’échec :

aws s3api head-object --bucket source-bucket --key data/file.parquet \
  --query '[ReplicationStatus, ServerSideEncryption, SSEKMSKeyId, LastModified]'

FAILED pointe vers les permissions ou KMS sur le chemin destination ; PENDING pendant des heures pointe vers un arriéré ou une limitation ; aucun champ de statut signifie que la règle n’a jamais couvert l’objet. Puis lisez la configuration d’un œil critique :

aws s3api get-bucket-replication --bucket source-bucket
aws s3api get-bucket-versioning --bucket source-bucket
aws s3api get-bucket-versioning --bucket dest-bucket

Vérifiez ce que le rôle peut réellement faire — la politique de confiance doit permettre s3.amazonaws.com, et la politique de permissions exige s3:GetObjectVersionForReplication, s3:GetObjectVersionAcl, s3:GetObjectVersionTagging sur la source, et s3:ReplicateObject, s3:ReplicateDelete, s3:ReplicateTags sur la destination :

aws iam get-role --role-name s3-replication-role --query 'Role.AssumeRolePolicyDocument'
aws iam list-attached-role-policies --role-name s3-replication-role

Les métriques CloudWatch de réplication existent par règle quand RTC ou les métriques de réplication sont activés : ReplicationLatency, BytesPendingReplication, OperationsPendingReplication sous l’espace de noms AWS/S3. Console : S3 > Buckets > source-bucket > Management > Replication rules et Metrics.

La liste de vérification

  1. Versionnage activé des deux côtés. Suspendu compte comme brisé pour la réplication. Corrigez, et notez que seuls les objets écrits après la réactivation se répliqueront.
  2. La portée de la règle correspond aux clés. Un filtre de préfixe data/ ne couvre ni Data/ ni prod-data/. Élargissez le filtre ou ajoutez des règles — et rappelez-vous que plusieurs règles exigent des priorités distinctes.
  3. Les objets préexistants exigent Batch Replication. Depuis l’écran de la règle (ou aws s3control create-job), lancez une tâche S3 Batch Replication pour rattraper tout ce qui a été écrit avant la règle. C’est la réponse à « j’ai activé la réplication et mes 10 To ne copient pas ».
  4. KMS géré explicitement. Dans la règle, activez la réplication des objets chiffrés KMS et précisez la clé KMS de destination ; accordez au rôle kms:Decrypt dans la politique de la clé source et kms:GenerateDataKey/kms:Encrypt dans celle de la clé destination. Entre comptes, les deux politiques de clés doivent nommer le rôle explicitement.
  5. Politique du bucket destination et propriété entre comptes. La politique du bucket destination doit permettre au rôle s3:ReplicateObject/s3:ReplicateDelete sur dest-bucket/*, et réglez Owner override to destination pour que les répliques appartiennent au compte destination — sinon le propriétaire de la destination pourrait ne pas pouvoir lire ses propres répliques.
  6. Réplication des marqueurs de suppression réglée volontairement. C’est une bascule par règle. Si votre plan de relève attend que les suppressions se propagent, activez-la ; si votre plan anti-rançongiciel attend qu’elles ne se propagent pas, laissez-la éteinte — mais décidez, ne découvrez pas.
  7. Statuts FAILED après correctifs : relancez avec Batch Replication. Corriger le rôle ne réplique pas rétroactivement les objets marqués FAILED ; une tâche Batch Replication limitée au préfixe touché les retraite.

Quand c’est la mauvaise approche

La réplication n’est pas une sauvegarde. Elle copie fidèlement les écrasements et (si activé) propage les marqueurs de suppression — la corruption se réplique aussi efficacement que les données. Si l’exigence est la récupération à un point dans le temps ou la résilience au rançongiciel, il vous faut le versionnage plus AWS Backup ou des copies de type coffre avec des identifiants séparés, pas seulement une réplique vivante. Et pour une copie ponctuelle de bucket, aws s3 sync ou S3 Batch Operations Copy est plus simple que de monter la réplication.

Erreurs fréquentes

  • Activer la réplication, vérifier cinq minutes plus tard que les vieux objets n’ont pas copié, et conclure que c’est brisé — les données préexistantes n’ont jamais été dans la portée.
  • Tester avec le téléverseur de la console sous le chiffrement par défaut du bucket (SSE-KMS) pendant que la règle a la réplication KMS éteinte — les objets de test sont sautés en silence.
  • Se fier aux comptes de aws s3 ls pour comparer les buckets ; utilisez des rapports d’inventaire ou au moins list-objects-v2 avec des comptes par préfixe, parce que les répliques de marqueurs et les piles versionnées font mentir la comparaison à l’œil.
  • Supprimer une version sur la source et s’attendre à ce que la version répliquée disparaisse — les suppressions de versions ne se répliquent volontairement pas.

Prévention

  • Activez les métriques de réplication (ou RTC quand la cible de 15 minutes justifie le coût) et alarmez sur OperationsPendingReplication qui grossit sans se vider.
  • Planifiez un rapport S3 Inventory hebdomadaire sur les deux buckets et comparez comptes d’objets et sommes de contrôle par préfixe — la seule comparaison qui tient à l’échelle.
  • Gardez la politique du rôle de réplication en IaC à côté des définitions de buckets, pour qu’une rotation de clé ou un renommage mette à jour les deux côtés ensemble.
  • Relancez une tâche Batch Replication ciblée après tout incident ayant produit des statuts FAILED, et consignez-le dans les notes d’incident. La liste des exigences de réplication sur https://docs.aws.amazon.com/AmazonS3/ mérite une relecture à chaque changement de règle.

Le débogage de réplication est une liste fermée, pas une enquête — le ReplicationStatus d’un objet plus les sept points ci-dessus localisent la rupture à tout coup. 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.