[アップデート] マルチリージョン強整合性のAmazon DynamoDBグローバルテーブルがAWS FISに対応したのでやってみた
マルチリージョン強整合性のAmazon DynamoDBグローバルテーブルがAWS FISに対応した
おのやんです。
この度のアップデートにより、マルチリージョンの強力な整合性が設定されたAmazon DynamoDB(以下、DynamoDB)グローバルテーブルを、AWS Fault Injection Service(以下、FIS)のターゲットとして設定できるようになりました。実際にFISを通して、リージョン間のレプリケーション障害を再現できます。
ということで今回は、実際にDynamoDBグローバルテーブルのレプリケーション障害をFIS経由で再現したいと思います。
アップデート内容を整理しよう
今回のアップデートにより、マルチリージョンの強力な整合性が設定されたDynamoDBグローバルテーブルがFISのアクションターゲットとして利用できるようになりました。DynamoDBグローバルテーブルのうち、マルチリージョンの強力な整合性が設定されたテーブルでも、FISの aws:dynamodb:global-table-pause-replicationを実行してリージョン間のレプリケーションを一時的に停止する障害を再現できます。
もともと、FISはDynamoDBグローバルテーブルに対応していました。こちらは2024年のアップデートページにて確認できます。
DynamoDBグローバルは、整合性オプションとしてマルチリージョンの結果整合性(参考:DynamoDB グローバルテーブルの仕組み - Amazon DynamoDB)のみを提供していました。そこに対して、2025年6月にDynamoDBがマルチリージョンの強力な整合性を後追いでサポートしました。
こちらのアップデートは、弊社ブログでもご紹介しています。
今回のFISのアップデートは、2025年6月のDynamoDBマルチリージョン強整合性サポートに追従した形ですね。
今回のアップデートは、us-east-1(バージニア北部)、us-east-2(オハイオ)、us-west-2(オレゴン)、ap-northeast-1(東京)、ap-northeast-3(大阪)、ap-northeast-2(ソウル)、eu-west-1(アイルランド)、eu-west-2(ロンドン)、eu-central-1(フランクフルト)、eu-west-3(パリ)の10リージョンで利用可能です。
やってみた
ということで、実際にマルチリージョン強整合性を設定したDynamoDB グローバルテーブルに対して、FISでレプリケーション障害を起こしてみます。
マルチリージョン強整合性グローバルテーブルは3つのリージョンが必須ですので、プライマリリージョンとしてap-northeast-1(東京)、レプリカリージョン1としてap-northeast-2(ソウル)、レプリカリージョン2としてap-northeast-3(大阪)の3リージョン構成でグローバルテーブルを作成します。
グローバルテーブルの作成
まず、マルチリージョン強整合性を有効にしたグローバルテーブルを作成します。
aws dynamodb create-table \
--table-name TestGlobalTable \
--attribute-definitions \
AttributeName=id,AttributeType=S \
AttributeName=timestamp,AttributeType=N \
--key-schema \
AttributeName=id,KeyType=HASH \
AttributeName=timestamp,KeyType=RANGE \
--billing-mode PAY_PER_REQUEST \
--region ap-northeast-1
DynamoDBのコンソール上でも、テーブルが作成されているのが確認できます。

次に、ソウルと大阪の2つのレプリカを追加して、マルチリージョン強整合性を有効化します。
aws dynamodb update-table \
--table-name TestGlobalTable \
--replica-updates '[{"Create":{"RegionName":"ap-northeast-2"}},{"Create":{"RegionName":"ap-northeast-3"}}]' \
--multi-region-consistency STRONG \
--region ap-northeast-1
DynamoDBのコンソール上でも、ソウルリージョンと大阪リージョンにテーブルが作成されて、全てのレプリカが「アクティブ」の状態になっているのが確認できます。

IAMロールの作成
FISの実験を実行するには、FISがDynamoDBテーブルにアクセスするためのIAMロールが必要です。まず、FISがロールを引き受けることを許可する信頼ポリシーを作成します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "fis.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
このJSONファイルを使ってIAMロールを作成します。
aws iam create-role \
--role-name FISExperimentRole \
--assume-role-policy-document file://fis-trust-policy.json \
次に、DynamoDBへのアクセス権限をロールにアタッチします。JSONファイルに、FISからDynamoDBへのアクセス権限を記述します。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:PutResourcePolicy",
"dynamodb:DeleteResourcePolicy",
"dynamodb:GetResourcePolicy",
"dynamodb:DescribeTable",
"tag:GetResources",
"dynamodb:InjectError"
],
"Resource": "*"
}
]
}
このJSONファイルを使って、先ほど作成したIAMロールに、IAMポリシーをアタッチします。
aws iam put-role-policy \
--role-name FISExperimentRole \
--policy-name FISDynamoDBPolicy \
--policy-document file://fis-dynamodb-policy.json
FISで実験
続いて、FIS実験テンプレートを作成します。マルチリージョン強整合性グローバルテーブル(東京・ソウル・大阪の3リージョン構成)のレプリケーションを5分間停止し、その状態でDynamoDBのグローバルテーブルの挙動を見てみます。
今回は実験テンプレートを、次のようなJSONで記述します。
{
"description": "DynamoDB グローバルテーブルのレプリケーション一時停止テスト",
"roleArn": "arn:aws:iam::245999598778:role/FISExperimentRole",
"targets": {
"DynamoDBTables": {
"resourceType": "aws:dynamodb:global-table",
"resourceArns": [
"arn:aws:dynamodb:ap-northeast-1:245999598778:table/TestGlobalTable"
],
"selectionMode": "ALL"
}
},
"actions": {
"PauseReplication": {
"actionId": "aws:dynamodb:global-table-pause-replication",
"description": "グローバルテーブルのレプリケーションを一時停止",
"parameters": {
"duration": "PT5M"
},
"targets": {
"Tables": "DynamoDBTables"
}
}
},
"stopConditions": [
{
"source": "none"
}
]
}
こちらのJSONファイルを使って、FISの実験テンプレートを作成します。
aws fis create-experiment-template \
--cli-input-json file://experiment-template.json \
--region ap-northeast-1
FISのコンソールでも、実験テンプレートが作成されていますね。

FISの実験の前に、DynamoDBにサンプルのデータを挿入しておきます。
$ aws dynamodb put-item \
--table-name TestGlobalTable \
--item '{
"id": {"S": "test-001"},
"timestamp": {"N": "1738308000"},
"message": {"S": "Hello from Tokyo region"},
"status": {"S": "active"}
}' \
--region ap-northeast-1
$ aws dynamodb put-item \
--table-name TestGlobalTable \
--item '{
"id": {"S": "test-002"},
"timestamp": {"N": "1738308000"},
"message": {"S": "Hello from Tokyo region"},
"status": {"S": "active"}
}' \
--region ap-northeast-1
それでは、実際にFISの実験を実行してみます。
aws fis start-experiment \
--experiment-template-id EXT2Q1Hyg7CpCYYQ \
--region ap-northeast-1
AWS上でも、FISの実験が開始されたことが確認できました。

この状態で、5分間DynamoDBのメトリクスを確認していました。レプリケーションやその他のレイテンシーを特にウォッチしていたのですが、ほんの少しレイテンシーは上がった気がします。ですが、有意にレイテンシーが上がったとは断言できなさそうです...

一方で、面白い挙動も見られました。この状態では、対象のDynamoDBテーブルへのPutItemはInternal server errorになります。
$ aws dynamodb put-item \
--table-name TestGlobalTable \
--item '{
"id": {"S": "test-003"},
"timestamp": {"N": "1738308000"},
"message": {"S": "Hello from Tokyo region"},
"status": {"S": "active"}
}' \
--region ap-northeast-1
An error occurred (InternalServerError) when calling the PutItem operation (reached max retries: 2): Internal server error
AWSドキュメントを見てみると、FISでaws:dynamodb:global-table-pause-replicationを実行している時は、対象のDynamoDBテーブルに対してdynamodb:UpdateTableを拒否するリソースポリシーが追加されるみたいなんですよね。
拒否されるアクションは、あくまでdynamodb:UpdateTableというコントロールプレーン操作です。PutItemなどのデータプレーン操作には影響しません。コントロールプレーン・データプレーンに関しては、こちらのドキュメントをご参照ください。
にもかかわらず、PutItemでInternal Server Errorが発生しています。おそらくですがレプリケーションが停止されているときは書き込み操作をDynamoDBのサービス側で拒否しているのではないでしょうか?
マルチリージョン強整合性が有効になっているDynamoDBグローバルテーブルは、書き込みが他のリージョンにレプリケートされてから成功を返すため、レプリケーションが停止している状態では整合性を保証できず、書き込みを受け付けられないと考えられます。
しっかりマルチリージョン強整合性を感じられた
「レプリケーション停止中は書き込み操作がInternal Server Errorで失敗する」という挙動を確認できました。
レプリケーションが拒否されるという挙動は直接は確認できませんでしたが、サービスの内部をちょこっと見れたみたいで非常に興味深かいですね、では!









