ReplicatedWriteConflictException

TL;DR — マルチリージョンの強い整合性（MRSC）を持つグローバルテーブルのアイテムに、別のリージョン のリクエストが同じアイテムを変更している間に書き込みました。強いマルチリージョン整合性は両方の勝ちを着地させられないため、1つの書き込みが拒否されます。AWS はこれをリトライ可能としてドキュメント化しています: バックオフして再試行し、可能な場所でホットアイテムのクロスリージョンの競合を減らしてください。

意味

ReplicatedWriteConflictException: One or more items in this request are
being modified by a request in another Region.

クラシック（結果整合性）のグローバルテーブルは、どこでも並行書き込みを受け入れ、後で last-writer-wins で調整します。MRSC グローバルテーブルは逆のトレードオフをします: 書き込みは確認される前にリージョン間で調整される必要があるため、2つのリージョンが同じ瞬間に同じアイテムを変更するのは本物の競合であり、一方は黙った上書きではなくこの例外を得ます。

発生する理由

同じアイテムが複数のリージョンから並行して書き込まれる — 2つのアプリケーションデプロイが、両方ともそのアイテムを自分が更新するものとして扱う。
ホットな調整アイテム — すべてのリージョンが触れるカウンター、ロック、シングルトンの設定アイテムは、自然な競合の磁石です。
リージョンをまたいだリトライストーム — 異なるリージョンからの同じ論理操作の同時リトライが再衝突し続ける。

修正方法

指数バックオフとジッターで再試行します — 競合は一時的です。他のリージョンの書き込みが完了すると、リトライは進みます。AWS はこのエラーをリトライ可能としています:
```
// let the SDK's adaptive retry handle it, or catch and back off:
catch (e) {
  if (e.name === 'ReplicatedWriteConflictException') return retryWithBackoff(op);
  throw e;
}
```
アイテムにホームリージョンを与えます — 特定のキーの書き込みを1つのリージョン経由（ユーザー居住地、テナント、パーティションによる）でルーティングし、他のリージョンを読み取り主体に保ちます。1つのリージョンだけがアイテムを変更するとき、競合は消えます。
並行更新を可換にします — 別々の属性へのアトミックカウンター更新（ADD / SET x = x + :n）は、アイテム全体の read-modify-write サイクルより競合が少ないです。
競争に負けた後に意図を再確認します — 他のリージョンがアイテムを変更しました。条件付きリトライ（バージョン属性への ConditionExpression）は、あなたの書き込みが新しい状態に対して依然有効であることを保証します。

アイテムがリージョン間で変化するのを見るのは、データが目の前にあるとはるかに簡単です。DynoTable デスクトップアプリは各レプリカリージョンに接続するため、アイテムを並べて比較でき、DynamoDB 料金計算ツールはレプリケート書き込みのコストを見積もります。

DynoTable で調べる

競合が起きたら、同じアイテムをリージョンをまたいで比べましょう — ⌘P で切り替え、⌘K でテーブルを開き、各レプリカリージョンのアイテムを並べて読みます。ステージング（⌘S）を使えば、条件付きのリトライを用意し、コミット前に差分をレビューできます。

ホットなテーブルで MRSC を有効にする前に、レプリケーションされる書き込みのコストを料金計算ツールで見積もりましょう。各リージョンは Settings → Profiles で設定し、Test Connection を実行してください。AWS に接続するとインストールを参照してください。

出典

How DynamoDB global tables work (2026-07-13 時点で検証)
Error handling with DynamoDB (2026-07-13 時点で検証)

参考資料

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

ReplicatedWriteConflictException

意味

発生する理由

修正方法

DynoTable で調べる

出典

関連するエラー

参考資料