Services Projets Tarifs Blogue À propos Appel gratuit →
Blogue

Secrets Manager : répliquer un secret entre comptes AWS

AWS permet depuis le 13 novembre 2026 de répliquer un secret vers un autre compte. Ce qui change, les limites et comment l’essayer prudemment.

5 min de lectureInfonuagiqueSécurité

Le 13 novembre 2026, AWS a annoncé la réplication entre comptes pour AWS Secrets Manager. Concrètement, un secret « principal » dans un compte peut maintenant avoir une copie synchronisée dans un autre compte. Si votre SaaS répartit ses charges de travail sur plusieurs comptes AWS (par exemple production et reprise après sinistre), cela évite de recopier des valeurs à la main ou de partager des clés de chiffrement entre comptes. Ce n’est toutefois pas pour tout le monde : une seule réplique par secret, et seulement dans la même région.

Qu’est-ce qui a été annoncé, et qu’est-ce qui est nouveau?

Selon l’annonce, la fonction maintient une copie synchronisée d’un secret principal dans un compte secondaire. Elle prolonge la réplication multirégion déjà offerte, mais au-delà de la frontière du compte. AWS cite trois usages : l’accès entre comptes, la sauvegarde et la reprise après sinistre.

La documentation d’AWS précise le modèle :

  • La réplique est un secret indépendant, avec ses propres politiques d’accès, sa propre clé KMS et son propre cycle de vie.
  • Quand la valeur du secret principal change, Secrets Manager propage la nouvelle valeur. L’annonce précise que cela inclut les rotations.
  • Le propriétaire du compte de la réplique la crée et la configure. Le propriétaire du compte principal l’associe ensuite au secret principal, ce qui déclenche la réplication.

Quelles sont les contraintes?

La documentation en liste trois, en date de novembre 2026 :

  • Même région. Le secret principal et la réplique doivent être dans la même région AWS.
  • Une réplique par secret principal. Une demande d’association d’une seconde réplique échoue.
  • Clé gérée par le client obligatoire. La réplique doit être chiffrée avec une clé KMS gérée par le client, pas avec la clé gérée par AWS aws/secretsmanager.

La réplication est asynchrone et cohérente à terme : la réplique peut ne pas refléter tout de suite la dernière valeur. On suit l’avancement avec DescribeSecret, qui indique un état : Pending, InProgress, InSync, Failed ou Detached.

Qu’est-ce qui est répliqué, et qu’est-ce qui ne l’est pas?

Sont répliqués : la valeur du secret et ses versions, la description, le type, ainsi que la correspondance entre versions et étiquettes intermédiaires (staging labels). Ne sont pas répliqués : les étiquettes (tags), la politique de ressource et la clé KMS. Chaque compte gère les siens.

C’est un point de conception important. La réplique ne reprend pas la politique d’accès du principal : ce sont les politiques IAM et la politique de ressource propres au compte de destination qui décident qui peut la lire, et leur revue vous revient. Pensez aussi à vos étiquettes de coûts et de propriété : elles ne suivront pas.

Quand est-ce utile, et quand peut-on l’ignorer?

C’est utile si :

  • Une équipe plateforme ou sécurité gère et effectue la rotation d’un secret au même endroit, et que d’autres comptes ont besoin d’une copie locale à jour. AWS indique que cela se fait sans clés KMS partagées ni politiques de secret entre comptes.
  • Vous voulez une copie dans un compte de reprise distinct. AWS décrit ce scénario comme une façon d’isoler la copie d’un compte principal compromis, et la réplique peut être promue en secret autonome au besoin.
  • Dans notre lecture, vous gérez des valeurs partagées entre comptes et elles dérivent à force de copies manuelles.

Vous pouvez l’ignorer si :

  • Vous n’avez qu’un seul compte AWS.
  • Vos comptes consommateurs peuvent simplement lire le secret principal par une politique entre comptes, et cela vous convient.
  • Vous avez besoin de plusieurs répliques d’un même secret : la limite est d’une.

Combien ça coûte?

L’annonce ne donne pas de prix pour les répliques et renvoie à la page de tarification. Cette page indique, en novembre 2026, 0,40 $ par secret par mois et 0,05 $ par tranche de 10 000 appels d’API (la page n’associe pas le symbole $ à une devise). Le tarif d’une réplique n’y figure pas en novembre 2026. Vérifiez-le avant de répliquer des centaines de secrets, car chaque réplique est un secret distinct dans son compte.

Comment l’essayer prudemment cette semaine?

  1. Choisissez un secret sans conséquence (un jeton de test, par exemple) et deux comptes de non-production dans la même région. La référence d’API indique aussi, par défaut, que le compte de la réplique doit appartenir à la même organisation AWS.
  2. Créez une clé KMS gérée par le client dans le compte de la réplique, puis la réplique elle-même.
  3. Associez-la depuis le compte principal, en vous référant à la documentation et à l’opération AssociateCrossAccountReplica décrite dans la référence d’API.
  4. Surveillez l’état jusqu’à InSync, puis changez la valeur du principal et mesurez le délai avant qu’elle apparaisse dans la réplique.
  5. Faites une rotation pour vérifier que la nouvelle valeur arrive, et testez la fin de la réplication (état Detached) pour savoir ce qui se passe côté consommateur.

Que vérifierions-nous d’abord avant de l’adopter?

Nous commencerions par des questions de gouvernance plutôt que par l’outil :

  • Qui possède la valeur? Une seule équipe doit pouvoir la modifier, sinon la synchronisation ne règle rien.
  • Les applications tolèrent-elles un délai? La réplication est asynchrone : un consommateur qui lit juste après une rotation peut voir l’ancienne valeur.
  • Qui lit la réplique? La politique de ressource et les rôles du compte de destination doivent être revus à part.
  • La journalisation couvre-t-elle les deux comptes? Les accès à la réplique doivent être traçables.
  • Que dit votre cadre de conformité? Si des renseignements personnels ou des exigences de la Loi 25 ou de SOC 2 entrent en jeu, validez la conception avec la personne responsable chez vous.

Si vous voulez un regard d’ingénierie sur la gestion des secrets de votre infonuagique, consultez nos services.

Cet article offre de l’information générale fondée sur l’annonce et la documentation publiques d’AWS en novembre 2026. Il ne constitue pas un conseil de sécurité ni de conformité : validez votre conception avec un professionnel.