Amazon Cognito徹底解説：ユーザープールとIDプールで作る“現実的な認証基盤”｜GCP Identity Platform・Azure AD B2C（Microsoft Entra External ID）比較
はじめに：Cognitoは「ログイン機能」ではなく“運用できる認証基盤”です
Amazon Cognito（以下、Cognito）は、Web/モバイルアプリ向けにユーザー認証と認可を提供するサービスです。Cognitoの理解で最初に大切なのは、「ユーザーを保管してログインさせる」だけではなく、ソーシャル/外部IdP連携、トークン発行（OIDC/OAuth 2.0）、そしてアプリがAWSリソースへ安全にアクセスするための権限払い出しまでを、設計として組み立てられる点です。ユーザープールはアプリ視点でOpenID Connect（OIDC）IdPとして振る舞うことが明記されており、現代の認証基盤に必要な“標準プロトコルの土台”を持っています。
一方で、認証は「一度作れば終わり」になりません。MFA、パスワードリセット、異常ログイン、アカウント乗っ取り対策、利用者増によるコストの増え方、そして“失敗したときの問い合わせ対応”まで含めて、日々の運用負荷が積み上がります。だからこそ、本記事ではCognitoを“運用できる形”にするために、ユーザープール（User Pools）とIDプール（Identity Pools）を軸に、どの順番で設計し、どこで割り切り、何を最初に決めておくべきかを丁寧にまとめます。
加えて、同じCIAM（Customer Identity and Access Management）領域でよく比較される GCP Identity Platform と Azure AD B2C（Microsoft Entra External IDを含む文脈）も並べます。GCP Identity Platformは、アプリ向け認証のバックエンド/SDK/UIライブラリを提供すること、料金がMAU（Monthly Active User）中心であることが公式に示されています。
Azure側は、Azure AD B2CがCIAMであり、2025年5月1日以降は新規顧客向けに購入不可である旨が公式ドキュメントに明記される一方、既存顧客は利用継続できること、そして少なくとも2030年5月までサポートする方針がFAQで示されています。
この記事が役に立つ方：認証の“困りごと”があるチームほど効きます
まず、アプリ開発チーム（バックエンド/フロントエンド）の方に向いています。ログインや会員登録はプロダクトの入口なので、仕様変更が頻繁に起こりがちです。ソーシャルログインを追加したい、メール確認を必須にしたい、退会/復旧を整えたい、認証UIをブランドに合わせたい。こうした要求に対して、標準プロトコルに沿って“後から育てられる”構造を最初に作れると、開発のつらさが減ります。CognitoユーザープールはOIDC IdPとして振る舞い、外部IdP（SAML/OIDCなど）との連携エンドポイントが整理されています。
次に、SRE/運用担当の方です。認証は障害が起きると影響が大きく、問い合わせが集中しやすい領域です。だからこそ「ログインできない」の原因が、ユーザー属性、IdP連携、トークン、有効期限、レート制限、メール配信など、どこにあるかを切り分けられる設計が重要になります。Cognitoの世界では、後述するManaged Login/Hosted UI、外部IdP連携、そしてIDプールによる一時的AWS認証情報の払い出しなど、部品が整理されているため、切り分けの地図を作りやすいです。
そして、マルチクラウドや将来移行を視野に入れるアーキテクトの方にもおすすめです。GCP Identity PlatformもAzure AD B2Cも、料金の軸がMAUであったり、標準プロトコル（OIDC/OAuth、SAMLなど）で連携できたりと共通点がありますが、ロックインが強く出るのは「UIの作り方」「運用の癖」「サポート/販売方針の変化」です。Azure AD B2Cは購入可否の条件が変わっているため、今後の新規導入判断では特に“制度面”を前提として設計する必要があります。
1. Cognitoの全体像：ユーザープールとIDプールを“役割で分けて”理解します
Cognitoは大きく2つの柱で理解すると迷いにくいです。
- ユーザープール（User Pools）：アプリのユーザーディレクトリ＋認証（OIDC IdP）
- IDプール（Identity Pools）：フェデレーションされたユーザーに対して一時的なAWS認証情報を払い出す仕組み
ユーザープールは、アプリ視点でOIDC IdPとして機能する、と公式ドキュメントに明記されています。つまり、ユーザープールが発行するIDトークン/アクセストークンを、アプリが検証してセッションを作る、という現代的な構造が取りやすいのです。
一方で、IDプールは「フェデレーションされたIDのディレクトリ」であり、トークンと交換で一時的なAWS認証情報を生成できる、と説明されています。ゲスト（未認証）でも始められ、後からサインインして権限を拡張する、といった体験も可能です。
実務のコツは、最初から両方を全部使おうとしないことです。多くのアプリでは、まずユーザープールで“ログインとトークン”を整え、AWSリソースへ直接アクセスさせる要件がある場合にだけIDプールを足す、という順番が安定しやすいです。
2. ユーザープール：アプリのためのOIDC IdPとして使う
2-1. ユーザープールが提供するもの：ログインの“標準プロトコル化”
ユーザープールはユーザーディレクトリであり、アプリに対してOIDC IdPとして振る舞う、と公式に説明されています。ここが重要で、ログインを“独自実装”ではなく“標準プロトコル”に乗せられます。
ユーザープールのエンドポイント（managed login、SAML、OIDC、OAuth 2.0など）については、サーバーコントラクトとして整理され、認可エンドポイントへのアクセスが認証開始になること、Authorizeエンドポイントがmanaged loginページまたはIdPのサインインへリダイレクトすることなどが明確に書かれています。
この“明文化された振る舞い”があると、アプリ側は「トークンが取れる」「検証できる」「更新できる」という最低限の責務に集中できます。ログインの細かな挙動（画面やフロー）は、できるだけCognitoに寄せるか、あるいは自前で作るとしても標準フローに沿って設計できます。
2-2. Managed Login/Hosted UI：まずは“管理できるログイン画面”を持つ
Cognitoには、Hosted UI/Managed Loginを使ってOIDC/OAuth 2.0フローに沿ったログインを実装できるという整理があり、認可コードフロー（PKCE含む）などの観点が資料でも説明されています。
実務では、初期フェーズほど「自前ログイン画面を美しく作る」よりも、「パスワードリセットやメール検証などを含む一連の体験を、事故なく回せる」ことのほうが重要になりがちです。まずManaged Loginで動かし、ブランド要件が固まってからUIを深くカスタムする、という段階的な進め方が失敗しにくいです。
2-3. 外部IdP連携：OIDC/SAMLで“会社のSSO”や“ソーシャルログイン”に広げる
ユーザープールは外部IdPとしてOIDCを追加できる手順がドキュメント化されており、ソーシャル/外部プロバイダー連携を段階的に追加できます。
ここでの設計ポイントは、「アプリのユーザー体験」と「企業のIDガバナンス」が衝突しやすいことです。
- B2C（一般ユーザー）では、メール＋パスワード、ソーシャルログイン、パスワードレスなど、離脱を減らす方向に寄せたくなります。
- B2B（企業顧客）では、SAML/OIDCで顧客企業のSSOに寄せ、退職/異動と連動したアクセス制御を重視したくなります。
Cognitoはプロトコル面の部品が揃っているので、どちらにも寄せられます。ただし、設計が難しいのは「同じメールアドレスが複数IdPに存在する」「企業SSOと個人ログインが混在する」といった統合ポリシーです。ここは“技術”よりも“運用ルール”が先に必要になります。
3. IDプール：AWSリソースへのアクセスを“トークン→一時認証情報”で安全にする
IDプールは、フェデレーションされたIDをAWS認証情報と交換できるディレクトリであり、サインイン済み/未サインインに関わらずユーザーに一時的なAWS認証情報を生成できる、と説明されています。さらに、IAMロールとポリシーでユーザーに付与するアクセス許可のレベルを選べる点が明記されています。
この仕組みが役立つ典型例は次のようなケースです。
- モバイルアプリが、直接AWSのサービスへアクセスしたい（ただし永続的な鍵は持たせたくない）
- ゲスト利用（未ログイン）でも一部機能を使わせたいが、ログイン後に権限を拡張したい
- ユーザープールや外部IdPのトークンを“入口”として、AWSリソースアクセス権を最小権限で払い出したい
設計のコツは、「IDプールで払い出す権限は、本当に必要なものだけ」にすることです。アプリが直接AWSリソースへ触れる設計は便利な反面、権限が広いと不正利用時の被害が大きくなります。IDプールはIAMロールで権限を調整できるため、最小権限設計を一緒に育てるのが前提になります。
4. 実務サンプル：Cognito設計を“型”にしてチームで共有する
ここでは、すぐ会話に使えるように、Cognito設計の代表的な型を3つにまとめます。コードよりも“考え方”の型としてお使いください。
サンプルA：一般向けWebアプリ（まずユーザープールだけで始める）
- 目的：会員登録・ログイン・パスワードリセットをまず安定させる
- 構成：ユーザープール＋Managed Login（Hosted UI）でOIDC/OAuthフローを確立
- 運用の肝：ログインできない問い合わせ対応のために、メール検証やリセット動線の仕様を文書化しておく
最初は「ログインに関する仕様書」を薄くても良いので作るのがおすすめです。問い合わせ対応は、人によって案内がぶれるほど炎上しやすいからです。
サンプルB：企業向けSaaS（顧客企業のSSOを段階導入）
- 目的：顧客ごとにSSO（SAML/OIDC）を提供し、退職/異動と連動した統制をしやすくする
- 構成：ユーザープールに外部IdP（OIDC/SAML）を追加し、Authorizeエンドポイントから統一導線にする
- 運用の肝：顧客企業ごとの「IdP設定・属性マッピング・テスト手順」をテンプレ化する
SSOは“最初の1社”が一番大変で、2社目以降はテンプレが効きます。最初にテンプレ化を意識しておくと、将来の導入がぐっと楽になります。
サンプルC：モバイル/ゲーム（ゲスト→ログインで権限拡張）
- 目的：ゲストでも遊べるが、ログインすると保存や同期ができる
- 構成：IDプールで未認証（ゲスト）にも一時AWS認証情報を払い出し、ログイン後に別ロールで権限を増やす
- 運用の肝：ゲスト権限とログイン権限の差を明文化し、権限が広がりすぎないように監査する
5. 料金の考え方：Cognitoは“MAU課金”なので設計で読みやすくできます
Cognitoの料金ページでは、ユーザープールがMAU（Monthly Active Users）を軸に課金されることが示され、無料枠（例：10,000 MAU）を超えた分が段階課金される例も提示されています。さらに、メール送信はSESを使うため別料金になる旨も記載されています。
ここでの実務ポイントは、「認証コストはユーザー数に比例しやすい」ため、プロダクトの成長に合わせて見積もりを更新しやすいことです。逆に言えば、認証の仕様を不用意に“ログイン回数が増える方向”に変えるとMAUの定義に影響する可能性があるため、ビジネス側の施策（強制再ログインなど）とコストを同じ会議で扱うのが安全です。
また、Cognitoの料金体系には複数のティア（Liteなど）が見えるため、将来のセキュリティ機能（高度な保護）をどこまで必要とするかも、設計に織り込んでおくと意思決定が楽になります。
6. GCP Identity Platformとの比較：実装体験は“SDK/ライブラリ中心”で進めやすい
GCP Identity Platformは、アプリやサービスのユーザー認証を容易にするバックエンドサービスとSDK、UIライブラリを提供する、と公式に説明されています。つまり、開発体験としては「SDKでサインインを組み込み、管理面はコンソールで整える」流れが素直です。
料金面でも、Identity Platformは多くのサインイン手段がMAU課金であること、電話/多要素認証はメッセージ送信数で課金されることが明示されています。
Cognitoと比較する際の分かりやすい整理は次の通りです。
- どちらもMAU中心：成長に合わせてコストが見積もりやすい
- GCPはSDK/ライブラリの導線が前面に出やすい：アプリ実装の“迷い”が減りやすい
- AWSはユーザープール＋IDプールでAWS権限払い出しまで一体化しやすい：AWSリソースアクセス要件が強いほど自然
どちらが優位というより、「アプリがどれだけAWS/GCPのリソースへ直接触れるか」「認証まわりをどこまで自前で作りたいか」で、相性が分かれます。
7. Azure AD B2C（Microsoft Entra External ID文脈）との比較：制度面の前提が変わっている点に注意
Azure AD B2CはCIAMソリューションであり、ソーシャル/エンタープライズ/ローカルアカウントでアプリやAPIへSSOアクセスできる、と公式に説明されています。またスケール面（多数ユーザー/多数認証）や脅威監視（パスワードスプレー、ブルートフォース等）についても概要で触れられています。
一方で重要なのは、2025年5月1日よりAzure AD B2Cは新規顧客向けに購入できなくなったという注意書きが公式の日本語ページに明記されている点です。
さらにFAQでは、「既存のAzure AD B2C顧客は継続利用でき、体験（新しいテナントやユーザーフロー作成など）は変わらない」こと、そして「少なくとも2030年5月までサポート継続」の方針が示されています。
このため、Azure側との比較では、技術差だけでなく次の判断が必要になります。
- 既存顧客として継続利用なのか（制度上の前提が変わる）
- 新規導入であれば、Entra External IDの位置づけを含めた判断が必要（公式FAQや案内を前提にする）
Cognitoはその点、現時点の公式情報としては新規利用の可否に同様の注意書きは見当たらず（少なくともここで参照した公式資料内には）、制度面の不確実性が相対的に少ない状態で設計を進めやすい、という実務的な差が出ます。
8. 失敗しないためのチェックリスト：最初の2週間で決めたい7項目
最後に、Cognito導入で後から効いてくる“決めごと”を、チームで共有しやすい形にまとめます。ここを先に合意しておくと、認証が成長しても破綻しにくいです。
- ログイン方式の優先順位
- メール＋パスワードを基本にするのか、ソーシャルを先に出すのか、企業SSOを前提にするのか
- トークンとセッションの扱い
- OIDC/OAuth 2.0のフロー（認可コード＋PKCE等）を基本にし、トークン更新や失効時のUXをどうするか
- ユーザー属性（プロフィール）をどこまでCognitoに持たせるか
- Cognitoを“認証だけ”にするのか、プロフィールの一部も持たせるのか（将来移行のしやすさに影響します）
- 外部IdPの統合ルール
- 同一メールの扱い、リンクポリシー、テナント（顧客）ごとの分離方針
- AWSリソースアクセスが必要か（IDプールの要否）
- 必要なら、未認証/認証済みロールを分け、最小権限を徹底する
- コスト見積もりの更新頻度
- MAUの見積もりをいつ更新するか、メール送信（別料金要素）をどう扱うか
- 問い合わせ対応の標準手順
- ログイン不可、メール未着、パスワードリセット失敗、SSO設定不備などの“よくある事故”の一次対応フローを作る
まとめ：Cognitoは「標準プロトコル＋運用の型」で認証を育てられます
Cognitoのユーザープールは、アプリ視点でOIDC IdPとして機能し、managed loginやOIDC/OAuth 2.0エンドポイントが整理されています。これにより、ログインを標準プロトコルに沿って実装し、将来の外部IdP連携や運用拡張にも対応しやすくなります。
そしてIDプールは、フェデレーションされたユーザーへ一時的なAWS認証情報を払い出し、IAMロールで権限を調整できるため、AWSリソースへ安全にアクセスさせたい要件で強く役立ちます。
GCP Identity PlatformはSDK/ライブラリとバックエンドでアプリ認証を組み込みやすく、MAU中心の課金が明確です。
Azure AD B2CはCIAMとしての機能整理が充実していますが、新規購入可否など制度面の注意が公式に明記されているため、導入判断では技術だけでなく前提条件もセットで確認することが大切です。
最初の一歩としては、ユーザープールで「認可コードフロー＋Managed Login」を基本形にし、問い合わせ対応まで含めて“運用の型”を作るのがおすすめです。その上で、AWSリソースへの直接アクセスが必要なときにだけIDプールを足す。こう進めると、認証が“怖いもの”から“運用できる基盤”へ変わっていきます。