Réplication S3 : configurer les copies et vérifier la reprise

La réplication S3 copie de manière asynchrone les objets éligibles entre des compartiments Amazon S3. Utilisez Same-Region Replication (SRR) dans une même région AWS, Cross-Region Replication (CRR) vers une autre région et Batch Replication pour les objets existants. Enregistrer une règle ne suffit pas : il faut vérifier les copies obtenues et leur utilisation pour la reprise.

Ce guide s’adresse aux équipes qui configurent la réplication de compartiments S3 à usage général. Il explique les méthodes, les permissions, un petit exercice de validation, les suppressions et la supervision. Les commandes présentées lisent la configuration et les métadonnées ; elles ne créent aucune règle et ne suppriment aucune donnée.

Choisir la méthode selon un besoin précis

AWS distingue la réplication continue et à la demande. La première copie les nouvelles écritures éligibles après la mise en place d’une règle, dans un même compte ou entre plusieurs comptes.

• Same-Region Replication : à envisager lorsqu’une autre équipe ou un autre compte a besoin d’une copie dans la même région. Séparer les comptes et séparer les lieux répond à des besoins différents.
• Cross-Region Replication : à envisager si le site de reprise ou une application consommatrice se trouve dans une autre région. Définissez comment l’application utilisera cette copie.
• Batch Replication : permet de traiter un ensemble défini d’objets existants, notamment certains objets dont la réplication a échoué. Vérifiez le périmètre du traitement avant son lancement.

Identifiez qui doit lire la destination et dans quel scénario. « Un deuxième compartiment » reste difficile à tester. Une exigence plus précise serait : l’équipe de reprise peut lire l’export quotidien terminé depuis le compte de destination, avec son rôle de reprise, sans dépendre des identifiants de l’application d’origine. Notre guide du stockage cloud Amazon aide à choisir le service adapté.

Vérifier les versions, la propriété et les permissions

La gestion des versions doit être activée sur les deux compartiments. Si la source utilise Object Lock, la destination doit également avoir Object Lock activé. Consultez les prérequis de réplication. Avant de modifier un compartiment existant, examinez les effets sur la conservation des versions et les coûts.

Utilisez un profil AWS CLI autorisé. Ces commandes lisent l’état des versions. Remplacez les noms, le profil et les régions ; un contrôle entre comptes peut nécessiter un autre profil pour la destination.

aws s3api get-bucket-versioning --bucket amzn-s3-demo-source --profile storage-review --region eu-west-1
aws s3api get-bucket-versioning --bucket amzn-s3-demo-destination --profile storage-review --region eu-central-1

Chaque réponse doit indiquer Status: Enabled. Une valeur absente ou Suspended ne signifie pas la même chose. La référence get-bucket-versioning décrit la réponse. Une erreur d’accès laisse le contrôle incomplet ; elle ne prouve pas que les versions sont désactivées.

Le rôle IAM de réplication permet à Amazon S3 de lire les versions sources concernées et d’écrire les réplicas. Ses permissions sont distinctes de celles de l’opérateur. Limitez les accès aux ressources prévues. Entre comptes, vérifiez aussi la politique du compartiment de destination et la propriété des réplicas. Suivez le guide des permissions au lieu d’élargir tous les accès pour contourner une erreur.

Configurer explicitement le chiffrement KMS

Les objets SSE-KMS et DSSE-KMS demandent une activation explicite de leur réplication, une clé KMS de destination adaptée et les permissions correspondantes. Cette clé doit se trouver dans la région de destination. L’acceptation d’une configuration ne valide pas l’utilisation de la clé. Vérifiez les conditions de réplication des objets chiffrés, puis testez le mode réellement utilisé par l’application.

Commencer par une règle de réplication limitée

Pour le premier exercice, utilisez des compartiments de test approuvés et un préfixe dédié, comme replication-test/. Écartez les données sans rapport avec l’essai. Notez les identifiants des comptes, les régions, les noms des compartiments, l’identifiant de la règle et la classe de stockage prévue pour permettre une relecture indépendante.

1. Dans l’onglet Management du compartiment source, créez une règle portant un nom clair.
2. Limitez-la au préfixe de test. Sélectionnez le compartiment de destination et le rôle de réplication vérifié.
3. Choisissez explicitement la classe de stockage, le chiffrement, la propriété des réplicas et le traitement des marqueurs de suppression.
4. Activez les métriques si vous souhaitez suivre cette règle dans le temps, après examen des frais supplémentaires.
5. Enregistrez la règle et relisez sa configuration avant d’ajouter un nouvel objet de test non sensible.

La présentation AWS de la configuration explique les filtres par préfixe et étiquettes. Si vous utilisez des étiquettes, testez leur présence dans le chemin d’envoi réel. Ne supposez pas que tous les producteurs de données les ajoutent correctement. Le premier exercice doit rester assez petit pour contrôler chaque objet attendu.

Relisez la configuration du compartiment source :

aws s3api get-bucket-replication --bucket amzn-s3-demo-source --profile storage-review --region eu-west-1 --output json

Vérifiez l’activation de la règle, son filtre, son rôle et l’ARN de destination. L’API de configuration peut brièvement afficher un état antérieur pendant la propagation d’une modification. Une lecture réussie ne prouve pas que les objets ont été répliqués.

Traiter les objets existants séparément

La réplication continue ne recopie pas automatiquement les anciennes données. S3 Batch Replication utilise un traitement Batch Operations et un manifeste pour sélectionner les objets existants. Il faut une configuration de réplication à la source et des permissions adaptées au traitement. Demandez un rapport de fin et examinez les échecs : un traitement terminé ne signifie pas que tous ses objets ont réussi.

Séparez l’historique des nouvelles écritures dans votre compte rendu. Par exemple, conservez une liste attendue pour les exports d’hier, puis utilisez celui d’aujourd’hui pour tester la réplication continue. Quelques nouveaux réplicas ne doivent pas donner l’impression que tout l’historique a été couvert.

Avant un gros traitement, vérifiez les classes de stockage éligibles et l’interaction avec les règles de cycle de vie. Ne suspendez pas sans examen les règles de conservation ou d’expiration en production. Convenez avec le responsable des données du traitement des anciennes versions, des objets supprimés et de toute modification temporaire de politique.

Définir l’effet des suppressions

Avec les règles actuelles, les marqueurs de suppression créés par l’utilisateur ne sont pas copiés par défaut. Activer leur réplication peut rendre l’objet également invisible à destination. Cette option ne fonctionne pas avec les règles fondées sur des étiquettes, et les marqueurs créés par le cycle de vie ne sont pas répliqués. Consultez le comportement des marqueurs de suppression.

La suppression définitive d’une version précise à la source n’est pas répliquée. Les configurations du compartiment, comme les règles de cycle de vie, ne sont pas copiées avec les objets. Les exclusions de réplication précisent ces limites. Examinez donc séparément les accès et la conservation à destination.

Vérifiez d’abord les copies. Si un essai ultérieur comporte une suppression, utilisez des objets jetables dans la zone convenue et notez le résultat attendu de chaque côté. Un fichier encore utile à quelqu’un ne doit pas servir à découvrir l’effet d’une option.

Vérifier la version exacte de l’objet

Relevez l’identifiant de version fourni lors de l’envoi ou dans la liste des versions à la source. Remplacez SOURCE_VERSION_ID par cette valeur :

aws s3api head-object --bucket amzn-s3-demo-source --key replication-test/sample.txt --version-id SOURCE_VERSION_ID --profile storage-review --region eu-west-1 --query "{VersionId:VersionId,ReplicationStatus:ReplicationStatus,Bytes:ContentLength}" --output json

Pour une réplication ordinaire dans un seul sens, la source indique PENDING, COMPLETED ou FAILED ; le réplica indique REPLICA. Consultez la référence des états pour les destinations multiples et replica modification sync. L’absence d’état ne vaut pas réussite : vérifiez l’éligibilité de la version et son inclusion dans la règle.

Repérez la version attendue à destination et utilisez son identifiant dans ce contrôle :

aws s3api head-object --bucket amzn-s3-demo-destination --key replication-test/sample.txt --version-id REPLICA_VERSION_ID --profile storage-review --region eu-central-1 --query "{VersionId:VersionId,ReplicationStatus:ReplicationStatus,Bytes:ContentLength}" --output json

HeadObject lit les métadonnées sans télécharger le contenu. La taille permet de repérer certaines erreurs, mais deux tailles identiques ne prouvent pas l’égalité des contenus. Lisez un réplica représentatif avec l’identité prévue pour la reprise, comparez-le à l’échantillon source conservé et vérifiez que l’application peut l’utiliser.

Conservez la liste des objets attendus avec ces résultats. Un fichier correct ne valide pas tout un préfixe, toutes les anciennes versions ou la restauration d’un export de base de données. Notre guide des tests de restauration décrit l’exercice plus large.

Surveiller les retards et les échecs

Les métriques de réplication indiquent les octets et opérations en attente, la latence et les opérations en échec. Elles peuvent être activées sans Replication Time Control. Utilisez les événements d’échec et les rapports pour rechercher les objets concernés. L’absence d’alerte n’est informative que si la supervision fonctionne et reçoit des données.

S3 Replication Time Control ajoute un seuil de 15 minutes, des notifications et des conditions de niveau de service. Cela ne garantit pas que chaque objet ou opération termine dans ce délai. La réplication reste asynchrone et ne garantit pas, à elle seule, une application sans perte de données. Batch Replication exige son propre suivi.

Désignez un responsable lorsqu’une file d’attente augmente. Examinez les changements du rôle, de la politique de destination, des versions et des clés avant de recréer les règles. Pour les objets déjà en échec, corrigez la cause et organisez une nouvelle tentative contrôlée, par exemple un traitement Batch Replication limité. Une configuration réparée ne prouve pas que les échecs antérieurs sont résolus.

Budgéter la copie et préparer la reprise

Prévoyez le stockage à destination, les versions conservées, les requêtes de réplication, les transferts entre régions lorsqu’ils s’appliquent et les frais éventuels de Batch, RTC, supervision et KMS. Utilisez les régions et classes réelles sur la page tarifaire S3. Le seul volume des données ne détermine pas la facture.

Avant de compter sur la réplication, fixez le retard maximal acceptable et décrivez comment l’application basculera vers la destination. Incluez les identifiants, l’accès aux clés, les dépendances et le retour au fonctionnement habituel. Une copie inaccessible à l’équipe de reprise ne répond pas à ce besoin.

La réplication peut contribuer à un plan de sauvegarde cloud, mais la conservation indépendante et les essais de restauration demandent des décisions explicites. Pour Hivenet ou un autre fournisseur compatible S3, vérifiez ses capacités propres. La compatibilité avec l’API S3 ne prouve pas la prise en charge des fonctions de réplication AWS.