Amazon EBS étend les Volume Clones à la copie entre comptes AWS
AWS étend les Volume Clones d’Amazon EBS à la copie entre comptes, avec un réchiffrement optionnel dans le compte cible. Les équipes multi-comptes peuvent désormais rafraîchir leurs environnements de test avec des données de production à jour, à condition de maîtriser les contraintes de chiffrement et de zone.
9 septembre 2026. AWS étend ses Volume Clones d’Amazon EBS à la copie entre comptes, un an après les avoir introduits pour des copies instantanées au sein d’une même zone de disponibilité. Concrètement, un volume peut désormais être partagé vers un autre compte via AWS RAM, puis copié dans ce compte avec un réchiffrement optionnel. Pour toute organisation qui isole ses comptes par environnement, c’est la fin d’un casse-tête récurrent : rafraîchir un bac de test avec des données de production à jour sans jamais toucher à la production.
Ce que change la copie entre comptes
Les Volume Clones répondent à un besoin précis : obtenir une copie à un instant T d’un volume, sans attendre la durée d’un snapshot classique et sans la contrainte de restauration. L’an dernier, AWS les avait cantonnés à un usage intra-compte, au sein d’une seule zone de disponibilité. La limite était frustrante pour les organisations structurées en comptes multiples, où la production vit dans un compte, les tests dans un autre, et le développement dans un troisième.
Le mécanisme est désormais simple. Le propriétaire du volume partage celui-ci vers le compte cible dans AWS Resource Access Manager (RAM), le service qui permet de partager des ressources entre comptes ou au sein d’une Organisation AWS. Le compte cible accepte le partage, voit le volume apparaître dans sa console Amazon EBS, puis lance une copie du volume. Le flux se pilote aussi bien en console que par API, y compris via le AWS MCP Server pour les équipes qui travaillent avec un assistant de codage.
L’intérêt opérationnel est immédiat. Au lieu de dupliquer des snapshots, de les partager, puis de les restaurer manuellement, l’équipe de recette reçoit un clone directement exploitable de la base de production. La fraîcheur des données de test s’améliore, et le risque de dériver entre l’environnement de préproduction et la réalité s’amenuise.
Les garde-fous du chiffrement
C’est ici que l’annonce se corse. Tous les volumes ne sont pas partageables à égalité, et la différence tient au mode de chiffrement.
Les volumes non chiffrés et les volumes chiffrés avec une clé gérée par le client (CMK) peuvent être partagés. En revanche, les volumes chiffrés avec la clé gérée par AWS par défaut (AMK) ne le peuvent pas. C’est une conséquence directe de l’architecture de AWS KMS : une clé AMK appartient à un seul compte et ne se délègue pas.
Deux implications pratiques en découlent. D’abord, lorsqu’on copie un volume chiffré avec une CMK, cette CMK doit elle-même être partagée avec le compte cible, sinon la copie échoue au moment du déchiffrement. Ensuite, le compte cible peut spécifier une CMK différente pour réchiffrer la copie à l’arrivée — ce qui est précisément la bonne pratique quand les comptes ont des frontières de sécurité distinctes.
Pour les équipes qui s’apprêtent à utiliser la fonction, le point de départ est un audit du mode de chiffrement des volumes de production. Un volume chiffré en AMK devra d’abord être migré vers une CMK (via un snapshot réchiffré, par exemple) avant de pouvoir alimenter un compte de test. C’est un prérequis qui se planifie, pas une option.
Zone, tarification et observabilité
La copie doit s’effectuer dans la même zone de disponibilité que le volume source. AWS recommande d’utiliser les identifiants de zone (comme use1-az1) plutôt que les noms de zone, car ces derniers ne correspondent pas physiquement aux mêmes emplacements d’un compte à l’autre.
Côté tarification, le partage via AWS RAM est gratuit. Une redevance unique, calculée sur la taille du volume, est facturée au compte où la copie réside, puis le volume copié encourt les frais EBS habituels dès sa création. Le modèle est donc proportionnel à la taille des données, sans surprise récurrente.
Enfin, l’opération est observable. L’événement SharedVolumeCopyInitiated apparaît dans AWS CloudTrail, et Amazon EventBridge émet des événements au début de la copie (état initializing) comme à sa fin (état completed), avec l’identifiant du volume partagé, le compte consommateur et l’horodatage. De quoi brancher une alerte quand un compte inattendu copie un volume sensible.
La comparaison avec les snapshots reste utile
Face à cette nouveauté, la question légitime est de savoir pourquoi ne pas continuer avec les snapshots. La réponse tient à la finalité. Un snapshot est une sauvegarde : incrémental, réplicable entre régions, conservable dans le temps, il est conçu pour restaurer. Un Volume Clone est un instantané de travail : immédiat, mais cantonné à la même zone et, jusqu’ici, à un seul compte — désormais élargi à un compte cible. Pour rafraîchir un environnement de recette, le clone gagne en rapidité et en simplicité ; pour la reprise d’activité inter-régions, le snapshot reste incontournable.
Le nouveau flux a aussi un effet secondaire appréciable côté conformité. En réchiffrant la copie avec une CMK du compte cible, on évite de faire circuler une clé de production vers un environnement moins protégé. Une base de production contenant des données personnelles peut ainsi alimenter un compte de test sous une clé distincte, avec une journalisation CloudTrail qui permet d’auditer précisément qui a copié quoi, et quand.
Le coût se lit en deux lignes. La redevance unique de copie, proportionnelle à la taille, reste marginale face au coût de stockage du volume copié, facturé dès sa création. Le vrai coût, comme souvent, n’est pas celui de l’opération : c’est celui de la dette de configuration — des volumes en AMK non migrés, des partages RAM mal gouvernés, et des alertes EventBridge jamais branchées.
Verdict
La copie entre comptes transforme les Volume Clones en brique d’ingénierie multi-comptes, et non plus en simple gadget de stockage. Elle supprime la friction la plus coûteuse des environnements isolés : le rafraîchissement des données de test.
Si vous opérez une architecture multi-comptes avec un Landing Zone ou des frontières de sécurité strictes, adoptez la fonction pour vos flux de recette et de reprise d’activité. Mais commencez par migrer vos volumes en CMK, auditez qui a le droit de partager des volumes, et branchez EventBridge sur SharedVolumeCopyInitiated.
Si vous devez copier vers une autre région, passez votre chemin : la contrainte de zone de disponibilité commune est ferme, et les snapshots restent l’outil des migrations inter-régions. Enfin, gardez à l’esprit que la copie n’est pas un mécanisme de sauvegarde — c’est un outil d’instanciation d’environnement, à compléter par une vraie politique de snapshots et de rétention.