Aller au contenu

AWS Mis à jour le 2026-03-17

AWS Backup avec copie inter-régions et inter-comptes — le test de restauration qui prouve que ça fonctionne

AWS Backup centralise la sauvegarde sur EBS, RDS, EFS, DynamoDB, S3. Plans de sauvegarde, coffres avec copie inter-régions et inter-comptes, KMS, et la boucle de test de restauration qui transforme une sauvegarde verte en donnée prouvée récupérable.

Un exercice de reprise d’activité sur l’environnement d’un client en 2025 fait apparaître le trou que personne n’avait remarqué. AWS Backup tourne, le plan de sauvegarde couvre RDS, EBS, EFS et DynamoDB, la métrique CloudWatch NumberOfBackupJobsCompleted est verte sur 180 jours consécutifs. Puis l’équipe tente de restaurer la base de production depuis un point de récupération vieux de 30 jours dans un compte sandbox pour un audit de conformité, et la restauration échoue — le rôle IAM qu’AWS Backup est configuré pour assumer dans le compte sandbox n’a pas la bonne politique de trust, la clé KMS du compte source n’accorde pas le decrypt au rôle sandbox, et la récupération réelle depuis le coffre inter-comptes n’a jamais été exercée. La sauvegarde tournait. La restauration n’était pas prouvée. Le montage ci-dessous est celui qui le prouve.

Ce qui se passe

AWS Backup est une couche managée d’orchestration qui prend des snapshots sur plusieurs ressources AWS sur un planning et les stocke dans des coffres. Les ressources supportées se sont élargies régulièrement — volumes EBS, clusters RDS, systèmes de fichiers EFS, tables DynamoDB, FSx, S3, Aurora, Storage Gateway, VMware, Neptune, DocumentDB, Redshift, SAP HANA, Timestream. Pour la plupart des charges, AWS Backup remplace le mécanisme de snapshot par service (cycle de vie EBS, sauvegardes RDS automatisées) par une politique centralisée et un ensemble de coffres.

L’architecture a trois couches :

  • Plan de sauvegarde — planning, rétention, cycle de vie (transition vers stockage froid), actions de copie.
  • Coffre de sauvegarde — destination des points de récupération, chiffré avec une CMK KMS, avec Vault Lock optionnel pour l’immuabilité.
  • Assignation de ressources — sélectionne quelles ressources le plan couvre, par tag ou par liste d’ARN.

La partie inter-régions/inter-comptes est la couche de reprise d’activité. Un plan de sauvegarde peut copier chaque point de récupération vers un second coffre dans une autre région, un autre compte, ou les deux. Le coffre de destination a sa propre CMK KMS, sa propre politique de rétention, son propre état Vault Lock. Un désastre régional en us-east-1 n’emporte pas la copie inter-régions ; une compromission du compte de production n’emporte pas la copie inter-comptes (le coffre de destination est dans un compte AWS séparé avec des identifiants séparés).

Le mode de défaillance « la sauvegarde tourne mais la restauration n’a jamais été testée » est endémique. La métrique NumberOfBackupJobsCompleted ne dit rien sur la possibilité de restaurer le point de récupération qui en résulte. La preuve vient de réellement lancer une restauration, sur une cadence, avec une destination qui est une vraie récupération (pas un appel d’API no-op qui retourne succès sans faire le travail).

Comment vérifier

L’état du montage courant :

aws backup list-backup-plans \
  --query 'BackupPlansList[].[BackupPlanName,BackupPlanId,LastExecutionDate]' \
  --output table

aws backup list-backup-vaults \
  --query 'BackupVaultList[].[BackupVaultName,EncryptionKeyArn,NumberOfRecoveryPoints,Locked]' \
  --output table

Pour chaque plan, obtenir les détails complets — planning, cycle de vie, actions de copie :

aws backup get-backup-plan \
  --backup-plan-id <id> \
  --query 'BackupPlan.Rules[].[RuleName,ScheduleExpression,Lifecycle,CopyActions]' \
  --output yaml

Un plan sain a au moins une règle avec une CopyAction pointant vers un ARN de coffre dans une région différente (et idéalement un compte différent). Si CopyActions est vide, la sauvegarde n’a pas de copie inter-régions.

Pour la vérification du test de restauration :

aws backup list-restore-jobs \
  --by-created-after $(date -u -v-90d +%Y-%m-%dT%H:%M:%S) \
  --query 'RestoreJobs[].[CreationDate,Status,RecoveryPointArn,ResourceType]' \
  --output table

Le cas vide — aucun job de restauration sur les 90 derniers jours — signifie que la restauration n’a pas été exercée. La première restauration au moment de l’incident va découvrir le trou de configuration que l’équipe n’a pas testé à l’avance.

La correction

Le montage complet, déployable comme une stack CloudFormation dans chacun des trois comptes (charge, sauvegarde, DR) :

  1. Montage du coffre dans le compte sauvegarde. Un compte AWS dédié qui possède le coffre de sauvegarde centralisé. La CMK KMS est créée dans le compte sauvegarde ; les comptes de charge reçoivent une autorisation explicite sur la clé pour kms:Encrypt seul (ils peuvent écrire des sauvegardes chiffrées mais ne peuvent pas déchiffrer les points de récupération résultants sans invoquer AWS Backup) :

    BackupVault:
  Type: AWS::Backup::BackupVault
  Properties:
    BackupVaultName: central-prod-backup
    EncryptionKeyArn: !GetAtt BackupKmsKey.Arn
    AccessPolicy: !Ref VaultAccessPolicy

VaultLockConfiguration:
  Type: AWS::Backup::BackupVault
  Properties:
    BackupVaultName: central-prod-backup
    LockConfiguration:
      MinRetentionDays: 7
      MaxRetentionDays: 2555
      ChangeableForDays: 3

    La fenêtre ChangeableForDays: 3 est la période de refroidissement : le vault lock est réversible pendant les trois premiers jours, puis il se verrouille en mode compliance et ne peut être supprimé. Les coffres de production devraient atteindre le mode compliance dans la semaine du passage en ligne.

  2. Montage du coffre dans le compte DR. Patron identique dans un compte AWS séparé dans une région différente. L’action de copie du plan Backup cible ce coffre.

  3. Compte de charge : plan de sauvegarde, rôle IAM, et assignation de ressources :

    BackupRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Version: "2012-10-17"
      Statement:
        - Effect: Allow
          Principal: { Service: backup.amazonaws.com }
          Action: sts:AssumeRole
    ManagedPolicyArns:
      - arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForBackup
      - arn:aws:iam::aws:policy/service-role/AWSBackupServiceRolePolicyForRestores

ProdBackupPlan:
  Type: AWS::Backup::BackupPlan
  Properties:
    BackupPlan:
      BackupPlanName: prod-daily
      BackupPlanRule:
        - RuleName: daily
          TargetBackupVault: prod-local-backup
          ScheduleExpression: "cron(0 5 ? * * *)"
          Lifecycle:
            DeleteAfterDays: 35
          CopyActions:
            - DestinationBackupVaultArn: arn:aws:backup:us-east-1:222222222222:backup-vault:central-prod-backup
              Lifecycle:
                DeleteAfterDays: 365
            - DestinationBackupVaultArn: arn:aws:backup:eu-west-1:333333333333:backup-vault:dr-prod-backup
              Lifecycle:
                DeleteAfterDays: 365

ResourceAssignment:
  Type: AWS::Backup::BackupSelection
  Properties:
    BackupPlanId: !Ref ProdBackupPlan
    BackupSelection:
      SelectionName: prod-tagged
      IamRoleArn: !GetAtt BackupRole.Arn
      ListOfTags:
        - ConditionType: STRINGEQUALS
          ConditionKey: backup-tier
          ConditionValue: prod

    Les deux actions de copie dans la règle de plan produisent trois copies par sauvegarde : locale (rétention 35 jours), centrale dans un autre compte (rétention 365 jours), DR dans une autre région (rétention 365 jours).

  4. Pipeline de test de restauration. Une tâche planifiée (cron EventBridge + Lambda ou un projet CodeBuild) qui effectue une restauration depuis le coffre DR toutes les deux semaines. La tâche :

    • Choisit le point de récupération le plus récent d’une ressource choisie (une base RDS sandbox non critique est une bonne cible).
    • Initie la restauration dans un compte sandbox.
    • Sonde le statut de restauration jusqu’à complétion.
    • Vérifie que la ressource restaurée existe, l’interroge brièvement pour confirmer que la donnée est lisible.
    • Supprime la ressource restaurée.
    • Rapporte succès/échec au canal d’astreinte.

    La ressource choisie compte : tester la restauration sur la base de production elle-même serait perturbant, donc la cible du test est une copie sandbox qui a le même schéma et à peu près le même volume de donnée. Le but est d’exercer le chemin de trust IAM, l’autorisation KMS, la configuration réseau et le chemin de création de ressource — pas de valider la donnée de production elle-même.

  5. Alarme CloudWatch sur échec de job de sauvegarde. L’alarme de l’article de baseline de cette série couvre NumberOfBackupJobsFailed > 0 sur une heure. Le pipeline de test de restauration contribue sa propre métrique — RestoreTestFailureCount publiée à CloudWatch — qui est la seconde alarme.

Trois règles sur chaque mission d’implémentation de sauvegarde :

Inter-régions et inter-comptes, les deux. L’inter-régions défend contre les pannes régionales et les désastres régionaux. L’inter-comptes défend contre la compromission d’identifiants. Les deux ensemble sont le plancher — l’un seul a un vrai mode de défaillance.

Vault Lock en mode compliance. Le verrou empêche les opérateurs de rançongiciels (ou un admin compromis) de supprimer les points de récupération. Les coffres de production devraient être en mode compliance dans la semaine du passage en ligne. La fenêtre de refroidissement est courte parce que le verrou est le contrôle de sécurité qui justifie la sauvegarde.

Test de restauration sur une cadence bimensuelle. Les métriques de sauvegarde disent que la sauvegarde a tourné. Les tests de restauration disent que le point de récupération est récupérable. La première restauration lors d’un incident est trop tard pour découvrir que le trust IAM est faux.

Le déploiement complet sur une AWS Organization neuve tient en trois jours concentrés — l’essentiel est la matrice de trust IAM entre les comptes de charge, sauvegarde et DR. Le coût continu est de deux heures par trimestre pour la revue du test de restauration. L’exercice qui a trouvé le trou de restauration inter-comptes dans l’histoire d’ouverture l’aurait attrapé dans les deux premières semaines de mise en service du pipeline de test.

Stack Harbor opère le nettoyage IAM, la baseline CloudWatch, AWS Backup et le rythme de contrôle des coûts dans le cadre de Gestion AWS et des Environnements infogérés en continu. Si la métrique de sauvegarde est verte mais personne n’a restauré depuis en six mois, commencez par une consultation d’infrastructure.