Amazon Cognito のマルチリージョンレプリケーションで東京→バージニアの認証冗長化を試してみた

2026年6月にGAされたAmazon Cognitoのマルチリージョンレプリケーション機能を使い、東京リージョンのユーザープールをバージニアにレプリケートしました。CLIベースのセットアップ手順、両リージョンでの認証テスト、レプリカ側の書き込み制限についてまとめています。

Amazon Cognito 認証認可セキュリティ DR/BCP AWS

suzuki.ryo

2026.06.04

はじめに

Amazon Cognito でマルチリージョン構成を実現するには、これまでカスタム実装が必要でした。ユーザーデータのエクスポート・インポート、パスワードのリセット、リージョンごとに異なる issuer への対応など、運用負荷の高い作業が求められていました。

2026 年 6 月 3 日、Amazon Cognito にマルチリージョンレプリケーション機能が GA されました。

観点	従来（カスタム実装）	マルチリージョンレプリケーション
データ同期	エクスポート＋インポートの自前実装	自動レプリケーション
パスワード	方式によってはリセットや移行処理が必要	レプリカ側でも同じパスワードで認証可能
issuer	リージョンごとに異なる	Updated Issuer で統一
クライアント設定	リージョンごとに再作成	自動レプリケート（※ Updated Issuer 移行時はエンドポイント変更が必要）
トークン検証	リージョン別に JWKS 管理	共通の JWKS で検証可能

公式ブログで詳細が紹介されています。

本記事では、東京リージョン（ap-northeast-1）をプライマリ、バージニアリージョン（us-east-1）をレプリカとして構成し、CLI ベースでセットアップから認証テスト、レプリカ側の制約確認までを検証します。

検証環境

項目	値
Primary	ap-northeast-1（東京）
Replica	us-east-1（バージニア）
Tier	ESSENTIALS
AWS CLI	v2.34.58

本記事のコマンドでは以下の変数を使用します。

PRIMARY_REGION=ap-northeast-1
REPLICA_REGION=us-east-1
USER_POOL_ID=ap-northeast-1_xxxxxxxxx
CLIENT_ID=xxxxxxxxxxxxxxxxxxxxxxxxxx
KMS_KEY_ID=mrk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

セットアップ

マルチリージョンレプリケーションを有効化するには、以下の前提条件を順番に満たす必要があります。

なお、create-user-pool-replica などの新しい API は AWS CLI v2.34.58 以降で利用可能です。古いバージョンではコマンドが認識されないため、事前にアップデートしてください。

KMS マルチリージョンキーの作成
キーポリシーの設定
ユーザープールの作成（CMK 指定）
IssuerConfiguration の変更
レプリカの作成と有効化

KMS マルチリージョンキーの作成

マルチリージョンレプリケーションには、KMS カスタマーマネージドキー（CMK）が必須です。通常の KMS キーではなく、マルチリージョンキーを作成し、レプリカリージョンにも複製します。

# プライマリリージョンにマルチリージョンキーを作成
aws kms create-key \
  --multi-region \
  --description "Multi-region key for Cognito" \
  --region ${PRIMARY_REGION}

{
    "KeyMetadata": {
        "KeyId": "mrk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
        "MultiRegion": true,
        "MultiRegionConfiguration": {
            "MultiRegionKeyType": "PRIMARY"
        }
    }
}

レプリカリージョンにキーを複製します。

aws kms replicate-key \
  --key-id ${KMS_KEY_ID} \
  --replica-region ${REPLICA_REGION} \
  --region ${PRIMARY_REGION}

キーポリシーの設定

Cognito がキーを使用できるよう、キーポリシーに cognito-idp.amazonaws.com と identitystore.amazonaws.com の両サービスへの権限を付与します。identitystore.amazonaws.com はレプリケーション時に内部的に使用されるサービスで、公式ドキュメントのポリシー例に従って設定します。

両リージョン（プライマリ・レプリカ）のキーにそれぞれ設定が必要です。

キーポリシー例（Cognito 関連部分）

{
    "Sid": "Allow Cognito to use the key",
    "Effect": "Allow",
    "Principal": {
        "Service": [
            "cognito-idp.amazonaws.com",
            "identitystore.amazonaws.com"
        ]
    },
    "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey",
        "kms:CreateGrant"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "aws:SourceAccount": "000000000000"
        }
    }
}

上記ポリシーを含む完全なキーポリシーを JSON ファイルとして保存し、両リージョンに適用します。既存の管理者権限を残したうえで、上記ステートメントを追加してください。

aws kms put-key-policy \
  --key-id ${KMS_KEY_ID} \
  --policy-name default \
  --policy file://key-policy.json \
  --region ${PRIMARY_REGION}

aws kms put-key-policy \
  --key-id ${KMS_KEY_ID} \
  --policy-name default \
  --policy file://key-policy.json \
  --region ${REPLICA_REGION}

ユーザープールの作成

--key-configuration で CMK を指定して UserPool を作成します。

aws cognito-idp create-user-pool \
  --pool-name multi-region-test \
  --user-pool-tier ESSENTIALS \
  --key-configuration KeyType=CUSTOMER_MANAGED_KEY,KmsKeyArn=arn:aws:kms:${PRIMARY_REGION}:000000000000:key/${KMS_KEY_ID} \
  --region ${PRIMARY_REGION}

{
    "UserPool": {
        "Id": "ap-northeast-1_xxxxxxxxx",
        "Name": "multi-region-test"
    }
}

IssuerConfiguration の変更

レプリケーション前に、OIDC Issuer を Updated 形式に切り替えます。Updated Issuer は https://issuer-cognito-idp.[region].amazonaws.com/[userPoolId] という形式です。今回の構成では、レプリカリージョンで認証しても iss はプライマリである ap-northeast-1 の issuer になりました。そのため、東京・バージニアのどちらで認証しても、同じ issuer / JWKS を前提にトークンを検証できます。

aws cognito-idp update-user-pool \
  --user-pool-id ${USER_POOL_ID} \
  --issuer-configuration Type=UPDATED \
  --key-configuration KeyType=CUSTOMER_MANAGED_KEY,KmsKeyArn=arn:aws:kms:${PRIMARY_REGION}:000000000000:key/${KMS_KEY_ID} \
  --region ${PRIMARY_REGION}

レプリカの作成

前提条件を満たした状態で、レプリカを作成します。

aws cognito-idp create-user-pool-replica \
  --user-pool-id ${USER_POOL_ID} \
  --region-name ${REPLICA_REGION} \
  --region ${PRIMARY_REGION}

{
    "UserPoolReplica": {
        "RegionName": "us-east-1",
        "Status": "CREATING",
        "Role": "SECONDARY"
    }
}

レプリカの有効化

レプリカはまず CREATING → INACTIVE と遷移します。INACTIVE になったら手動で ACTIVE に切り替えます。

# ステータス確認（CREATING → INACTIVE を待つ。約2分）
aws cognito-idp list-user-pool-replicas \
  --user-pool-id ${USER_POOL_ID} \
  --region ${PRIMARY_REGION}

{
    "UserPoolReplicas": [
        {
            "RegionName": "us-east-1",
            "Status": "INACTIVE",
            "Role": "SECONDARY"
        },
        {
            "RegionName": "ap-northeast-1",
            "Status": "ACTIVE",
            "Role": "PRIMARY"
        }
    ]
}

# レプリカを有効化
aws cognito-idp update-user-pool-replica \
  --user-pool-id ${USER_POOL_ID} \
  --region-name ${REPLICA_REGION} \
  --status ACTIVE \
  --region ${PRIMARY_REGION}

これでセットアップは完了です。プライマリ（東京）で作成したユーザーやクライアント設定がレプリカ（バージニア）に自動同期されます。

認証テスト

プライマリ（東京）で作成したユーザーが、レプリカ（バージニア）からも認証できるか検証しました。

テストユーザーの準備

プライマリリージョンでアプリクライアントとテストユーザーを作成します。

# アプリクライアント作成
aws cognito-idp create-user-pool-client \
  --user-pool-id ${USER_POOL_ID} \
  --client-name test-client \
  --explicit-auth-flows ALLOW_USER_PASSWORD_AUTH ALLOW_REFRESH_TOKEN_AUTH \
  --region ${PRIMARY_REGION}

{
    "UserPoolClient": {
        "ClientId": "xxxxxxxxxxxxxxxxxxxxxxxxxx",
        "ClientName": "test-client"
    }
}

以降、この ClientId を CLIENT_ID として使用します。

# テストユーザー作成
aws cognito-idp admin-create-user \
  --user-pool-id ${USER_POOL_ID} \
  --username testuser01 \
  --temporary-password 'TempPass1!' \
  --message-action SUPPRESS \
  --region ${PRIMARY_REGION}

# パスワードを確定
aws cognito-idp admin-set-user-password \
  --user-pool-id ${USER_POOL_ID} \
  --username testuser01 \
  --password 'TestPass123!' \
  --permanent \
  --region ${PRIMARY_REGION}

レプリカを ACTIVE にした後も、ユーザーやクライアントの反映には数十秒かかる場合があります。admin-get-user でレプリカ側にユーザーが見えることを確認してから認証テストに進みました。

プライマリ（東京）での認証

aws cognito-idp initiate-auth \
  --auth-flow USER_PASSWORD_AUTH \
  --client-id ${CLIENT_ID} \
  --auth-parameters USERNAME=testuser01,PASSWORD='TestPass123!' \
  --region ${PRIMARY_REGION}

成功しました。

レプリカ（バージニア）での認証

aws cognito-idp initiate-auth \
  --auth-flow USER_PASSWORD_AUTH \
  --client-id ${CLIENT_ID} \
  --auth-parameters USERNAME=testuser01,PASSWORD='TestPass123!' \
  --region ${REPLICA_REGION}

こちらも成功しました。

トークンの比較

両リージョンで取得したトークンの主要 claim を比較しました。

ID トークン:

claim	東京（Primary）	バージニア（Replica）
iss	`https://issuer-cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_xxxxxxxxx`	同一
sub	`a7445a18-xxxx-xxxx-xxxx-xxxxxxxxxxxx`	同一
aud	`xxxxxxxxxxxxxxxxxxxxxxxxxx`	同一

アクセストークン:

claim	東京（Primary）	バージニア（Replica）
iss	`https://issuer-cognito-idp.ap-northeast-1.amazonaws.com/ap-northeast-1_xxxxxxxxx`	同一
sub	`a7445a18-xxxx-xxxx-xxxx-xxxxxxxxxxxx`	同一
client_id	`xxxxxxxxxxxxxxxxxxxxxxxxxx`	同一

iss・sub・aud（client_id）が両リージョンで一致しています。iat・exp・jti は認証タイミングにより異なりますが、トークン検証で参照する claim は同一であるため、リージョンごとにトークン検証ロジックを分岐させる必要はありません。

ただし、既存プールで Updated Issuer へ切り替える場合は、アプリケーション側の issuer / JWKS エンドポイント設定の更新が別途必要です。

レプリカの書き込み制限

レプリカリージョンのユーザープールは、認証とユーザーデータ参照を主目的とした読み取り専用のエンドポイントです。書き込み系の操作がどのように拒否されるか確認しました。

検証結果

操作	API	結果
ユーザー作成	AdminCreateUser	❌ 拒否
セルフサインアップ	SignUp	❌ 拒否
パスワード設定 (Admin)	AdminSetUserPassword	❌ 拒否
パスワード変更 (User)	ChangePassword	❌ 拒否
パスワードリセット	ForgotPassword	❌ 拒否
属性更新	AdminUpdateUserAttributes	❌ 拒否
ユーザー参照	AdminGetUser	✅ 成功

今回試した書き込み操作は、いずれも同一のエラーで拒否されました。

An error occurred (OperationNotEnabledException) when calling the AdminCreateUser operation:
This operation is not enabled in this region for this User Pool

Admin API・ユーザー向け API を問わず、エラータイプは一貫して OperationNotEnabledException、メッセージは "This operation is not enabled in this region for this User Pool" です。レプリカで発行された有効なアクセストークンを使用した ChangePassword も同様に拒否されました。

各操作のコマンドと出力

ユーザー作成:

aws cognito-idp admin-create-user \
  --user-pool-id ${USER_POOL_ID} \
  --username testuser02 \
  --temporary-password 'TempPass1!' \
  --message-action SUPPRESS \
  --region ${REPLICA_REGION}
# → OperationNotEnabledException

セルフサインアップ:

aws cognito-idp sign-up \
  --client-id ${CLIENT_ID} \
  --username testuser03 \
  --password 'TestPass123!' \
  --region ${REPLICA_REGION}
# → OperationNotEnabledException

パスワード設定:

aws cognito-idp admin-set-user-password \
  --user-pool-id ${USER_POOL_ID} \
  --username testuser01 \
  --password 'NewPass456!' \
  --permanent \
  --region ${REPLICA_REGION}
# → OperationNotEnabledException

パスワード変更（ユーザー操作）:

aws cognito-idp change-password \
  --previous-password 'TestPass123!' \
  --proposed-password 'NewPass789!' \
  --access-token '<レプリカで取得した有効なアクセストークン>' \
  --region ${REPLICA_REGION}
# → OperationNotEnabledException

パスワードリセット:

aws cognito-idp forgot-password \
  --client-id ${CLIENT_ID} \
  --username testuser01 \
  --region ${REPLICA_REGION}
# → OperationNotEnabledException

属性更新:

aws cognito-idp admin-update-user-attributes \
  --user-pool-id ${USER_POOL_ID} \
  --username testuser01 \
  --user-attributes Name=email,Value=test@example.com \
  --region ${REPLICA_REGION}
# → OperationNotEnabledException

ユーザー参照（成功）:

aws cognito-idp admin-get-user \
  --user-pool-id ${USER_POOL_ID} \
  --username testuser01 \
  --region ${REPLICA_REGION}
# → 正常にユーザー情報が返却される

アプリケーション設計としては、このエラータイプをハンドリングして書き込み操作をプライマリリージョンへルーティングするか、認証エンドポイントと書き込みエンドポイントを最初から分離する方針が考えられます。

レプリカ上限の確認

1 つのユーザープールに複数リージョンのレプリカを追加できるか検証しました。既にバージニア（us-east-1）のレプリカが存在する別のプール（us-west-2 がプライマリ）に対して、3 リージョン目の追加を試みます。

aws cognito-idp create-user-pool-replica \
  --user-pool-id us-west-2_xxxxxxxxx \
  --region-name ap-northeast-1 \
  --region us-west-2

An error occurred (LimitExceededException) when calling the CreateUserPoolReplica operation:
User pool has reached the maximum allowed number of replicas

LimitExceededException で拒否されました。1 プールあたりレプリカは 1 つが上限です。つまりプライマリ＋レプリカの 2 リージョン構成が最大となります。

3 リージョン以上で認証を分散させたい場合は、別プール構成など別の設計が必要になります。なお、同じ KMS マルチリージョンキーを複数プールで共有することは可能です。

コスト目安

マルチリージョンレプリケーションは Cognito の基本料金に加えてアドオン料金が発生します。2026 年 6 月時点の公開料金に基づく概算を示します。

前提条件:

Cognito Essentials tier、レプリカ 1 リージョン
KMS マルチリージョンキー 2 リージョン分（プライマリ＋レプリカ）
Cognito の基本料金には Free Tier（10,000 MAU）を適用
MRR（Multi-Region Replication）アドオンに Free Tier はありません
KMS はキー月額のみ（API リクエスト料金は除外）
SMS・メール送信・Advanced Security の料金は含みません

MAU	Cognito 基本	MRR アドオン	KMS（2 リージョン）	月額目安
1,000	$0（Free Tier）	~$5	~$2	~$7
10,000	$0（Free Tier 適用後）	~$45	~$2	~$47
100,000	~$1,350（Free Tier 控除後）	~$450	~$2	~$1,802

算出単価: Cognito Essentials $0.015/MAU、MRR アドオン $0.0045/MAU/レプリカリージョン、KMS $1/キー/リージョン/月。

料金の詳細は Amazon Cognito の料金ページおよび AWS KMS の料金ページを参照してください。

注意事項

Updated Issuer への切り替えは既存アプリへの破壊的変更です。 公式ブログに「requests to the old endpoints will no longer be routed correctly」と明記されています。issuer を固定値で検証しているアプリケーションは、事前にエンドポイントの更新が必要です
TOTP MFA はセカンダリレプリカで非対応です。MFA 設定済みユーザーはプライマリでのみ認証可能です
パスワード認証失敗カウントはリージョン間で非同期のため、ブルートフォース対策のロックアウト閾値が各リージョン独立で評価されます
「次世代インフラストラクチャ」上のプールのみ対応です。古い既存プールは AWS による移行完了後に利用可能になります
フェイルオーバーを自動化するには、カスタムドメインや DNS ルーティングの設計が必要です。API を直接呼び出す構成では、アプリケーション側で呼び出し先リージョンを切り替える実装が必要になります

まとめ

Amazon Cognito のマルチリージョンレプリケーションにより、東京リージョンのユーザープールをバージニアリージョンへレプリケートし、両リージョンで認証できることを確認しました。KMS マルチリージョンキーと Updated Issuer を利用することで、同一のクライアント ID と issuer / JWKS を前提にでき、トークン検証ロジックをリージョンごとに分ける必要はありません。

ただし、レプリカは読み取り専用であり、ユーザー登録・パスワード変更・属性更新などはプライマリへルーティングする必要があります。また、1 プールあたりのレプリカは 1 つまでのため、3 リージョン以上では別プール構成などの検討が必要です。

既存アプリでは Updated Issuer への切り替えが破壊的変更となる点に注意しつつ、新規構築では本番利用前に対応しておくと、将来的なマルチリージョン化に備えやすくなります。