既存の Amazon Cognito ユーザープールにマルチリージョンレプリケーションをマネジメントコンソールから有効化してみた
はじめに
Amazon Cognito にマルチリージョンレプリケーション (MRR) が追加され、ユーザーディレクトリを別リージョンのレプリカユーザープールへ複製できるようになりました。リージョン障害が起きても、レプリカ側で認証を継続できる、というものです。
東京とバージニア北部の組み合わせで検証した記事は以下をご参照ください。
実運用では、すでに稼働しているユーザープールに後から MRR を入れたい、というケースのほうが多いはずです。そこで本記事では、稼働中の既存ユーザープールに対して MRR の前提を整え、レプリカ作成まで持っていけるのかを、マネジメントコンソールから確認してみました。
既存プールに MRR を入れる前提
MRR を有効化するには、ユーザープール側が以下のような条件を満たしている必要があります。
- 機能プランが Essentials または Plus であること (Lite は不可)
- 保管時の暗号化にマルチリージョンの AWS KMS カスタマーマネージドキーを使っていること
- OIDC issuer が Updated issuer (マルチリージョン対応) になっていること
加えて、MRR は最新の Amazon Cognito インフラストラクチャで稼働するユーザープールでないと設定できません。コンソール上で MRR の設定項目が出てくるかどうかで判別できるようです。この前提は、公式ドキュメントでも次のように述べられています。
マルチリージョンレプリケーションは、現時点ではすべてのユーザープールで利用できるわけではありません。マルチリージョンレプリケーションには、機能とスケーラビリティが強化された最新の Amazon Cognito インフラストラクチャが必要です。
今回のプールはこの設定項目が表示されたので対象ですね。
新規作成であれば作成時にまとめて満たせる条件ですが、既存プールでは初めから揃っているとは限りません。今回の検証用プールも、機能プランは Plus だったものの、暗号化はデフォルトの AWS 所有キー、issuer も従来の Original のままでした。つまり、CMK と issuer はあとから設定し直す必要があります。ここが新規作成との一番の違いだと思います。
マルチリージョン CMK を用意する
まず、保管時の暗号化を AWS 所有キーからマルチリージョン CMK に切り替えます。MRR の画面を開くと、有効化までの開始方法がステップで案内されます。
開始方法のステップから「保管中の暗号化を編集」に進み、キーのタイプを「別の AWS KMS キーを選択する (詳細)」にします。
ここで「AWS KMS キーを作成」を押すと KMS のコンソールへ移動します。キーのタイプは対称、キーの使用法は暗号化および復号化、キーマテリアルのオリジンは KMS とし、マルチリージョンキーとして作成しました。キーポリシーはこの時点ではデフォルトのままで構いません。
レプリカ先のリージョンにもこのキーが必要になるので、マルチリージョンキーを us-east-1 にレプリケートしておきます。そのうえで「保管中の暗号化を編集」画面に戻り、作成した KMS キーを指定します。
キーを指定すると、「KMS キーポリシーの拡張」に、この CMK に設定すべきキーポリシーが表示されます。ここには「ユーザープールのみ」と「ユーザープールとログのエクスポート」の 2 つが用意されていて、どちらを選ぶかは、ユーザープールでログのエクスポートを使っているかどうかで決まります。
ログのエクスポートを含む側のポリシーは、ログのエクスポートを設定している場合に適用するもので、Cognito がログを書き出すときに暗号化し、中間サービスが復号してから配信先に書き込めるようにするためのもののようです。今回の検証プールは userAuthEvents のログを出力しているので、「ユーザープールとログのエクスポート」を選びました。ログのエクスポートをしていないプールなら「ユーザープールのみ」で問題ありません。
表示されるポリシーは、暗号化コンテキストで対象のユーザープール ARN に絞り込まれていて、最小権限を意識した作りになっています。cognito-idp.amazonaws.com だけでなく identitystore.amazonaws.com にも権限が渡る点や、kms:EncryptionContext:aws:cognito-idp:userpool-arn で対象プールに限定しているようでした。
あとはこのポリシーを KMS キーに反映し、暗号化の変更を保存すれば、設定が CMK に切り替わります。
なお、この CMK を無効化するとユーザープールは認証不能になり、削除すると復旧不能になります。無効化は再有効化すれば戻せますが、削除のほうは AWS KMS が即時削除を許さず削除予約になるとはいえ、予約期間を過ぎれば取り返しがつきません。いずれにせよ運用責任が一段重くなる点は意識しておきたいところです。
issuer を Updated に切り替える
次に、OIDC issuer を Original から Updated に切り替えます。
Updated issuer に切り替えると https://issuer-cognito-idp.[region].amazonaws.com/[userPoolId] という、issuer- のプレフィックスが付いたホスト名になります。発行されるトークンの iss クレームも、この新しい issuer に切り替わります。
ここが既存プールならではの注意点になります。既にこのプールでアプリを動かしている場合、アプリ側がトークン検証で issuer を固定値で持っていると、切り替え後は iss クレームが一致せず検証が通らなくなります。JWKS の取得先も issuer- 付きのホストに変わるので、discovery を使わず URL を直書きしているアプリは合わせて見直しが必要です。MRR の前提を満たすための設定変更が、そのまま既存アプリへの破壊的変更になってしまうわけです。
本番で切り替えるなら、先にアプリケーション側で新しい issuer と JWKS も受け付けられるようにしておいてから、プール側を切り替える順番が安全だと思います。
レプリカユーザープールを作成する
前提が揃うと、レプリカユーザープールを作成できるようになります。
MRR の画面から「レプリカユーザープールを作成」を選び、リージョンに us-east-1 を指定すると、レプリカが作られます。
作成直後のレプリカは INACTIVE の状態で、本番トラフィックに使う前にリージョン個別の設定を整える流れになっています。
前提さえ満たしてしまえば、レプリカの作成自体はコンソールの数クリックで終わります。
レプリカ作成後に残る設定
一方で、これだけでマルチリージョン構成が完成するわけではない点は注意が必要です。
レプリカ作成後の比較テーブルを見ると、Cognito ドメイン、E メール設定、Lambda トリガー、ログのエクスポート設定などは、レプリカ側で個別に設定する必要があります。これらはプライマリの設定が自動で複製されるわけではありません。今回の検証プールにも認証後の Lambda トリガーが紐付いていましたが、いずれも東京リージョンにしか存在しないため、us-east-1 側で相当するものを用意しないと同じ挙動にはなりません。
つまり MRR の導入では、周辺リソースをリージョンごとに揃える設計と移行作業まで見込んでおく必要があります。
もう一点、レプリカ先として大阪リージョン (ap-northeast-3) が現時点で対応していない点も気になりました。国内で完結したディザスタリカバリ構成を組みたい場合には、ここがネックになりそうです。対応リージョンは今後増える可能性もあるので、いつか大阪が入ってくれることを期待しています。
まとめ
稼働中の既存ユーザープールでも、機能プランの確認、マルチリージョン CMK の用意、Updated issuer への切り替えという前提を順に整えれば、レプリカユーザープールの作成までは問題なく進められました。
ただ、issuer 切り替えが既存アプリにとって破壊的変更になる点と、ドメインや E メール、Lambda トリガーといった周辺設定をリージョンごとに作り込む必要がある点を踏まえると、既存プールへの導入は思い立ってすぐ、というよりは移行計画を立てて段階的に進めるテーマだと感じました。大阪リージョンが未対応な点も含め、構成要件と相談しながら検討していくのがよさそうです。
