先に要点
- AWS Cognito は AWS が提供する マネージドな認証 / 認可サービス。OAuth 2.0 / OpenID Connect (OIDC) に標準対応し、「ユーザー登録 / ログイン / MFA / ソーシャルログイン / パスキー」 を一通り提供する。
- 大きく User Pool(ユーザー管理 + 認証) と Identity Pool(AWS リソースへの一時クレデンシャル発行) の 2 つで構成。混同しやすいが 役割が違う。多くの Web/API ユースケースでは User Pool だけで足り、Identity Pool は 「モバイル/ブラウザから直接 AWS リソースを触りたい」 時に使う。
- 典型構成は フロント → API Gateway / ALB → Lambda / バックエンド に対し、User Pool が発行する JWT を Authorizer で検証。API Gateway は Cognito Authorizer または JWT Authorizer(HTTP API)で連携できる。
- 料金は 月間アクティブユーザー(MAU)単位。一定 MAU まで無料枠あり、超過分は段階課金。「通常のログイン認証」 はマネージド IdP 全般の中で 比較的安価。アドバンスドセキュリティ(リスクベース認証)を有効にすると別料金。
- 判断軸: AWS 中心のスタックか」 「OIDC 標準で十分か」 「MAU 規模はどれくらいか」 `カスタマイズがどれくらい必要か。AWS と相性が良いが、カスタム UI / 複雑なフロー / マルチテナント要件が強いなら Auth0 / Okta の方がはまる場合もある。
「AWS で認証どうする?」 と聞かれて、「とりあえず Cognito 入れとこう」 まではよく聞きますが、実際に触ると User Pool と Identity Pool ってどっち使うの?」 「JWT は誰が発行するの?」 `API Gateway とどう繋ぐの? で詰まるのが Cognito の最初の壁です。
ざっくり言うと、AWS Cognito は AWS が用意した OIDC 対応のマネージド IdP です。「ユーザー管理 / ログイン / MFA / ソーシャル / パスキー」 を 1 つのサービスで賄え、JWT を発行して API Gateway / ALB に連携します。
この記事では、Cognito の 仕組み・User Pool と Identity Pool の違い・典型構成・料金・選び方 を、「これから AWS で認証を組む人」 向けに整理します。OAuth 2.0 と OIDC の違い と併読すると、「なぜ Cognito の仕組みがこうなっているか」 が腑に落ちます。
まず役割を一言で
Cognito の 2 種類のプールを表で整理します。「どっち使うの?」 がここで決まります。
| 項目 | User Pool | Identity Pool (Federated Identities) |
|---|---|---|
| 主な目的 | ユーザー管理 + 認証(誰が誰か) | AWS リソースへの一時クレデンシャル発行(AWS API を直接叩く権限) |
| 発行するもの | JWT(ID トークン / アクセストークン) | AWS の 一時クレデンシャル(IAM Role の引き受け) |
| 典型用途 | Web / API へのログイン認証 | モバイル/ブラウザから S3 や DynamoDB を直接読み書き |
| 必要性 | 多くの Web/API でこれだけで足りる | 「AWS リソースに直接アクセスしたい」 時だけ追加 |
| OIDC 対応 | ○ User Pool 自体が OIDC IdP として動く | 外部 IdP(User Pool 含む)を信頼する仕組み |
「普通の Web アプリ」 なら User Pool だけ」 で十分なケースが多いです。「Identity Pool が要る」 のは モバイルアプリから直接 S3 へアップロードしたい のような特殊要件のときだけ、と理解すると混乱しません。
User Pool で提供される機能
User Pool は OIDC 対応のマネージドユーザーディレクトリ として、よくある認証機能を一通り提供します。
ユーザー登録とログイン
「 メール / 電話番号 / ユーザー名」 でのサインアップ、「メール / SMS の検証コード送付」、「パスワードポリシー(長さ・複雑度・履歴)」 をマネージドで提供。アプリは JWT を受け取って API に投げる だけで認証完了。
MFA とパスキー
「 SMS MFA / TOTP MFA / WebAuthn (パスキー)」 に対応。「MFA を必須化」 する設定だけで、OWASP Top 10 A07(認証の失敗) 対策の中心要素を実装できる。
典型構成: User Pool + API Gateway
「 Web フロント → API Gateway → Lambda」 の構成に Cognito User Pool を組み合わせるのが、AWS のサーバレス認証の定番です。
「User Pool + API Gateway + Lambda」 の組み合わせは、「認証ロジックをアプリ側で書かない」 を実現する典型パターンです。
Identity Pool が要るのはどんな時か
「 Identity Pool は要らないケースが多い」 と書きましたが、「要るケース」 もあるので整理します。
モバイルアプリから S3 へ直接アップロード
「 写真共有アプリ」 のように クライアントから直接 S3 にアップロードしたい 場合、Identity Pool が一時クレデンシャルを発行して 「そのユーザーのみが書き込めるパス」 に絞ったアクセスを許可する。
ブラウザから AppSync (GraphQL) を IAM 認証で叩く
「 AWS AppSync」 を IAM 認証モードで使う時、Identity Pool が ブラウザ用の一時クレデンシャル を発行。「複雑な permission モデル」 を IAM ポリシーで表現したい場合に。
未認証ユーザーにも限定的に AWS リソースを使わせる
「 ゲストユーザーが画像をアップロードできる」 のような匿名 + AWS 連携。Identity Pool の 未認証ロール で限定的な権限を渡す。
料金の考え方
Cognito の料金は 月間アクティブユーザー(MAU) 単位で、シンプルですが 機能ごとに別計算 があります。
| 項目 | 料金イメージ | 注意点 |
|---|---|---|
| 基本 MAU(User Pool) | 最初の 50,000 MAU まで無料、超過分は段階課金 | 無料枠は AWS アカウント単位 |
| アドバンスドセキュリティ | 「 MAU 単価に追加」 で、リスクベース認証 / 漏洩パスワード検出 などが有効化 | 無効でも基本的な認証は動く。本格運用なら推奨 |
| SMS MFA / OTP 配信 | Amazon SNS の SMS 料金が別途発生 | 国別 / 通信事業者で大きく違うので地域を絞る |
| Identity Pool | 無料(STS 経由の AssumeRole は AWS の通常料金) | 追加料金はかからない |
「小規模スタートアップ」 で 「MAU が数千〜数万」 規模なら、無料枠の範囲で運用できる ことも多いです。Auth0 / Okta と比べた時の 料金面の優位性 は Cognito の魅力の一つです。
Cognito を選ぶべきか — 他 IdP との比較
「Cognito 一択ではない」 ので、判断軸を整理します。
「AWS 中心のサーバレス」 なら Cognito、「複雑なエンタープライズ要件」 なら Auth0/Okta、「Firebase エコシステム」 なら Firebase Auth、と 主要技術スタックに合わせる のが選び方の本質です。
ハマりやすいポイント
実装で踏みやすい落とし穴を整理します。
User Pool ID / App Client ID の取り違え
「 User Pool ID」 と 「App Client ID(Audience)」 は別物。「同じ User Pool に複数の App Client を作って、Web / モバイル / 管理画面で使い分ける」 のが基本。アプリ側の設定で取り違えると JWT の aud 検証で失敗 する。
「 ID トークン」 は ユーザー識別用、「アクセストークン」 は API 呼び出し用。OIDC の原則 に従い使い分ける。「認証なら ID トークンの aud 検証、API 認可ならアクセストークンの scope 検証」 が正しい。
Cognito に関するよくある質問
Q. Auth0 と Cognito、どっち選ぶべき?
A. AWS 中心なら Cognito、それ以外なら Auth0 が基本。「料金面では Cognito の方が安い」 ことが多いですが、「管理 UI の成熟度・カスタマイズ性・エンタープライズ SSO 対応」 は Auth0 が上。小〜中規模スタートアップで AWS 中心 なら Cognito 一択でも問題なく、「B2B 大企業向けで複雑な要件」 なら Auth0 の学習投資に値します。
Q. User Pool だけで Identity Pool は本当に要らないですか?
A. 通常の Web/API では要らない が答え。「バックエンドが AWS リソースを叩く」 構成では、バックエンドの IAM ロールが直接 AWS を操作するので Identity Pool は不要。「 モバイル/ブラウザから直接 AWS リソースを触りたい」 ケースだけ Identity Pool を追加します。
Q. JWT の検証は API Gateway に任せれば自分で書かなくていい?
A. HTTP API の JWT Authorizer / REST API の Cognito Authorizer を使えば API Gateway 側で自動検証してくれます。「Lambda には検証済みのクレームだけ届く」 ので、アプリ側で JWT 検証コードを書く必要がない。Authorizer の設定で audience / issuer を正しく入れる ことだけ忘れずに。
Q. ソーシャルログイン(Google など)はどう設定する?
A. User Pool の Federation 設定で OIDC または OAuth 2.0 IdP を追加。Google なら Google Cloud Console で OAuth クライアントを作って、Client ID / Secret を Cognito に登録するだけ。ユーザーから見れば Google でログイン → Cognito の JWT 発行 → アプリにそのまま渡る 一貫した流れになります。
Q. パスキー(WebAuthn)は使えますか?
A. 使えます。Cognito User Pool は パスキー / WebAuthn をサポートし、「パスワードレス」 でも 「MFA の一手段としても」 利用可能。「フィッシング耐性 + ユーザビリティ」 を求める新規システムでは積極的に検討する価値があります。
Q. カスタム UI は作れますか?
A. 作れます。「Hosted UI(Cognito 提供のログイン画面)」 を使うのが最も楽ですが、「AWS SDK / Amplify Auth」 を直接呼んで 自前 UI を構築することも可能。「ブランドに合わせた UI が必要」 なら自前実装、「プロトタイプ」 や 「要件が薄い」 なら Hosted UI、と使い分けます。
Q. マルチテナント(SaaS のテナント分離)はどう設計しますか?
A. 1 User Pool + カスタム属性でテナント識別」 か `テナントごとに User Pool を分離 の 2 パターンあります。「小〜中規模・テナント数 100 以下」 なら User Pool 分離も現実的、「大規模・動的テナント追加」 なら 1 User Pool + 「custom:tenant_id」 属性 + Pre Token Generation でクレーム付与、が定番です。
まとめ
AWS Cognito は AWS が用意した OIDC 対応のマネージド IdP として、「認証の標準機能を一通り低コストで使える」 サービスです。User Pool(認証) + Identity Pool(AWS 直接認可) という構成を分けて理解すれば、「どちらを使うか」 の迷いが消えます。
「AWS 中心のスタックで小〜中規模」 なら Cognito から始めるのがコスパ良好。「複雑な要件 / カスタマイズ重視」 なら Auth0 / Okta も検討。「OAuth 2.0 / OIDC の理解 + OWASP Top 10 A07 対策 + マネージド IdP」 のセットが、現代的な認証実装の標準ラインです。
参考リンク
- AWS: Amazon Cognito
- AWS Docs: Amazon Cognito Developer Guide
- AWS: Cognito Pricing
- AWS Docs: User Pool vs Identity Pool
- AWS Blog: Cognito user pool passkey support