ReplicaAlreadyExistsException

TL;DR — La Région que tu ajoutes fait déjà partie du groupe de réplication de la table globale. L'ajout n'est pas idempotent, donc une réexécution de la même requête (reprise, déploiement rejoué, IaC dérivée) échoue une fois que la première a réussi. Décris d'abord la table et ne crée que les réplicas qui n'y sont pas — ou traite cette exception comme « déjà fait » et passe à la suite.

Ce que ça signifie

ReplicaAlreadyExistsException: The specified replica is already part of
the global table.

La gestion des réplicas est un changement de plan de contrôle avec une précondition stricte : Create exige que la Région soit absente, Delete exige qu'elle soit présente. Demander la création de eu-west-1 alors que eu-west-1 réplique déjà la table viole cette précondition — l'état que tu voulais existe déjà.

Pourquoi ça arrive

Une étape de provisionnement réessayée ou rejouée — la première tentative a réussi (peut-être après qu'un timeout a masqué le succès), et la reprise réajoute la même Région.
Dérive de l'infrastructure-as-code — le réplica a été ajouté manuellement dans la console, puis le pipeline IaC essaie de l'ajouter à nouveau.
Deux chemins d'automatisation en concurrence — des déploiements parallèles ou des jobs d'expansion de région soumettant tous les deux la même création de réplica.

Comment le corriger

Vérifie le groupe de réplication avant de le muter :

aws dynamodb describe-table --table-name orders \
  --query 'Table.Replicas[].RegionName'

Rends l'opération idempotente — attrape cette exception à la création (et ReplicaNotFoundException à la suppression) et traite-la comme un succès ; la table est déjà dans l'état voulu :
```
catch (e) {
  if (e.name === 'ReplicaAlreadyExistsException') return; // desired state reached
  throw e;
}
```
Réconcilie l'IaC avec la réalité — importe le réplica ajouté manuellement dans ta stack plutôt que de laisser chaque déploiement retenter la création.
Sérialise les changements de réplica — une mise à jour de réplica à la fois par table ; attends que la table revienne à ACTIVE (et que le nouveau réplica quitte CREATING) avant le changement suivant.

Confirmer qu'un réplica sert réellement des données — et pas seulement que l'API a accepté — est un travail à regarder directement : l'application desktop DynoTable parcourt le réplica de chaque Région directement, et le calculateur de tarifs DynamoDB montre le coût récurrent que la Région supplémentaire ajoute.

Erreurs liées

ReplicaNotFoundException — l'image miroir : supprimer une Région qui n'est pas dans le groupe.
GlobalTableNotFoundException — confusion API legacy vs current.
ResourceInUseException — la table est en cours de modification.
En savoir plus : DynamoDB global tables

Références

Dernière vérification le 2026-07-13 par rapport à la documentation officielle AWS liée ci-dessus.