AWS Backup étend les copies intercomptes au cloud souverain européen

Des sauvegardes réparties entre comptes, avec un pilotage commun

Le 29 octobre 2026, AWS a annoncé la disponibilité de trois fonctions d’AWS Backup (service de sauvegarde d’AWS) dans la région Allemagne de son European Sovereign Cloud : gestion entre comptes, copie des sauvegardes entre comptes et administration déléguée. Une entreprise peut désormais appliquer des politiques communes, surveiller les opérations de sauvegarde, de copie et de restauration, puis conserver des points de récupération dans un autre compte de son organisation. Un point de récupération est la sauvegarde que vous sélectionnez pour préparer une restauration. Annonce AWS.

L’intérêt opérationnel tient à cette séparation. Selon AWS, copier les sauvegardes dans un autre compte ajoute une protection contre leur suppression accidentelle ou malveillante dans le compte source. Pour votre décision, distinguez donc le compte qui fait fonctionner l’application de celui qui reçoit les copies. Demandez ensuite qui peut administrer chacun : le choix du destinataire et des autorisations fait partie du projet.

L’administration déléguée répond à un autre besoin : confier la gestion des sauvegardes à un compte membre, sans donner aux équipes l’accès au compte de gestion de l’organisation. AWS annonce ces fonctions sans supplément propre à leur utilisation ; la tarification habituelle d’AWS Backup continue de s’appliquer. La décision doit ainsi porter sur l’organisation des responsabilités autant que sur la copie des données.

Les entreprises concernées et les limites à vérifier

Ce changement intéresse les PME françaises qui exploitent plusieurs comptes dans l’AWS European Sovereign Cloud, ou qui évaluent une architecture de sauvegarde avant d’y installer leurs applications. Le service est ouvert à tous les clients. En revanche, un compte AWS existant ne suffit pas : la FAQ officielle exige de créer un compte propre à cet environnement, indépendant des comptes utilisés dans les autres régions AWS. Ne traitez donc pas cette annonce comme une simple option à activer sur votre compte habituel.

La copie intercomptes exige que les comptes appartiennent à la même organisation AWS Organizations, le service qui regroupe et administre plusieurs comptes. Le coffre destinataire ne peut pas être le coffre par défaut. Vérifiez également les droits du rôle qui lance la copie et ceux du coffre qui la reçoit. Le guide de configuration détaille ces prérequis ; leur présence doit être contrôlée des deux côtés.

La disponibilité dépend aussi de la ressource sauvegardée et de la région. La matrice AWS Backup distingue ces deux dimensions. Faites vérifier chaque type de ressource de votre inventaire. Une fonction proposée pour un service ailleurs ne suffit pas à établir sa disponibilité dans votre environnement.

Le chiffrement conserve des conditions propres aux ressources

Pour les ressources entièrement gérées par AWS Backup, le coffre destinataire peut employer une clé gérée par le client ou la clé gérée par AWS Backup. Pour les autres ressources, le parcours direct de copie intercomptes impose une clé gérée par le client : les clés gérées par AWS ne peuvent pas être partagées entre comptes dans ce cas. Si une clé client chiffre la ressource source, son partage avec le compte destinataire doit aussi être préparé. Conditions de chiffrement.

Le guide décrit aussi un montage alternatif pour RDS (service AWS de bases de données relationnelles) avec une région intermédiaire. La matrice de disponibilité n’indique pas de copie interrégions pour la région souveraine : ce montage ne fournit donc pas une procédure directement transposable ici.

Ne concluez pas que toute copie devient automatiquement chiffrée : les copies de clusters (ensembles de serveurs de bases de données) Aurora, DocumentDB et Neptune non chiffrés restent non chiffrées. AWS Backup ne prend pas en charge les copies intercomptes destinées au stockage froid. Pour votre pilote, retenez donc un parcours en stockage courant. Les sauvegardes déjà placées en stockage froid ou en archive ne peuvent pas non plus être copiées.

Une autre limite concerne les sauvegardes continues : lorsqu’une copie est prise en charge, elle devient une sauvegarde périodique. Elle ne conserve pas la restauration à un instant précis, appelée PITR. Si votre besoin est de revenir juste avant une erreur, demandez à quelle date exacte la copie permettra réellement de revenir. Vérifiez aussi la conservation : le réglage Always (toujours) laisse l’expiration du point source primer sur celle de la copie. Ce réglage ne suffit donc pas à garantir une conservation indéfinie. Règles de copie.

Disponible depuis le 29 octobre, avec une mise en place à organiser

L’historique officiel d’AWS Backup confirme l’ajout de la gestion et des copies intercomptes dans cette région au 29 octobre 2026. L’annonce ne fixe aucune date limite de migration. Vous pouvez donc préparer un pilote et décider de son extension après vérification des résultats.

Ne confondez pas activation et reprise des anciennes opérations dans le suivi central : les tâches visibles sont celles créées après l’activation de la surveillance intercomptes. L’enregistrement d’un administrateur délégué ne lui donne pas, à lui seul, la gestion des politiques. Il faut aussi attribuer les permissions nécessaires et déléguer cette gestion dans AWS Organizations. Guide d’administration.

Prévoyez enfin le temps du parcours complet. AWS ne donne pas d’engagement de niveau de service sur le délai d’achèvement des copies. Pour restaurer dans un autre compte, il faut d’abord y copier la sauvegarde, puis la restaurer dans ce compte ; le rôle lié au service concerné doit y être présent. Mesurez ces étapes ensemble avant de fixer votre objectif de reprise.

Six actions pour décider et préparer le déploiement

• Délimitez le pilote. Choisissez une application, ses ressources et un compte destinataire autorisé. Faites vérifier leur prise en charge dans la région concernée. Écrivez le résultat attendu : quelle copie conserver, qui doit la surveiller et quelle restauration doit être démontrée. Gardez cette fiche comme critère de décision pour l’extension.

• Préparez les comptes et les droits. Depuis le compte de gestion, activez les fonctions nécessaires. Faites contrôler les permissions IAM (système de gestion des identités et des accès) : backup:CopyFromBackupVault côté source et backup:CopyIntoBackupVault dans le rôle source et la politique du coffre destinataire. Examinez les clés avant de lancer le premier essai.

• Cadrez l’administration déléguée. Désignez le compte membre responsable. Pour gérer les politiques, prévoyez AWSBackupOrganizationAdminAccess pour les identités concernées et la délégation dans AWS Organizations. Vérifiez les sélections : les politiques centrales ciblent des types de ressources ou des étiquettes, pas des identifiants individuels de ressources ; ces derniers nécessitent une affectation dans un plan local.

• Limitez les destinations. Faites approuver les comptes et coffres qui peuvent recevoir les copies. AWS recommande des politiques de contrôle de service pour restreindre ces destinations. Un compte qui quitte l’organisation conserve ses sauvegardes : examinez aussi le contrôle de cette sortie avant d’y envoyer des données.

• Exécutez une restauration complète. Contrôlez l’achèvement de la copie, restaurez dans le compte retenu et faites vérifier l’application par son responsable. Consignez la date récupérable et les durées observées. Le succès d’une tâche de copie ne doit pas être votre seul critère de réception.

• Chiffrez puis arbitrez. Évaluez le stockage conservé et les restaurations d’essai avec la page tarifaire, sans transposer ses exemples d’autres régions à votre budget. Décidez ensuite quelles applications étendre, avec quelle conservation et quelle fréquence d’essais. Formalisez qui traite un échec de copie et qui autorise la reprise.

Pour ce dispositif de copies intercomptes, le suivi des tâches, les alertes, le traitement des anomalies et les essais planifiés peuvent être confiés à VCSTS, avec un périmètre, des plages d’intervention et une fréquence d’essais définis dans le contrat.