災害対策を検討するとき、「バックアップを別リージョンに保存している」「DR側にもWeb/APやDBを用意している」という説明をよく聞きます。
データを遠隔地に保全し、サーバやデータベースを別リージョンで起動できるようにすることは重要です。ただ、それだけで業務を再開できるとは限りません。
DBが復旧している。Web/APも起動している。それでも利用者がログインできなければ、オンラインサービスは利用できません。
DRで確認すべきなのは、リソースが存在するかではなく、利用者が認証され、必要な処理を実行し、安全に業務を継続できる一連の経路が成立するかです。
Amazon Cognitoは、この問題を分かりやすく示す例です。
本記事では、実際のDR検討で経験した問題と、2026年に提供開始されたAmazon Cognito User PoolsのMulti-Region Replication（MRR）を題材に、AWSのDR設計で何を確認すべきかを整理します。
1. DRは「データ」「起動」「業務経路」の3レベルで考える
DRを考えるときは、どこまで復旧できれば「DRが成立した」と考えるのかを3つのレベルに分けると整理しやすくなります。
レベル1は、データが残っている状態です。
データベースのバックアップやスナップショット、オブジェクトストレージ、AMIなどを遠隔リージョンへ保管し、大規模障害でもデータや復旧資材を失わないようにします。
レベル2は、システムを起動できる状態です。
DRリージョンでネットワーク、サーバ、コンテナ、データベースなどを起動し、アプリケーションが動作できるところまで復旧します。
レベル3は、安全に業務経路が成立する状態です。
利用者がシステムへ到達できるか。認証できるか。適切な権限でAPIやDBへアクセスできるか。KMS、Secrets、外部IdP、外部APIなどの依存先がDRリージョンでも利用できるか。
ここまで確認して初めて、業務を再開できます。
バックアップがあることは、DRの一部にすぎません。
図 DRは「データが残る」「システムが起動する」だけではなく、「安全に業務経路が成立する」ところまで確認する
2. DRではリソース一覧ではなく「1トランザクション」を追う
DR設計では、EC2、RDS、S3、Lambdaなど、AWSリソース単位で対策を並べがちです。
リソース単位の確認は必要ですが、それだけでは依存関係を見落とします。
見るべきなのは、利用者が1回の業務処理を完了するまでに何を通るのかです。
Webシステムなら、利用者はDNS、WAFやロードバランサー、Web/APを通り、認証基盤で認証された後、DBや外部APIを使って業務処理を行います。
認証基盤が外部IdP、メール、SMS、Lambda Triggerへ依存する構成もあります。KMS、Secrets Manager、証明書は複数の処理から参照される共通依存です。
監視、ログ、運用管理端末、管理アクセスもDR時に必要になります。
2026年9月のAWS Security Blog記事でも、Cognito MRRを利用する場合、Lambda、WAF、SNS、SES、CloudWatchなどのリージョナルな構成を別リージョンのレプリカ側で準備する必要があると説明されています。
DR設計で見る単位を、
何のリソースを複製したか
から、
利用者が業務を完了するまでに、どの依存先を通るか
へ変えることが重要です。
図 DRでは利用者からDBまでの本流だけでなく、認証、外部IdP、KMS、Secrets、外部API、監視など、その業務経路を支える依存先まで確認する
認証フローは構成によって異なります。Amazon CognitoのManaged Loginでは、ブラウザがCognitoのドメインへ直接遷移する場合があるため、この図は依存関係を理解するための概念図です。
3. 実案件で直面した「データは送れるが、認証できない」問題
Amazon Cognitoが大阪リージョンへ対応する前の案件で、東京リージョン全体が利用できなくなった場合に、大阪リージョンで業務を継続する構成を検討しました。
Cognitoが大阪リージョンで利用可能になったのは2023年9月1日です。今回の案件はそれより前の検討でした。
AWSの発表はWhat’s Newで確認できます。
私がこの案件で強く印象に残ったのは、データを大阪へ持っていけることと、大阪で業務を継続できることは別だったという点です。
Web/APやデータ、復旧資材を大阪側へ持つ構成は検討できました。
しかし当時はAmazon Cognitoを大阪リージョンで利用できず、認証を大阪側だけで完結できませんでした。
Web/APやDBを大阪側に用意しても、利用者がログインできなければオンライン業務は成立しません。
結果として、大阪側ではデータを遠隔保全するところまでとし、認証を含めて大阪側で業務を継続するDR構成にはできませんでした。
この経験は、前章で整理した「データが残る」だけでは、「安全に業務経路が成立する」ところには届かない例です。
DR要件を「別リージョンにデータを保管する」とだけ定義すると、この違いを見落とします。
4. Cognito MRRで何が変わったのか
2026年6月、Amazon Cognito User PoolsにMulti-Region Replication（MRR）が追加されました。
提供開始時の概要はAWS What’s Newで確認できます。
MRRではPrimary User Poolを権威あるユーザープールとし、ユーザー属性、ハッシュ化された認証情報、グループ、App Client、外部IdP設定などをSecondaryへ複製します。
レプリケーションはPrimaryからSecondaryへの一方向です。
Secondaryではサインインやトークン発行などの認証処理を継続できますが、Primaryとまったく同じ機能を持つわけではありません。
図 MRRにより認証基盤を別リージョンへ複製できるようになった。ただし、レプリケーションだけでDRが完成するわけではなく、フェイルオーバー方式や周辺依存を別途設計する必要がある
以下は、2026年10月時点のAmazon Cognito Developer Guideに基づく主な前提と制約です。
| 観点 | MRRで確認する内容 |
|---|---|
| Feature Plan | EssentialsまたはPlusが必要。MRRは追加料金のアドオン |
| 暗号化 | Multi-RegionのCustomer Managed KMS Keyが必要 |
| User Pool | 新しいCognito基盤に対応したUser Poolが対象。対象外の既存PoolはAWS側のアップグレードが必要 |
| Secondary数 | 1つまで |
| 初期状態 | SecondaryはINACTIVEで作成され、リージョン固有設定を確認してからACTIVEへ変更 |
| データ同期 | Primary→Secondary。結果整合のため短時間の同期遅延があり得る |
| Secondaryでのユーザー作成 | Signup、Adminによる新規作成とも不可 |
| ユーザー変更 | パスワードリセット、プロフィール変更はSecondaryでは不可 |
| Federated User | Primaryで一度サインインしたユーザーのみSecondaryでサインイン可能 |
| MFA | TOTP MFAはSecondaryでは非対応 |
| ロックアウト | パスワード認証のログイン失敗回数はリージョン間で同期されない |
| リージョン固有設定 | Email、SMS、Lambda Trigger、Tags、Log export、WAFなどはSecondary側でも設定が必要 |
詳細な制約はAmazon Cognito Developer Guideに整理されています。
issuerもDRの依存関係になる
MRRを検討するときはOIDC issuerにも注意が必要です。
Cognitoにはoriginal issuerとupdated issuerがあり、AWSはMRRを含むUser Poolでupdated issuerを推奨しています。
updated issuerではOIDC discoveryとJWKSを複数リージョンで提供できます。
MRR自体はoriginal issuerでも利用できます。
ただしoriginal issuerのOIDC discovery endpointとJWKS endpointは単一リージョンに紐づきます。リージョン障害時にはJWKSを取得できない可能性があり、アプリケーションが公開鍵を動的に取得してトークン署名を検証する構成では影響を受ける可能性があります。
updated issuerへ移行できない場合、AWS Security Blogでは、アプリケーションのトークン検証層でJWKSをキャッシュする方法を緩和策として挙げています。
認証サービスがSecondaryで動作しても、トークンを検証する側が参照するJWKSまで確認しなければ、認証経路全体の可用性は評価できません。
また、2026年10月時点のDeveloper Guideでは、updated issuerはApplication Load BalancerのCognito認証、およびAmazon API Gateway REST APIのCognito authorizerとは互換性がありません。
サービス仕様が変わる可能性があるため、実装時には最新ドキュメントの確認が必要です。
ALB認証の制約とJWKSキャッシュは別の論点です。JWKSキャッシュはアプリケーション側のトークン検証層に対する対策であり、ALB認証の非互換を解消する方法ではありません。
5. 東京→大阪DRで確認すべきこと
2026年6月のMRR提供開始時点では、対応リージョンに東京は含まれていましたが、大阪は含まれていませんでした。
提供開始時点の対象リージョンはAWS What’s Newで確認できます。
ここで重要なのは、
「大阪リージョンでCognitoを利用できる」ことと、「東京のCognito User Poolを大阪へMRRできる」ことは別
という点です。
東京→大阪を前提にFull-stack DRを設計する場合、MRRの対応リージョンを設計時点で確認する必要があります。
対応していなければ、MRRを利用できる別リージョンの組み合わせへ設計を変更する方法があります。この場合、ユーザー情報が別リージョンへ複製されるため、データ所在や組織内の規程との整合も確認が必要です。
AWS Security Blogでも、Secondaryのリージョンを選ぶ際にはdata sovereigntyやresidency要件を確認するよう説明しています。
MRRを使わず、別User Poolを自前で同期する方法も考えられます。
AWSは、MRR以前の手動エクスポートやインポートには、データ露出や不整合のリスク、利用者へのパスワードリセットといった課題があったとAWS News Blogで説明しています。
単に「同期処理を作ればよい」と考えず、運用負荷とセキュリティまで含めて評価する必要があります。
MRRの対象リージョンは追加される可能性があるため、実装時には最新のAWS公式情報を確認してください。
6. 「認証だけのDR」と「システム全体のDR」は違う
2026年9月のAWS Security Blogでは、CognitoのフェイルオーバーをAuthentication-only failoverとFull-stack failoverに分けています。
Authentication-only failoverは、アプリケーション本体を同じリージョンで稼働させたまま、認証だけをCognitoのSecondaryへ切り替える方式です。
Full-stack failoverは、compute、data store、API、authenticationなど、アプリケーション全体を別リージョンへ切り替える方式です。
Lambda TriggerがリージョナルなDynamoDBへアクセスする場合など、認証処理の周囲にある依存先もDR側で成立させる必要があります。
先ほどの東京→大阪の実案件は、東京リージョン全体が利用できなくなることを想定していました。
求めていたのはFull-stack failoverです。
CognitoのMRRが成立しても、Web/AP、DB、API、Lambda、KMS、Secrets、外部サービスなどがDRリージョンへ切り替わらなければ、Full-stack DRにはなりません。
複数コンポーネントの切替を協調させる仕組みとして、AWSは**Amazon Application Recovery Controller（ARC）**も紹介しています。
認証、compute、database、APIなどをリカバリープランとして扱い、切替を協調させる選択肢です。
DR時だから認証を弱めてよいわけではない
DRでは可用性の回復が優先されやすく、「ログインできないなら認証を一時的に緩める」という発想が出ることがあります。
避けるべき設計です。
情報セキュリティでは、可用性だけでなく機密性と完全性も維持する必要があります。
MRRのSecondaryでTOTP MFAを利用できないなら、障害発生後に認証水準を下げるのではなく、SMS OTP、Email OTP、passkeyなど、利用可能な代替方式を平時に設計します。
SMSを使う場合も、Secondary側でSNS設定や送信元IDの登録が必要です。登録に時間がかかる場合があるため、DR発動後に準備するものではありません。
フェイルオーバー先ではPrimaryとは別に失敗回数が管理されます。ロックアウトまでの失敗回数が引き継がれないため、切替後のロックアウト判定はPrimaryの状態と一致しない場合があります。
DRでは、可用性だけでなく、認証・アクセス制御の挙動が切替前後でどう変わるかも確認する必要があります。
セキュリティリスクから要件を導き、残存リスクまで評価する考え方については、次の記事で整理しています。
7. フェイルオーバーは「何を異常とみなすか」まで設計する
Managed LoginやFederationを利用する構成では、Cognito MRRはRoute 53 Health Checkを利用したフェイルオーバーに対応しています。
Custom DomainだけでなくPrefix Domainでも利用できます。
Health Checkを設定し、Unhealthyになった場合、CognitoはSecondaryを利用する認証経路へ切り替えられます。
重要なのは、MRRを有効にするだけで切り替わるわけではないことです。
何をもってPrimaryが異常と判断するのかは、利用者側が設計します。
単純なHTTP死活監視では、認証処理そのものが失敗していてもHealthyになる可能性があります。
AWS Security Blogでは、CloudWatch Syntheticsで実際の認証フローを実行し、その結果をCloudWatch AlarmとRoute 53 Health Checkへつなぐ例を紹介しています。
単なる死活監視ではなく、認証処理がエンドツーエンドで成立しているかを見る考え方です。
SDKやCognito APIを直接利用する構成では、アプリケーション側でRegional Endpointの切替を行います。
AWS Security Blogでは、カスタムエンドポイントやプロキシを介してPrimaryとSecondaryへルーティングする構成も示されています。
DR設計書に、
CognitoはMRRを利用する
とだけ書いても不足です。
最低でも、何を監視するのか、どの状態を障害と判定するのか、自動切替か運用者判断か、誰が復旧を判断するのか、どこまでを一緒に切り替えるのかを決める必要があります。
この領域は基本設計と運用設計の両方にまたがります。
可用性方式や依存関係を基本設計で具体化する考え方については、次の記事で整理しています。
監視条件、障害判定、切替手順、復旧後の戻し方については、次の記事で整理しています。
8. AWS DR設計で確認したいチェックリスト
MRRの前提
- □ 利用するUser PoolとPrimary、SecondaryのリージョンがMRRの対象か
- □ EssentialsまたはPlus、Multi-Region KMS KeyなどMRRの前提を満たすか
- □ original issuerとupdated issuerのどちらを使うか決め、その依存先への影響を確認したか
障害時に認証できるか
- □ Secondaryを
ACTIVEにする前に、Lambda、WAF、SNS、SES、ログなどのリージョン固有設定を完了したか - □ SMSを使う場合、Secondary側のSNS設定と送信元IDなどの登録を済ませたか
- □ TOTP利用者の代替認証方式を平時に決めたか
- □ Route 53 Health Checkで何を異常とみなすかを決めたか
- □ 自動切替か手動切替か、判断者と復旧判断を決めたか
- □ SDKやAPIを直接利用する場合のRegional Endpoint切替方式を決めたか
業務経路全体が成立するか
- □ DNS、WAF/LB、Web/AP、DBまでDR側で利用できるか
- □ KMS、Secrets、証明書がDRリージョンでも利用できるか
- □ 外部IdP、外部API、外部システムへの接続を確認したか
- □ 認証後に呼ばれるLambdaや、その先のデータストアまで確認したか
- □ 監視、ログ、運用管理端末、管理アクセスがDR時にも利用できるか
- □ 「ログイン → 業務処理 → データ参照・更新」まで実際にDRテストしたか
- □ Health Checkを意図的に反転し、PrimaryからSecondaryへの切替と復帰を確認したか
AWS Security Blogでは、Health Checkの反転やAWS Fault Injection Service（FIS）を使ったフェイルオーバーテストも紹介されています。
チェックリストで重要なのは、個々のAWSサービスが存在するかではありません。
業務を開始して終了するところまで、一連の経路を実際に通せるかです。
9. まとめ
バックアップがあることと、DR先で業務を継続できることは同じではありません。
データが残っている。システムも起動できる。それでも、認証やKMS、外部サービスなどの依存先が成立しなければ、利用者は業務を再開できません。
Amazon CognitoのMRRによって、User Poolを別リージョンへ複製し、認証基盤の可用性を高められるようになりました。
MRRにもリージョン条件、Secondaryの機能制限、issuer、リージョナルサービス、フェイルオーバー方式など、確認すべき依存関係があります。
Authentication-only failoverとFull-stack failoverも区別する必要があります。
DRで確認すべきなのは、
「何をバックアップしたか」ではなく、「利用者が安全に業務を再開できるか」
です。
この視点で1トランザクションの経路を追うと、バックアップ一覧やリソース一覧だけでは見えなかったDRの弱点が見えてきます。
参考資料
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 Developer Guide — Identity provider and relying party endpoints
https://docs.aws.amazon.com/cognito/latest/developerguide/federation-endpoints.html
AWS Security Blog — Architecting resilient authentication with Amazon Cognito multi-Region replication
2026年9月15日
https://aws.amazon.com/blogs/security/architecting-resilient-authentication-with-amazon-cognito-multi-region-replication/
AWS What’s New — Amazon Cognito now supports multi-Region replication
2026年6月4日
https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-cognito-multi-region/
AWS News Blog — Improve your application resilience with Amazon Cognito multi-Region replication
2026年6月3日
https://aws.amazon.com/blogs/aws/improve-your-application-resilience-with-amazon-cognito-multi-region-replication/
AWS What’s New — Amazon Cognito がアジアパシフィック（大阪）リージョンとイスラエル（テルアビブ）リージョンでご利用いただけるようになりました
2023年9月1日
https://aws.amazon.com/jp/about-aws/whats-new/2023/09/amazon-cognito-new-regions/
コメント