Amazon Cognito user poolsをログイン基盤として使っているチームにとって、2026年6月3日のAWS News Blogで発表されたmulti-Region replicationは、かなり実務寄りの更新です。
ただし、これは「Cognitoを有効化すれば、認証機能が完全なactive-active構成になる」という話ではありません。主に守りやすくなるのは、既存ユーザーのサインイン継続、トークン発行、マネージドログインやフェデレーションの入口です。ユーザー作成、サインアップ、パスワードリセット、プロファイル変更、TOTP MFAなどには制約が残ります。
この記事では、Amazon Cognitoのmulti-Region replicationを、ログイン基盤のDRとして導入前に何を確認すべきかに絞って整理します。確認日は2026年6月4日午前、Asia/Tokyo時点です。
Amazon Watch JapanはAmazon.com, Inc.、Amazon Web Services, Inc.および各関係会社と提携していない独立サイトです。この記事は製品・サービス更新の確認を目的としており、投資助言ではありません。
3行まとめ
このテーマをもう少し広げて見るなら、Amazon Bedrock AgentCore Identityが既存Secrets Manager参照に対応：AIエージェントの認証情報管理で確認すべきこと と AWS ConfigがBedrock AgentCore/SageMaker系9リソースに対応：AI基盤の設定監査で確認すべきこと も合わせて確認してください。Cognitoでログイン基盤のDRを考える読者は、外部APIやSaaS認証情報の管理境界も合わせて確認すると、IDまわりの責任分担を整理しやすくなります。
primary RegionのUser Poolをreplica user poolへ同期し、リージョン障害時の既存ユーザー認証継続を支えます。
EssentialsまたはPlus feature plan、multi Region customer managed KMS key、multi Region向けOIDC issuerなどを確認します。
secondaryではユーザー作成、サインアップ、パスワードリセット、プロファイル変更、TOTP MFAなどに制約があります。
MRRはログイン基盤のDRを補強しますが、すべての認証関連操作を別リージョンで同じように続ける機能ではありません。
- Amazon Cognito user poolsのmulti-Region replicationは、primary Regionのユーザーディレクトリを追加リージョンのreplica user poolへ同期し、リージョン障害時の認証継続に使う機能です。
- 利用にはEssentialsまたはPlus feature plan、multi-Region customer managed KMS key、multi-Region向けのOIDC issuerなどの前提があります。Liteでは有効化できません。
- secondary replicaでは、サインインやトークン発行の継続に使える一方、ユーザー作成、サインアップ、パスワードリセット、プロファイル変更、TOTP MFAなどに制約があります。導入判断では「何を守るDRなのか」を先に決める必要があります。
今回の需要シグナルは、AWS News Blogの新規発表、Cognito APIのreplica関連変更、AWS利用者コミュニティで続いてきたCognitoのマルチリージョン要望です。ただし、仕様や料金の根拠にはAWS公式ブログ、Amazon Cognito Developer Guide、Pricingページを使っています。
Amazon Cognito MRRで何が変わったのか
- 1primary Region
User Poolの管理設定とユーザーディレクトリの中心として動きます。
- 2replica user pool
追加リージョンで同期されたユーザー情報を使い、障害時のサインインとトークン発行を支えます。
- 3入口の切り替え
custom domainやアプリ側ルーティングで、利用者の認証リクエストを使えるリージョンへ向けます。
- 4残る設計
書き込み操作、外部IdP、API/SDK直叩き、監視と復旧手順は別に確認します。
secondaryは完全な独立本番系ではなく、同期済みユーザーの認証継続を支えるreplicaとして見ると判断しやすくなります。
Amazon Cognito user poolsのmulti-Region replication、以下MRRは、追加のAWSリージョンにreplica user poolを作り、認証インフラの事業継続と災害対策に使えるようにする機能です。AWS News Blogでは、リージョン障害時に一貫したユーザー認証を維持したいという開発者の要望を背景に、MRRの提供開始が説明されています。
これまでCognitoを使ったマルチリージョン構成では、別リージョンにUser Poolを手動で作る、ユーザー移行を考える、アプリクライアントやissuerを分ける、外部IdPのコールバックURLを複数管理する、といった設計負担がありました。MRRはその一部をサービス側の機能として吸収します。
User Poolを別リージョンに複製できる
MRRを有効にすると、primary RegionのUser Poolに対して、追加リージョンのreplica user poolを作れます。AWSの説明では、primaryからsecondaryへユーザーデータやmachine secret、User Pool設定を同期し、secondary側で認証処理を継続できるようにします。
ここで大事なのは、複製先が「完全な独立本番系」ではないことです。primaryは引き続き管理設定やユーザーディレクトリの書き込みの中心です。secondaryは、障害時に既存ユーザーのサインインやトークン発行を支えるためのreplicaとして読む方が安全です。
根拠
Amazon Cognito Developer Guideは、MRRを追加リージョンのreplica user poolを作成する機能として説明しています。あわせて、secondary user poolは作成直後にINACTIVE状態から始まり、本番トラフィックに使う前にリージョン別設定を確認してからACTIVEにする流れも示しています。
DRで守れるのは主に既存ユーザーの認証継続
ログイン基盤のDRで最初に決めるべきなのは、何を止めないかです。MRRで期待しやすいのは、既存ユーザーがサインインし、アクセストークンやIDトークンを取得し、現在のセッションを維持しやすくすることです。AWS News Blogでも、secondary Regionへの切り替え時に、既存ユーザーが既存の認証情報でサインインを続けられる点が説明されています。
一方で、新規登録やアカウント管理まで同じレベルで継続できると考えると、設計を誤ります。障害時の画面、問い合わせ導線、サポート手順、外部IdP、メール/SMS、Lambda triggers、WAF、アプリ本体のリージョン設計まで合わせて見なければ、ユーザーのログイン体験は止まり得ます。
判断の軸
MRRを評価するときは、既存ユーザーがサインインできるか、トークンを発行できるか、フェデレーションを通せるか、アプリやバックエンドがsecondaryへ向けられるか、の4点で読むと整理しやすくなります。
「Cognitoが複製されるか」ではなく、「ユーザーが障害時に何を続けられるか」を基準にしてください。
まず確認する前提条件
前提条件を満たさない場合は、MRRの設計より先にUser Pool tier、暗号鍵、issuer、リージョン選定を見直します。
MRRは、どのUser Poolにもそのまま入れられる機能ではありません。Developer GuideとPricingページを見ると、feature plan、KMS、OIDC issuer、対象リージョン、User Pool側のインフラ対応を先に確認する必要があります。
EssentialsまたはPlusが必要で、Liteでは使えない
Developer Guideでは、MRRにはEssentialsまたはPlus feature planが必要で、LiteのUser Poolでは有効化できないと説明されています。Pricingページでも、Amazon CognitoのUser PoolにはLite、Essentials、Plusの3つのpricing tierがあり、EssentialsはManaged Loginやパスキー、メール、SMSによるpasswordless loginなどを含み、Plusはリスクベースのadaptive authenticationやcompromised credentials detectionなどを追加する位置づけです。
AWS News Blogの発表時点では、MRRはEssentialsおよびPlus利用者向けのadd-on featureとして提供されています。ユーザー認証では、Essentials tierが月間アクティブユーザーあたりreplica Regionごとに0.0045ドル、Plus tierが同0.006ドルと説明されています。machine-to-machine authenticationでは、成功したtoken issuedに対する標準のvolume-based pricingに30%上乗せされる説明です。
注意点
料金は更新される可能性があります。この記事では2026年6月4日午前時点の公式ブログとPricingページに基づいていますが、導入前には必ずAmazon Cognito Pricingで、自社のtier、MAU、M2M authorization、higher API RPS quota、replica Region、契約条件を確認してください。
multi-Region KMS keyとOIDC issuerを先に見る
MRRでは、User Poolをmulti-Region customer managed keyで構成する必要があります。このKMS keyは、User Pool replicaがあるすべてのAWSリージョンで利用できる必要があります。既存のUser PoolがAWS managed keyや単一リージョンのkeyを前提にしている場合、MRRの前提を満たせるかを先に見ます。
もう一つの重要点はOIDC issuerです。Developer Guideは、リージョンをまたいだtoken validationの一貫性を確保するために、multi-Region OIDC issuerが必要だと説明しています。Cognitoのfederation endpointsドキュメントでは、従来のoriginal issuerと、multi-Region replicationを含むUser Poolに推奨されるupdated issuerが分けられています。
移行で見落としやすいところ
issuer URLをアプリケーション、API Gateway authorizer、外部サービス、社内ライブラリで固定している場合、MRRの前に検証が必要です。JWKS取得、キャッシュ、issuer検証、IdP側の設定が絡むためです。Cognitoの設定だけを見て「MRRのボタンが押せるか」を確認するのではなく、トークンを検証するすべての場所を棚卸ししてください。
対象リージョンと既存User Poolの対応状況を見る
AWS News Blogでは、MRRの対象リージョンとして、US East、US West、Asia Pacific、Canada、Europe、South Americaの複数リージョンが挙げられています。日本の読者に関係しやすい点では、Asia PacificにTokyoが含まれています。発表文では、列挙されたリージョンをsourceまたはdestinationに使えると説明されています。
ただし、対象リージョンにあるUser Poolなら必ず今すぐ使える、とは考えない方がよいです。Developer Guideでは、コンソール上で対象User PoolにMRR設定が表示されるか、対象外の場合に例外メッセージが出るかを確認する流れが示されています。
確認項目
最低限、User Poolのfeature plan、KMS key、OIDC issuer、primaryとsecondaryにしたいリージョン、現在のUser PoolがMRR設定画面に対応しているかを確認します。既存の本番User Poolで直接試すのではなく、同じ認証方式を持つ検証用User Poolで再現してから本番設計へ移すのが現実的です。
フェイルオーバーはcustom domain中心で考える
- 1managed login
custom domainを使うと、Route 53 health checkの状態を見たCognito側ルーティングを設計できます。
- 2federation
外部IdPからのresponseを受ける入口もcustom domainに寄せると、切り替え時の設定を整理しやすくなります。
- 3prefix domain
リージョンごとのdomainやIdPコールバックURLを個別に扱う設計になります。
- 4API/SDK direct call
アプリやバックエンド側でCognitoエンドポイントの切り替えを持つ必要があります。
custom domainはフェイルオーバー設計の中心になりますが、API/SDKで直接Cognitoを呼ぶ構成ではアプリ側の切り替え設計も必要です。
MRRを有効にしても、すべてのクライアントが自動的にsecondaryへ向かうわけではありません。どの入口を使っているかで、フェイルオーバーの責任分界が変わります。
managed loginとfederationはcustom domainが軸になる
Developer Guideでは、multi-Region User Poolの自動フェイルオーバーを構成できるのはcustom domainを使う場合だと説明されています。custom domainはOAuth 2.0のauthorize endpoint、token endpoint、外部IdPからのresponseを受ける入口になります。
AWS News Blogでも、managed loginとfederationでcustom domainを使う場合、Amazon Route 53 health check IDを指定して組み込みのtraffic routing featureを使えると説明されています。つまり、ユーザーがログイン画面へ向かう入口をcustom domainに寄せ、Cognito側がhealth checkの状態を見てprimaryまたはsecondaryで処理する、という設計になります。
注意点
ここをDNS failoverだけの話として単純化しない方がよいです。Route 53 health checkは、Cognito側のrouting判断に使う指標です。アプリがどのURLへリダイレクトするか、外部IdPのcallback URLが何を許しているか、cookieやredirect URIがどう扱われるかは、アプリ側の設計と合わせて確認します。
prefix domainだけの運用では設定が増える
Cognito User Poolにはリージョンごとのprefix domainもあります。secondaryのprefix domainを直接使えば、限定的なテストや手動切り替えの検証はできます。
しかし、フェデレーションを使う場合は、外部IdP側に複数のcallback URLを登録する必要が出る可能性があります。利用者向けにURLを切り替える運用も重くなります。本番で自動切り替えを考えるなら、custom domainを中心に置いた方が設計は整理しやすいです。
判断基準
検証や緊急時の手動手順ならprefix domainも候補になります。通常運用でユーザーに意識させず切り替えたいなら、custom domain、Route 53 health check、IdP設定、アプリ側redirect URIをセットで設計する必要があります。
API/SDK直叩きはアプリ側の責任が残る
managed loginやfederationだけでなく、アプリやバックエンドがCognito APIやAWS SDKを直接呼ぶ構成もあります。この場合、custom domainのフェイルオーバーだけでは不十分です。Cognito APIのregional endpointをどちらに向けるかは、アプリケーション側で判断する必要があります。
たとえば、SPA、モバイルアプリ、バックエンドAPI、バッチ、社内管理画面がそれぞれ別のCognito呼び出しを持っている場合、どのコンポーネントがprimary障害を検知し、どこからsecondaryへ向けるのかを決めなければなりません。
実装観点
接続先リージョンをアプリに埋め込むより、バックエンドや設定配信で制御できる方が運用しやすい場合があります。MRRの検証では、ログイン画面だけでなく、refresh token、user info取得、管理API、サポート運用ツールまで確認対象に入れてください。
できないことを先に潰す
セキュリティとアカウント管理に関わる操作は単純な可否だけでなく、障害時の表示、問い合わせ対応、復旧後の整合性まで合わせて確認します。
MRRの記事で最も大切なのは、できることよりも、障害時にできないことを早めに潰すことです。ここを曖昧にすると、DR訓練では通っても本番障害時にユーザーサポートが詰まります。
secondaryではユーザー作成や属性変更に制約がある
Developer Guideは、secondary User Poolでは新しいユーザーを生成できないと説明しています。サインアップや管理者による作成が該当します。ユーザーはsecondary側でパスワードリセットやプロファイル変更もできません。
そのため、primary Regionに障害がある間は、アカウント新規作成、パスワードリセット、プロファイル編集、管理者によるユーザー作成などを一時的に止めるUIや運用手順が必要になります。
障害時UIの考え方
「ログインはできますが、アカウント管理は一部停止しています」という状態を、ユーザーにどう見せるかを決めます。パスワードリセット画面をそのまま出して失敗させるより、障害時用の案内、問い合わせ先、復旧後の再試行案内を出す方が、サポート負荷を下げられます。
TOTP MFAと初回フェデレーションユーザーは要注意
Developer Guideでは、secondary replicaでTOTP MFAがサポートされないことが示されています。TOTP MFAを設定しているユーザーは、primary Regionがリクエストを処理しているときに認証する必要があります。パスワードベース認証のロックアウト前の失敗回数も、リージョン間では同期されず、各replicaが独自に数えます。
また、新しいフェデレーテッドユーザーは、過去にprimary User Poolへサインインしていない場合、failover状態のsecondary User Poolへサインインできるとは限りません。B2Bや社内向けSAML/OIDC連携だけでなく、B2CでGoogle、Apple、Facebookなどのsocial sign-inを使うサービスでも確認が必要です。
確認項目
自社サービスのTOTP MFA利用率、TOTP必須ユーザーの割合、外部IdP経由ユーザー、初回ログイン前ユーザー、ロックアウト運用を確認します。セキュリティを弱めないためにも、DR目的でMFA条件を変える場合は、リスク受容、監査ログ、サポート手順まで同時に決めるべきです。
replicationは同期済みを前提にしすぎない
MRRはprimaryからsecondaryへ情報を同期しますが、障害の直前に行われた変更がすべて期待どおり反映されているかは、検証しなければ分かりません。ユーザー作成直後、パスワード変更直後、グループ変更直後、MFA設定変更直後のようなケースは、DRテストに入れておきたいところです。
評価基準
RTOやRPOを資料に書く前に、Cognito以外の部品も含めてテストします。外部IdP、DNS、Route 53 health check、Lambda triggers、メール/SMS、WAF、監視、アプリ本体、管理画面がそろって初めて、ユーザーから見たログインDRになります。
費用と運用負荷はどこで増えるか
LiteからEssentialsまたはPlusへ上げる必要があるかを最初に見ます。
Essentialsは月間アクティブユーザーあたりreplica Regionごとに0.0045ドル、Plusは0.006ドルという発表値を確認します。
machine to machine認証では、成功したtoken issuedの増加が費用に効きます。
health check、custom domain、KMS keyなど周辺サービスもDR費用に含めます。
フェイルオーバー、failback、障害時UI、監視確認の継続コストを見ます。
月間アクティブユーザーだけではなく、replica Region数、M2Mトークン量、周辺サービス、訓練頻度を分けると上振れ要因を見落としにくくなります。
MRRは可用性を上げるための機能ですが、料金と運用負荷は別に見積もる必要があります。Cognito本体の料金だけでなく、replica、M2M、RPS、Route 53、KMS、検証作業を分けて考えます。
User Pool tierとMRR add-onを分ける
まず、LiteからEssentialsまたはPlusへ上げる必要があるかを確認します。すでにEssentialsまたはPlusを使っている場合でも、MRR add-onの料金が別にかかります。AWS News Blogでは、Essentials tierは月間アクティブユーザーあたりreplica Regionごとに0.0045ドル、Plus tierは0.006ドルと説明されています。
ユーザー認証だけでなく、M2M認証をCognitoで扱っている場合は、成功したtoken issuedに対する標準のvolume-based pricingに30%上乗せされる点も確認します。APIやagentic AIのバックエンドでM2Mトークンを多く発行する構成では、ユーザー数だけでは見積もれません。
上振れ要因
フェイルオーバー時には、再ログイン、リトライ、監視、テスト、手動確認が増えることがあります。通常時のMAUだけでなく、障害時に認証リクエストが偏る場合、higher API RPS quotaやM2M add-onも見ます。
Route 53、KMS、運用テストもDR費用に入れる
custom domainを使ったフェイルオーバーではRoute 53 health checkが関係します。multi-Region customer managed KMS keyも前提です。これらはCognitoの料金表だけを見ていると見落としやすい費用です。
さらに、DRは設定して終わりではありません。failoverテスト、failbackテスト、health checkの閾値調整、IdP callback URLの確認、障害時UIの切り替え、監査ログ確認、サポート訓練を継続的に行う必要があります。
評価基準
見積もり表は「Cognitoの月額」ではなく「ログインDRの月額と運用コスト」として作る方が実態に近くなります。Cognito、Route 53、KMS、IdP、メール/SMS、監視、サポート対応を分けて書くと、あとから責任範囲を説明しやすくなります。
導入前に試す検証シナリオ
- 通常時
primaryでサインイン、トークン発行、managed login、federation、API/SDK呼び出しが期待通りかを確認します。
- 手動切り替え
custom domain routingやアプリ側設定を使い、secondaryへ安全に向けられるかを確認します。
- primary障害想定
新規登録、パスワードリセット、プロファイル変更など止める操作の表示とサポート手順を確認します。
- 復旧後
failback後にサインイン、トークン、同期状態、監視アラートが戻るかを確認します。
検証はCognitoの状態だけでなく、アプリ、外部IdP、DNS、監視、問い合わせ対応まで含めて通すと実運用に近づきます。
MRRを本番に入れる前に、少なくとも通常時、手動フェイルオーバー、primary障害想定、復旧後のfailbackをテストします。ここでは記事を読んだあとに、そのまま検証表へ写せる粒度で確認項目を整理します。
replica状態をコンソールとAPIで確認する
AWS側では、CreateUserPoolReplica、ListUserPoolReplicas、UpdateUserPoolReplica、DeleteUserPoolReplicaのようなreplica関連APIが確認されています。記事執筆時点ではAPIやドキュメントの反映が進んでいる段階なので、最終的にはAWS公式のAPI Reference、AWS CLI、SDK、CloudFormationやCDKの対応状況を個別に確認してください。
検証では、replicaのRegion、status、ACTIVE/INACTIVE、primaryとsecondaryの役割、custom domainのrouting設定、Route 53 health check IDを確認します。
注意点
コマンドが打てることと、DRとして運用できることは別です。検証ログには、操作時刻、primary/secondaryの状態、ユーザー属性、issuer、token claims、IdPログ、CloudTrail、アプリログを残します。
custom domain failoverを安全に試す
managed loginとfederationを使うサービスでは、custom domainを通したフェイルオーバーが最も重要です。primaryがhealthyな状態、health checkをunhealthyにした状態、復旧後にprimaryへ戻す状態を分けてテストします。
見るべきものは、authorize endpointの応答、token endpointの応答、外部IdPからのredirect、issuer、JWKS取得、session cookie、既存ユーザーの再ログイン、現在ログイン中ユーザーの継続、エラー文言です。
観測項目
CloudTrail、アプリログ、IdPログ、Cognito関連ログ、監視メトリクスを同じ時刻でそろえます。ユーザーに見える画面も確認します。ログでは成功に見えていても、ユーザーの画面ではcallback URL mismatchやMFAエラーとして見えていることがあります。
障害時に止める画面と残す画面を決める
secondaryで成立しない操作は、障害時に止める判断が必要です。サインアップ、パスワードリセット、プロファイル編集、MFA設定変更、初回フェデレーションログインをどう扱うかを決めます。
残す画面は、secondaryで成立する操作に絞ります。止める画面は、ただエラーにするのではなく、復旧後に再試行してほしいこと、問い合わせ先、影響範囲を短く伝えます。これは技術設計であると同時に、カスタマーサポート設計でもあります。
検証後の判断
EssentialsまたはPlus、custom domain、updated issuer、multi-Region KMS key、外部IdP設定、アプリ側routingを確認でき、主目的が既存ユーザーのサインイン継続なら、MRRは検証に進む価値があります。
一方で、TOTP MFA必須ユーザーが多い、サインアップやパスワードリセットを止められない、issuer変更の影響範囲が読めない、外部IdP設定をすぐ変えられない場合は、MRRを本番DRとして扱う前に前提整備が必要です。
Amazon/AWSの2026年6月の重要トピックは、<a href="https://amzn-watch.blog.mo-gmo.com/monthly-topics-2026-06/">2026年6月 重要トピックまとめ</a>でも追っています。Cognito MRRのような基盤更新は、AWS News Blogだけでなく、Developer Guide、Pricing、API Referenceの更新とセットで見てください。
AWS公式発表の読み方は、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-10-amazon/">Amazon公式ニュースの読み方</a>でも整理しています。Cognito MRRのように、発表記事、製品ドキュメント、料金ページ、API差分を横断する更新では、1ページだけで判断しないことが大切です。
本番運用の監視という観点では、<a href="https://amzn-watch.blog.mo-gmo.com/amzn-19-bedrock-mantle-cloudwatch-metrics/">Amazon Bedrock MantleにCloudWatchメトリクス追加</a>の記事も参考になります。サービスは違いますが、公式発表を運用・監視・費用配賦へ落とし込む読み方は共通しています。
読了後にAmazon/AWSの公式発表やサービス更新の通知を受け取りたい場合は、<a href="https://amzn-watch.blog.mo-gmo.com/newsletter/">ニュースレター</a>で月次まとめや重要トピックの更新を追えます。本文の判断材料を置き換えるものではなく、一次情報を見に行くきっかけとして使ってください。
次に読むなら
次に読むなら
参照した主な情報源
確認日: 2026年6月4日 Asia/Tokyo。
- AWS News Blog: Improve your application resilience with Amazon Cognito multi-Region replication
https://aws.amazon.com/blogs/aws/improve-your-application-resilience-with-amazon-cognito-multi-region-replication/
- Amazon Cognito Developer Guide: Multi-Region replication for user pools
https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-multi-region.html
- Amazon Cognito Pricing
https://aws.amazon.com/cognito/pricing/
- Amazon Cognito Developer Guide: Identity provider and relying party endpoints
https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints.html
- Amazon Cognito Developer Guide: User pool feature plans
https://docs.aws.amazon.com/cognito/latest/developerguide/feature-plans-features.html