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 料金計算ツールはレプリケート書き込みのコストを見積もります。

References

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

ReplicatedWriteConflictException

意味

発生する理由

修正方法

関連するエラー

References