ReplicaAlreadyExistsException

TL;DR — 追加しているリージョンは、すでにグローバルテーブルのレプリケーショングループにあります。追加は冪等ではないため、同じリクエストの再実行（リトライ、リプレイされたデプロイ、ドリフトした IaC）は、最初のものが成功すると失敗します。まずテーブルを記述し、そこにないレプリカのみを作成する — またはこの例外を「すでに完了」として扱い、先に進んでください。

意味

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

レプリカ管理は、厳格な前提条件を持つコントロールプレーンの変更です: Create はリージョンが不在であることを、Delete はリージョンが存在することを要求します。eu-west-1 がすでにテーブルをレプリケートしているときに eu-west-1 の作成を求めるのは、その前提条件に違反します。望んだ状態はすでに存在します。

発生する理由

リトライまたはリプレイされたプロビジョニングステップ — 最初の試行が成功し（おそらくタイムアウトが成功を隠した後）、リトライが同じリージョンを再追加する。
Infrastructure-as-code のドリフト — レプリカがコンソールで手動追加され、その後 IaC パイプラインがそれを再び追加しようとする。
2つのオートメーション経路の競合 — 並列デプロイやリージョン拡張ジョブが両方とも同じレプリカ作成を送信する。

修正方法

変更する前にレプリケーショングループを確認します:
```
aws dynamodb describe-table --table-name orders \
  --query 'Table.Replicas[].RegionName'
```
操作を冪等にします — 作成時にこの例外を（削除時に ReplicaNotFoundException を）キャッチして成功として扱います。テーブルはすでに望んだ状態です:
```
catch (e) {
  if (e.name === 'ReplicaAlreadyExistsException') return; // desired state reached
  throw e;
}
```
IaC を現実と調整します — 手動追加されたレプリカをスタックにインポートし、すべてのデプロイが作成を再試行しないようにします。
レプリカの変更を直列化します — テーブルごとに一度に1つのレプリカ更新。次の変更の前に、テーブルが ACTIVE に戻る（そして新しいレプリカが CREATING を離れる）のを待ちます。

レプリカが実際にデータを提供すること — API が受け入れただけでなく — を確認するのは、テーブルを見る作業です: DynoTable デスクトップアプリは各リージョンのレプリカを直接閲覧し、DynamoDB 料金計算ツールは追加のリージョンが加える継続的なコストを表示します。

DynoTable でチェック

レプリカの作成が成功したら、API が受け付けただけでなく、実際にデータを返すことを確認しましょう。⌘P でレプリカのリージョンに切り替え、⌘K でテーブルを開き、アイテムを閲覧します。DynoTable は各リージョンのコピーを並べて表示するので、静かに部分失敗していればすぐに分かります。

リージョンをもう 1 つ追加する前に、レプリケーションされる書き込みの継続的なコストを料金計算ツールで見積もりましょう。Settings → Profiles でリージョンごとにプロファイルを設定し、それぞれで Test Connection を実行してください。AWS に接続するとインストールを参照してください。IaC の再実行が目的の状態に到達しているなら、ReplicaAlreadyExistsException は成功として扱ってかまいません — そのリージョンはすでにレプリケーションしています。

出典

UpdateGlobalTable — Amazon DynamoDB API Reference (2026-07-13 時点で検証)
Global tables — Amazon DynamoDB Developer Guide (2026-07-13 時点で検証)

参考資料

最終検証日 2026-07-13、上記にリンクした公式 AWS ドキュメントに照らして確認しました。

ReplicaAlreadyExistsException

意味

発生する理由

修正方法

DynoTable でチェック

出典

関連するエラー

参考資料