PD-6 — Retour d'expérience¶

1. Résumé exécutif¶

La User Story PD-6 visait à activer la Cross-Region Replication (CRR) entre AWS S3 Paris (eu-west-3) et Frankfurt (eu-central-1) pour garantir la résilience géographique des archives probatoires WORM. L'implémentation fournit un sous-module Terraform frankfurt/ avec bucket destination Object Lock COMPLIANCE, rôle IAM CRR dédié, configuration CRR avec RTC (15 min SLA), et monitoring CloudWatch. Cependant, 1 écart MAJEUR est identifié : SSE-S3 au lieu de SSE-KMS avec clés distinctes Paris/Francfort, ainsi que 2 écarts MINEURS : nommage buckets divergent de la spec et metric BytesPendingReplication absente. Verdict : ACCEPTÉ AVEC RÉSERVES.

2. Points fluides¶

• CRR activée : réplication Paris → Frankfurt opérationnelle avec rule ID crr-paris-to-frankfurt
• RTC (Replication Time Control) : SLA 15 minutes garanti avec replication_time.status = "Enabled"
• Object Lock COMPLIANCE répliqué : mode COMPLIANCE identique source/destination
• Delete marker replication désactivée : conformité WORM (pas de suppression répliquée)
• Storage class DEEP_ARCHIVE : coût minimal sur la replica Frankfurt
• IAM role dédié : pv-crr-replication-role avec permissions minimales
• Permissions Object Lock : s3:PutObjectRetention, s3:PutObjectLegalHold incluses
• Bucket policies restrictives : DenyAllDeletes + HTTPSOnly sur Frankfurt
• Public access block : toutes options à true sur destination
• Versioning activé : prérequis CRR et Object Lock respecté
• prevent_destroy : protection Terraform contre suppression accidentelle
• Metrics CRR activées : metrics.status = "Enabled" avec event_threshold 15 min
• Tags conformité : NF-Z42-013, RetentionMax, Region, CRR role documentés
• Logging intentionnel : justification documentée (source has logging)
• replica_modifications : réplication des modifications de metadata activée
• Script de test : test-crr.sh disponible pour validation

3. Points difficiles¶

4. Hypothèses révélées tardivement¶

5. Invariants complexes à implémenter¶

6. Dette technique¶

7. Risques résiduels¶

8. Améliorations processus¶

9. Enseignements clés¶

1. S3 Object Lock COMPLIANCE + CRR = solution WORM complète — Glacier Vault Lock initialement prévu s'est révélé redondant. S3 Object Lock COMPLIANCE offre la même garantie d'immutabilité avec une architecture plus simple.

2. Delete marker replication doit être explicitement désactivée pour WORM — Par défaut, la CRR peut répliquer les delete markers, ce qui compromettrait l'immutabilité. Le paramètre delete_marker_replication.status = "Disabled" est critique pour la conformité.

3. RTC (Replication Time Control) est essentiel pour la conformité SLA — Le SLA 15 minutes garantit que les données sont répliquées dans un délai prévisible, critique pour la résilience probatoire. Cette fonctionnalité est payante mais justifiée.

4. Le logging sur le bucket destination CRR est optionnel — Le bucket source capture toutes les écritures. Le bucket destination ne reçoit des objets que via CRR, rendant le logging destination redondant. L'alerte SonarQube S6258 est documentée comme intentionnelle.

5. SSE-KMS CRR nécessite une configuration additionnelle significative — La réplication avec SSE-KMS requiert replica_kms_key_id, des permissions KMS cross-region, et un bloc sse_kms_encrypted_objects. Le choix SSE-S3 simplifie l'implémentation mais ne satisfait pas l'exigence de clés distinctes.