Cognitoのユーザーを別AWSアカウントへ移す場合は、移行先にユーザープールを用意し、そこへユーザーを移行します。判断の中心になるのは、既存パスワードを維持したいか、決まった時点でユーザー属性をまとめて登録したいかです。
ユーザー移行LambdaトリガーとCSVインポートでは、移行が進むタイミングや利用者への案内が異なります。この記事では、ユーザープール間の移行で先に整理したい点を説明します。アイデンティティプールの設定移行とは分けて考えてください。
最初に選ぶ2つの移行方法
| 比較点 | ユーザー移行Lambda | CSVインポート |
|---|---|---|
| 進め方 | 移行先へのサインイン時などにユーザーを作成 | 用意した属性情報をジョブでまとめて登録 |
| 既存パスワード | 移行元で認証し、同じパスワードを継続する構成が可能 | 通常の属性インポートでは引き継がない |
| 完了の考え方 | サインインしないユーザーへの別対応が必要 | 登録ジョブと、その後の初回認証を分けて確認 |
| 主な準備 | 認証フローと移行Lambdaの実装 | 属性の整形、初回利用・パスワード再設定の案内 |
公式の入口はユーザープールへのユーザーのインポートです。
1. パスワードを維持したいなら、サインイン時の移行を検討する
移行先プールに存在しないユーザーがパスワードでサインインすると、ユーザー移行Lambdaを呼び出せます。Lambdaで移行元ディレクトリの認証を行い、認証できたユーザーの属性を返すと、移行先にユーザーが作成されます。
既存パスワードを継続させる構成では、成功時のレスポンスで finalUserStatus を CONFIRMED にします。別アカウントの旧プールへアクセスする処理や権限、失敗時の扱いは、移行用の実装として設計します。
この方式では、利用していないユーザーは自動的にすべて移るわけではありません。「移行期間をいつまで続けるか」「残ったユーザーをどう扱うか」を決め、旧認証基盤を終了する条件を明確にします。
認証フローをSRPのままにしない
独自サインイン画面からSDK/APIを使う場合、移行時には USER_PASSWORD_AUTH または ADMIN_USER_PASSWORD_AUTH が必要です。通常の USER_SRP_AUTH では、移行Lambdaが旧ディレクトリで検証するためのパスワードを受け取れません。
また、移行Lambdaのリクエストにはパスワードが含まれるため、イベント全体をCloudWatch Logsへ出力しないようにします。認証フロー、レスポンス、ログの注意点はユーザー移行Lambdaの公式手順で確認できます。
パスワード忘れのフローでも移行トリガーは動作しますが、この場合はパスワードが渡されません。パスワードによるサインインと同じ処理を前提にせず、検証済みの連絡先と再設定フローを用意します。詳しくは移行トリガーのパラメータを参照してください。
2. CSVでは属性の登録と初回認証を分けて計画する
CSVインポートは、ユーザー名やメールアドレスなどの属性を、移行先へまとめて登録する方法です。移行先プールのCSVテンプレートに合わせてデータを整形し、ジョブの結果と失敗した行を確認します。
パスワードを含めない通常のインポートでは、ユーザーは RESET_REQUIRED となり、パスワード認証を使う際に再設定が必要です。再設定コードを受け取れる連絡先と、アプリケーション側の初回利用フローを確認しておきます。
なお、現在のCSV仕様には、対応する形式のパスワードハッシュをインポートする機能もあります。ただし、これは移行元から対応するハッシュを用意できる場合の機能です。Cognito間の移行で、ユーザー属性のエクスポートだけでパスワードまで移せると判断してはいけません。移行元から取得できる情報と対応形式を別途確認します。現在の仕様はCSVインポートの公式資料を参照してください。
ユーザーIDと、プール設定の移行も確認する
ユーザー情報を登録できても、アプリケーションの認証切り替えまで完了したことにはなりません。移行先で新しく作成されるユーザーの sub を、旧プールの値と同一と考えず、アプリケーション内の会員IDとの対応を設計します。
AWSのユーザープロファイルのエクスポートガイダンスでも、新プールでは新しいsubが割り当てられることや、パスワード・MFA情報などの移行制約が説明されています。このガイダンスを使う場合は、その対応範囲を確認してください。
- 必須属性、カスタム属性、サインインに使う名前・エイリアスをそろえる。
- アプリクライアント、認証フロー、コールバックURLを確認する。
- 外部IdP、グループ、利用者への権限付与を別途確認する。
- MFAの再登録やパスワード再設定が必要な利用者の案内を用意する。
- アプリのユーザープールID・クライアントID・トークン検証先を切り替える。
小さな範囲で、初回と2回目のサインインを試す
移行の確認では、ユーザーが作られたかだけでなく、最初のサインインと、移行済みになった後のサインインを確認します。パスワード忘れ、連絡先未検証、MFA、旧ユーザー名とエイリアスが異なる場合も、利用している構成に応じて試します。
CSVの先行登録とサインイン時移行を組み合わせる場合も、移行先に既にユーザーが存在すると通常の「未存在ユーザーの移行」条件に合わなくなる点を考慮します。方式を混ぜる前に、対象ユーザーをどう分けるかを決めてください。
