公開2025.02.04更新2026.10.21 AWS

DynamoDB Global Tables（グローバルテーブル）とは：MRSC・マルチアカウントと料金・作成手順【2026年10月】

Q: AWS::DynamoDB::GlobalTableとAWS::DynamoDB::Tableはどう使い分けますか？

将来リージョンを増やす可能性があるテーブルは、最初から AWS::DynamoDB::GlobalTable で1リージョンだけ定義しておきます。この段階の料金は単一リージョンのテーブルと同じで、後からReplicasを足すと安全にグローバルテーブルへ変わります。 AWS::DynamoDB::Table はリージョンを増やす予定が無いテーブルに使い、後から型の書き換えでGlobalTableへ移すことはしません。

DynamoDB Global Tables（グローバルテーブル）とは：MRSC・マルチアカウントと料金・作成手順【2026年10月】

Amazon DynamoDB Global Tables（グローバルテーブル）は、1つのテーブルを複数のAWSリージョンへ自動で複製し、どのリージョンのレプリカでも読み書きできるようにする機能です。2025年6月に強整合のモード（MRSC）が一般提供され、2026年2月には複数のAWSアカウントをまたぐ複製にも対応しました。この記事では2026年10月時点の公式ドキュメントをもとに、2つの整合性モードの選び方、東京・大阪の実単価での料金、CLI・CloudFormation・Terraformでの作成手順と、作る前に知っておくべき制約を整理します。

まとめ：Global Tablesの要点（2026年10月時点）

どのレプリカにも書き込めるマルチアクティブ構成。SLAは単一リージョンの99.99%に対し99.999%。
整合性モードは作成時に選び、後から変えられない。既定はMREC（結果整合）で、複製は通常1秒以内、競合はLast Writer Winsで解決される。
MRSC（強整合）はRPO=0。ちょうど3リージョン（3レプリカか、2レプリカ＋ウィットネス）で、空のテーブルからしか作れず、TTL・LSI・トランザクションは使えない。
2026年2月からマルチアカウント構成が可能。ただしMRECのみで、レプリカ1つにつきアカウントが1つ要る。
料金はレプリカのあるリージョンごとに複製書き込み（rWRU／rWCU）が発生し、単価は通常の書き込みと同じ。リージョン間の複製にデータ転送料金はかからない。
新規は版2019.11.21で作る。2017.11.29は公式が新規利用を避けるよう案内するレガシーで、Terraformのaws_dynamodb_global_tableはこの旧版専用。

Global Tablesの仕組み：レプリカの動きと2つの版

レプリカ・マルチアクティブ書き込み・99.999%のSLA

グローバルテーブルは、異なるリージョンにある2つ以上のレプリカテーブルで構成されます。1リージョンに置けるレプリカは1つだけで、全レプリカがテーブル名・主キーのスキーマ・項目データを共有します。どのレプリカに書いても残りへ自動で反映され、読み書きは通常のDynamoDB APIのままです（AWS公式：グローバルテーブル）。

公式のCore conceptsは、グローバルテーブルのSLAを99.999%、単一リージョンのテーブルを99.99%としています。単一リージョンのDynamoDB自体の機能やキー設計はAmazon DynamoDBとは：機能の全体像からローカル起動・キー設計・容量モード選定までで扱っています。

現行版2019.11.21とレガシー版2017.11.29の見分け方

版は2つあり、AWSは可能な限り2019.11.21（Current）を使うよう案内しています。手元のテーブルがどちらかは、describe-tableの出力に"GlobalTableVersion": "2019.11.21"があるかで判定できます。旧版は専用API群で管理されるため、describe-global-tableが成功すれば2017.11.29、GlobalTableNotFoundExceptionなら旧版ではありません。

差は書き込みの消費量にも出ます。公式の版比較による、1KBの項目を2リージョンで扱う場合の消費量は次のとおりです。

操作（1KB・2リージョン）	2017.11.29	2019.11.21	削減
PutItem	4 rWRU	2 rWRU	50%
UpdateItem	3 rWRU	2 rWRU	33%
DeleteItem	3 rWRU	2 rWRU	33%

旧版は11リージョンでしか使えず、TTL設定・Auto Scaling・GSI設定もレプリカ間で同期しません。監視指標のPendingReplicationCountは旧版だけが出す指標なので、古い解説記事どおりに組んだアラームは現行版では発火しないままです。旧版のテーブルが残っていれば、コンソールのGlobal Tablesタブにある「Update version」から現行版へ更新します（テーブルの大きさとレプリカ数によって数分から数時間かかります）。全レプリカのリージョンでdynamodb:UpdateGlobalTableVersionの権限が要り、更新中はAuto Scalingが容量を調整しないため、公式は更新の間オンデマンドに切り替えておくことを強く推奨しています。

整合性モードの選び方：MREC（結果整合）とMRSC（強整合）

グローバルテーブルの設計で最初に決めるのが整合性モードです。作成時に指定しなければMRECになり、作成後にモードを変更する手段はありません。主な違いをHow DynamoDB global tables workから抜き出すと次のとおりです。

項目	MREC（結果整合）	MRSC（強整合）
複製	非同期（通常1秒以内）	1つ以上の他リージョンへ同期
RPO	複製遅延ぶん（数秒程度）	0
リージョン数	2以上（パーティション内の全リージョンまで）	ちょうど3
データ入りテーブルからの作成	可	不可（空のテーブルのみ）
レプリカの追加・削除	随時	追加不可・1つだけの削除も不可
TTL・LSI・トランザクション	使える	使えない
ReplicationLatency指標	出る	出ない
マルチアカウント	対応	非対応

整合性の考え方そのもの（結果整合と強整合の違い、レプリカ遅延を前提にした設計）は結果整合性とは？強整合性との違いとレプリカ遅延の設計を実装者目線で解説【2026年版】で詳しく扱っています。

MRECの競合解決（Last Writer Wins）と強整合読み込みの落とし穴

MRECで同じ項目が複数リージョンからほぼ同時に更新されると、DynamoDBは項目ごとの内部タイムスタンプが最も新しい書き込みを採用します（last writer wins）。負けた側の更新はエラーにならず上書きされます。

見落としやすいのはConsistentRead=trueの意味です。MRECの強整合読み込みが最新を返すのは、その項目を最後に更新したのが読んだリージョン自身だった場合だけで、別リージョンで更新された項目は古い値を返すことがあります。条件付き書き込みの条件式も、そのリージョンにある版に対して評価されます。在庫の引き当てのように「条件付き書き込みで二重更新を防ぐ」設計は、書き込み先のリージョンを1つに寄せない限りMRECでは成り立ちません。

MRSCの3リージョン構成・ウィットネス・ReplicatedWriteConflictException

MRSCでは、書き込みは少なくとも1つの他リージョンへ同期で複製されてから成功を返します。どのレプリカで強整合読み込みをしても最新の版が返り、条件付き書き込みも常に最新の版に対して評価されます。ただしGSIからの読み込みは、MRSCでも単一リージョンと同じく結果整合です。

構成はちょうど3リージョンで、3レプリカか、2レプリカ＋1ウィットネスを選びます。ウィットネスはデータを保持するもののDynamoDBが管理する部品で、読み書きはできず、自分のアカウントにも表示されません。対応リージョンは一般提供時（2025年6月30日）の10から、2026年9月にカナダ（中部）・ストックホルム・スペイン・ムンバイ・シンガポールが加わって15になり、大陸をまたぐ組み合わせも選べるようになりました（AWS What’s New）。日本向けなら東京と大阪をレプリカにし、ソウルをウィットネスにする構成が組めます。ウィットネスも複製データを保持するため、データの国内保管が要件ならソウルに置けるかを先に確認します。

他リージョンで変更中の項目を書き換えようとするとReplicatedWriteConflictException（HTTP 400）が返ります。この例外は再試行すれば、相手側の変更が終わった時点で成功します。既定で再試行されるかはSDKと再試行モードによって異なるため、この例外を再試行対象に含めて動作を確かめておきます。

MRSCを選ぶ条件と選ばない条件

MRSCが向くのは、決済・残高・在庫のように「別リージョンで古い値を読むと業務が壊れる」データで、しかもRPO=0を求められる場合です。リレーショナルのSQLとトランザクションが必要なら、同じくマルチリージョンで強整合をうたうAurora DSQLも比較対象に入ります。

次のどれかに当たるなら、MRSCは選びません。

既存のテーブルにデータが入っている（MRSCは空のテーブルからしか作れない）
TransactWriteItems／TransactGetItemsを使っている（MRSCのレプリカではエラーになる）
TTLで期限切れデータを消している、またはLSIを使っている
4リージョン以上に置きたい、あるいは後からリージョンを増やす予定がある
書き込みのレイテンシーを最小に抑えたい（MRSCは書き込みのたびにリージョン間の通信が入る）

どれにも当たらず、データの正しさをレイテンシーより優先するときだけMRSCを選びます。モードは作り直さない限り変えられないため、迷ったら「RPOを0にする必要が本当にあるか」を先に確定させます。

同一アカウント構成とマルチアカウント構成（2026年2月対応）の違い

2026年2月3日、AWSはマルチアカウントのグローバルテーブルを発表しました。各レプリカを別々のAWSアカウントに置き、リージョン単位に加えてアカウント単位でも障害やセキュリティ事故の影響を切り離せます。IAM・KMS・請求・CloudTrailがアカウントごとに分かれるため、事業部ごとにアカウントを分けている組織に向きます。

制約は同一アカウント構成より強めです。公式の説明によると、次の点が異なります。

MRECのみ対応（MRSCは同一アカウント構成だけ）
レプリカN個にはアカウントがN個要る（1アカウントに1レプリカ）
単一リージョンのテーブルから始める必要があり、既存の同一アカウント構成のグローバルテーブルを移すには、レプリカを削除していったん単一リージョンに戻す
各レプリカでGlobalTableSettingsReplicationMode = ENABLEDを設定し、リソースポリシーでグローバルテーブルのサービスプリンシパルに複製の権限を渡す
容量モード・TTL・GSI定義などはレプリカごとの上書きができない（例外は読み込みのAuto Scalingポリシー）
逆にテーブルクラス・暗号化の種類とKMSキー・PITR・削除保護・タグは同期されず、各アカウントで個別に設定する

マルチアカウント構成では、リソースポリシーの権限削除やKMSキーの拒否など利用者側の原因でReplicationLatencyが3時間を超えると通知が届き、20時間後に2回目の通知が来ます。それでも直さなければ、そのレプリカはグローバルテーブルから外されます。権限の棚卸しを自動化している組織は、このポリシーを除外対象にしておきます。

Global Tablesの作成手順：AWS CLIでMREC・MRSCを構成

現行版では、既存の単一リージョンのテーブルにレプリカを足す形でグローバルテーブルにします。コンソールならテーブル詳細の「グローバルテーブル」タブから「レプリカを作成」を選び、リージョンを指定します。以下は公式チュートリアルの手順を東京・大阪・ソウルに置き換えたものです。

MREC：既存テーブルにレプリカを追加する（update-table）

公式の作成例は、DynamoDB StreamsをNEW_AND_OLD_IMAGESで有効にしたテーブルにレプリカを足しています。MRECはStreamsを読んで複製するため、レプリカではStreamsが既定で有効になり、無効にはできません。

# 東京に元テーブルを作る（Streams有効）
aws dynamodb create-table \
    --table-name Orders \
    --attribute-definitions AttributeName=pk,AttributeType=S \
    --key-schema AttributeName=pk,KeyType=HASH \
    --billing-mode PAY_PER_REQUEST \
    --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES \
    --region ap-northeast-1

aws dynamodb wait table-exists --table-name Orders --region ap-northeast-1

# 大阪にレプリカを追加する（データ入りのテーブルでも可）
aws dynamodb update-table \
    --table-name Orders \
    --replica-updates '[{"Create":{"RegionName":"ap-northeast-3"}}]' \
    --region ap-northeast-1

# 版とレプリカの状態を確認する
aws dynamodb describe-table --table-name Orders --region ap-northeast-1 \
    --query 'Table.{Version:GlobalTableVersion,Replicas:Replicas[*].{Region:RegionName,Status:ReplicaStatus}}'

レプリカの状態がACTIVEになれば完了です（空のテーブルなら数分、大きなテーブルは数時間）。追加は既存テーブルの性能に影響しませんが、レプリカ追加に使った元のテーブルは、新しいレプリカの作成から24時間削除できません。

MRSC：ウィットネス付きで作成する（–multi-region-consistency STRONG）

MRSCは空のテーブルに、レプリカ1つとウィットネス1つ（またはレプリカ2つ）を一度に足して作ります。変換が終わるまでテーブルに書き込んではいけません。

# 東京に空のテーブルを作る（MRSCでは Streams は不要）
aws dynamodb create-table \
    --table-name Ledger \
    --attribute-definitions AttributeName=pk,AttributeType=S \
    --key-schema AttributeName=pk,KeyType=HASH \
    --billing-mode PAY_PER_REQUEST \
    --region ap-northeast-1
aws dynamodb wait table-exists --table-name Ledger --region ap-northeast-1

# 大阪をレプリカ、ソウルをウィットネスにして強整合で構成する
aws dynamodb update-table \
    --table-name Ledger \
    --replica-updates '[{"Create":{"RegionName":"ap-northeast-3"}}]' \
    --global-table-witness-updates '[{"Create":{"RegionName":"ap-northeast-2"}}]' \
    --multi-region-consistency STRONG \
    --region ap-northeast-1

ウィットネスを作るにはIAMでdynamodb:CreateGlobalTableWitnessの許可も要ります。作成後にdescribe-tableでMultiRegionConsistencyがSTRONGになっているか、GlobalTableWitnessesにソウルが出ているかを確かめます。

IaCで定義する：CloudFormationとTerraformの書き方

CloudFormation：AWS::DynamoDB::GlobalTableと「type変更で削除」の罠

CloudFormationではAWS::DynamoDB::GlobalTableを使います。このリソースは2019.11.21専用で、旧版は扱えません。最も危ないのは既存のAWS::DynamoDB::Tableのtypeを書き換えてGlobalTableにする操作で、リソースのリファレンスは「テーブルが削除される可能性がある」と明記しています。既存テーブルを移すときは、ベストプラクティスにある次の順で進めます。

既存のAWS::DynamoDB::TableのDeletionPolicyをRetainにする
スタック定義からそのテーブルを外す
コンソールでレプリカを追加してグローバルテーブルにする
できたテーブルをAWS::DynamoDB::GlobalTableとしてスタックへインポートする

新規なら、最初からGlobalTableで1リージョンだけ定義し、後からReplicasを足すのが安全です（それまでの料金は単一リージョンと同じ）。Replicasにはスタックのリージョン自身を必ず含め、1回の更新で追加・削除できるレプリカはMRECでは1つまでです（MRSCは3レプリカか2レプリカ＋ウィットネスをまとめて指定）。レプリカが2つ以上あるMRECではStreamSpecificationの指定が必須です。各リージョンのスタックにレプリカを分けて書くとドリフトでエラーになるため、全レプリカを1つのリージョンのスタックにまとめます。

# MREC：東京＋大阪（東京リージョンのスタックで全レプリカを定義）
Resources:
  OrdersTable:
    Type: AWS::DynamoDB::GlobalTable
    Properties:
      TableName: Orders
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: pk
          AttributeType: S
      KeySchema:
        - AttributeName: pk
          KeyType: HASH
      StreamSpecification:
        StreamViewType: NEW_AND_OLD_IMAGES
      Replicas:
        - Region: ap-northeast-1
          DeletionProtectionEnabled: true
        - Region: ap-northeast-3
          DeletionProtectionEnabled: true

# MRSC：東京・大阪がレプリカ、ソウルがウィットネス
  LedgerTable:
    Type: AWS::DynamoDB::GlobalTable
    Properties:
      TableName: Ledger
      BillingMode: PAY_PER_REQUEST
      MultiRegionConsistency: STRONG
      AttributeDefinitions:
        - AttributeName: pk
          AttributeType: S
      KeySchema:
        - AttributeName: pk
          KeyType: HASH
      Replicas:
        - Region: ap-northeast-1
          DeletionProtectionEnabled: true
        - Region: ap-northeast-3
          DeletionProtectionEnabled: true
      GlobalTableWitnesses:
        - Region: ap-northeast-2

2つの定義はcfn-lint 1.46.0のスキーマ検証でエラーが出ないことを確認済みです（権限やクォータはスキーマ検証では分からないため、検証用アカウントで一度作成してから本番に流します）。削除保護はレプリカ間で同期されないので、レプリカごとにDeletionProtectionEnabledを書きます。

Terraform：aws_dynamodb_tableのreplicaブロックとprovider版の要件

Terraformではaws_dynamodb_tableにreplicaブロックを足します。よく検索されるaws_dynamodb_global_tableは2017.11.29（V1）専用のリソースなので、新規構築では使いません。MRSCの指定に使う引数はAWS providerの比較的新しい版で入ったものです。provider のCHANGELOGでは、replica.consistency_modeが6.3.0（2025年7月10日）、global_table_witnessが6.22.0（2025年11月20日）で追加されています。

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 6.22.0"
    }
  }
}

resource "aws_dynamodb_table" "ledger" {
  name             = "Ledger"
  billing_mode     = "PAY_PER_REQUEST"
  hash_key         = "pk"
  stream_enabled   = true
  stream_view_type = "NEW_AND_OLD_IMAGES"

  attribute {
    name = "pk"
    type = "S"
  }

  # provider の region（東京）＋大阪のレプリカ＋ソウルのウィットネス
  replica {
    region_name      = "ap-northeast-3"
    consistency_mode = "STRONG"
  }

  global_table_witness {
    region_name = "ap-northeast-2"
  }
}

MRECにするならconsistency_modeを省き（既定はEVENTUAL）、global_table_witnessを外してreplicaブロックを必要なリージョンぶん並べます。global_table_witnessはconsistency_mode = "STRONG"のレプリカ1つと組み合わせたときだけ有効で、それ以外の組み合わせは作成に失敗します。replicaブロックと別リソースのaws_dynamodb_table_replicaは併用できない点にも注意します。

料金の計算：東京・大阪の実単価で見るGlobal Tablesの費用

課金の基本は公式の課金ガイドのとおりです。テーブルにレプリカを足すと、書き込みの単位がWRU／WCUからrWRU（オンデマンド）／rWCU（プロビジョンド）に変わり、レプリカのある全リージョンでそれぞれ課金されます。2024年11月1日からの値下げで、rWRU・rWCUの単価は単一リージョンの書き込みと同額になりました（オンデマンドで67%、プロビジョンドで33%の引き下げ）。リージョン間の複製にデータ転送料金はかかりません。読み込みとストレージは各リージョンで単一リージョンと同じように課金されます。

このほか、GSIの更新はレプリカのある全リージョンでWRU／WCUとして課金され、レプリカの追加時には追加先でテーブル復元の料金が一度かかります。MRSCのウィットネスには複製書き込み・ストレージ・転送の料金がかからないため、3レプリカより2レプリカ＋ウィットネスのほうが安くなります。

AWS価格表API（2026年9月11日公開分）の東京・大阪の単価は次のとおりです。プロビジョンドの場合、東京のrWCUは通常のWCUと同じ1時間0.000742ドルです。

項目	東京	大阪
書き込み（WRU）・複製書き込み（rWRU）	0.715ドル／100万	0.715ドル／100万
ストレージ（Standard）	0.285ドル／GB月	0.285ドル／GB月
レプリカ追加時の復元	0.171ドル／GB	0.171ドル／GB

月3,000万回の書き込み（1件1KB以下・オンデマンド）、データ100GBのテーブルで試算します（リージョンごとに月25GBのストレージなどの無料枠は差し引いていません）。東京だけなら書き込み21.45ドル＋ストレージ28.50ドルで月49.95ドルです。大阪にレプリカを足すと、東京・大阪の両方で3,000万rWRUずつ課金されて書き込みは42.90ドル、ストレージも2倍の57.00ドルとなり、月99.90ドルになります。加えて追加時に一度だけ100GB×0.171ドル＝17.10ドルの復元料金がかかります。2リージョン構成はほぼ2倍で、データ転送の上乗せはありません。東京・大阪＋ソウルのウィットネスによるMRSCも、ウィットネス分は無料なので同じ99.90ドルの見込みです。

費用を下げる手は、アクセスの少ないリージョンのレプリカを置かないこと、書き込み量の多い属性を別テーブルに分けて複製対象から外すこと、MRECならTTLで不要な項目を消すことです（TTLの削除は削除が起きたリージョンでは無料ですが、他リージョンへの複製分は課金されます。TTLの基本はDynamoDB TTLの設定方法と自動削除の仕組み）。単一リージョンを含めたDynamoDB全体の料金の組み立てはDynamoDBの料金を東京リージョンの実額で試算する：請求が跳ねる設計と単価の下げ方で計算しています。

運用で効く設定：同期されない設定・ReplicationLatency・FIS

レプリカ間で同期される設定と同期されない設定

同一アカウント構成では、容量モード、書き込み容量とそのAuto Scaling、キー・GSIの定義、暗号化の種類、MRECのStreams定義、TTL、ウォームスループットが全レプリカで自動的にそろいます。読み込み容量やテーブルクラスは同期されますが、レプリカごとに上書きできます。

逆に、削除保護・ポイントインタイムリカバリ（PITR）・タグ・リソースポリシー・Kinesis Data Streams連携・Contributor Insightsは同期されません。「1つのレプリカで削除保護を有効にしたから全体が守られている」と考えるのは誤りで、レプリカごとに設定が要ります。PITRは1つのレプリカで有効にするだけでもDR要件を満たせる場合がある、と公式は書いています。どこまで取るかはDR対策とは？構成4パターンのRPO・RTO目安とDR計画の作り方で整理したRPO・RTOの目標から決めます。

ReplicationLatencyの監視とFISによる複製停止テスト

MRECでは、CloudWatchのReplicationLatency（ミリ秒）が送信元と受信先のリージョンの組ごとに出ます。値はリージョン間の距離で変わるため、閾値は平常時の値を記録してから決めます。上がり続けるなら複製が追いついておらず、公式は一時的に読み書きを別リージョンへ寄せる対応を挙げています（MRSCはこの指標を出しません）。

切り替え手順が本当に動くかは、AWS Fault Injection Service（FIS）のaws:dynamodb:global-table-pause-replicationで確かめられます。選んだレプリカとの間の複製（送受信の両方向）を止めてリージョンの孤立を再現するアクションで、2026年1月からMRSCにも対応しました。ただしFISのアクションリファレンスによると、開始後も最大5分は複製が続くことがあるため、実験時間は5分より十分長く取ります。MRSCの実験中は結果整合の読み込みはできますが、課金モードや容量の変更はできません。実験中はFISがテーブルのリソースポリシーに拒否の文を一時的に差し込み、MRSCではdynamodb:InjectErrorの権限が要るほか、1テーブルあたり直近7日間で合計5,040分までという上限があります。リソースポリシーを自動で上書きする仕組みがあると実験とぶつかるので、実験中は止めておきます。

リージョン切り替えまで含めた設計や、AWSでのDR構成の構築・運用は、AWSを中心としたインフラ構築の支援でも相談を受けています。

導入前に確認する制約と落とし穴

設計段階で引っかかりやすい制約を、影響の大きい順に並べます。

MRECのトランザクションはリージョン内でだけ原子的。TransactWriteItemsの書き込みは1単位として複製されないため、別リージョンでは途中までしか反映されていない状態が見えることがある。
DAXのキャッシュが古くなる。他リージョンからの複製書き込みはDAXを通らないので、DAXのキャッシュはTTLが切れるまで更新されない。
リージョンを無効化すると20時間後に分離。そのリージョンのレプリカは単一リージョンのテーブルに恒久的に変わる。
プロビジョンドでは複製分も書き込み容量を食う。アプリの書き込みと複製・TTL削除の合計が容量を超えるとスロットリングになる。新しいレプリカには元リージョンの容量設定（Auto Scalingの上限を含む）が引き継がれ、追加先のクォータを超えると作成が失敗する。
Streamsを読むアプリは複製分も受け取る。自リージョンの変更だけを処理したいなら、項目に書き込み元リージョンの属性を入れ、Lambdaのイベントフィルタで絞る。変更データの扱い方はチェンジフィードとは？Cosmos DB・DynamoDBでの変更フィード実装と採用判断も参考になる。

どれも「どのリージョンにでも書ける」性質の裏返しです。書き込みを受けるリージョンを先に決めておくと、競合や重複処理の大半を防げます。

よくある質問

DynamoDB Global Tablesとは何ですか？

DynamoDBのテーブルを複数のAWSリージョンへ自動で複製し、どのリージョンのレプリカでも読み書きできるようにするフルマネージドの機能です。リージョン障害時に別リージョンへ切り替えて業務を続けるDR対策や、利用者に近いリージョンで読み書きして応答を速くする目的で使います。SLAは99.999%で、単一リージョンのテーブル（99.99%）より高く設定されています。

DynamoDBでリージョン間の強い整合性（MRSC）は使えますか？

使えます。2025年6月30日に一般提供されたMRSC（マルチリージョン強整合性）を作成時に選ぶと、書き込みが他リージョンへ同期で複製され、どのレプリカの強整合読み込みも最新の値を返します。条件はちょうど3リージョン（3レプリカか2レプリカ＋ウィットネス）で、空のテーブルから作ることです。使えない機能は本文の比較表のとおりです。

Global Tablesにすると料金は何倍になりますか？

書き込みとストレージの費用はレプリカの数だけかかるため、レプリカ2つならおおむね2倍、3つならおおむね3倍です。読み込みは読んだリージョンでだけ課金されるので倍にはならず、MRSCを2レプリカ＋ウィットネスで組む場合は3リージョンでも約2倍です。複製書き込みの単価は通常の書き込みと同じで、リージョン間の複製にデータ転送料金はかかりません。レプリカ追加時には追加先でテーブル復元の料金が一度かかり、MRSCのウィットネスには料金がかかりません。

既存のDynamoDBテーブルをグローバルテーブルに変換できますか？

MRECなら、データが入ったままの既存テーブルにレプリカを追加するだけで変換できます。MRSCはデータの入ったテーブルからは変換できず、空のテーブルで作り直す必要があります。CloudFormationで管理しているテーブルは、typeの書き換えで削除される恐れがあるため、本文のIaCの章の手順（Retainで外す→コンソールで変換→インポート）で移します。

AWS::DynamoDB::GlobalTableとAWS::DynamoDB::Tableはどう使い分けますか？

将来リージョンを増やす可能性があるテーブルは、最初からAWS::DynamoDB::GlobalTableで1リージョンだけ定義しておきます。この段階の料金は単一リージョンのテーブルと同じで、後からReplicasを足すと安全にグローバルテーブルへ変わります。AWS::DynamoDB::Tableはリージョンを増やす予定が無いテーブルに使い、後から型の書き換えでGlobalTableへ移すことはしません。