Amazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説【2026年10月】

Amazon Cognito（コグニート）は、Amazon Web Services（AWS）が提供する認証・ユーザー管理サービスです。Web／モバイルアプリのサインアップ・サインイン・アクセス制御を、自前で実装せずに組み込めます。分類としてはCIAM（カスタマーアイデンティティ＆アクセス管理）にあたり、多要素認証（MFA）、ソーシャルログイン、パスキーによるパスワードレス認証を標準で持っています。

この記事では、読み方と名前の由来から、できること・料金・使い方、混同しやすいIAMやIAM Identity Center（旧AWS SSO）との違いまでを順に整理します。料金は東京リージョンの単価で月額を試算し、使い方はAWS CLIでユーザープールを作ってログインし、発行されたトークンを検証するところまでコードで示します。後半では、既定値のまま作ると穴になる設定と、2025〜2026年に入った変更点もまとめました。数値と仕様は2026年10月22日時点のAWS公式情報で確認しています。

まとめ：Amazon Cognitoの要点と料金・使い方の結論（2026年10月時点）

• Amazon Cognito（コグニート）は、アプリのユーザー認証を任せるためのAWSのCIAMサービスです。中核はユーザープール（認証）とIDプール（AWSリソースへの認可）の2つです。
• ユーザープールはLite／Essentials／Plusの3つの機能プランから選び、新規作成時の既定はEssentialsです。
• 課金はMAU（その月に認証などの操作があったユーザー数）単位です。東京リージョンでは、LiteとEssentialsが月10,000MAUまで無料で、超過分はEssentialsが1MAUあたり0.015ドル、Plusは無料枠なしで0.020ドルです（2026年10月20日公開の価格表）。
• IAMはAWSを操作する人とサービスの権限、IAM Identity Centerは社員のシングルサインオン、Cognitoはアプリの顧客のログイン、と対象が分かれます。
• サインインに使う属性（メールアドレスか電話番号か）と必須属性は、ユーザープール作成後に変更できません。
• CLIやAPIで作るアプリクライアントは、ユーザーの存在を示すエラーの抑止が既定で無効（LEGACY）で、属性の書き込み権限も広く付きます。本番では作成時に明示して閉じます。
• AWS中心の構成で、標準的な会員ログインを早く安く用意したいなら有力な選択肢です。AWS外のシステムが主体の場合や、法人顧客ごとのテナント管理を画面込みで求める場合は、ほかのIDaaSも比較してから決めます。

Amazon Cognito（コグニート）の読み方と名称の由来、cognitの綴り

Amazon Cognitoの読み方は「コグニート」です。英語の発音は「カグニートウ」に近いものの、日本語の現場では「コグニート」と呼ばれます。

AWSは名称の由来を公式には説明していません。語としては、イタリア語の cognito（既知の）が近く、Wiktionaryではラテン語の cognitus（知られた。動詞 cognōscō＝知るようになる、の過去分詞）から来た語とされています。英語の cognition（認知）、recognize（認識する）、incognito（身元を隠して）も同じ語根の語です。「利用者を見分けて本人だと確かめる」というサービスの役割と重ねて覚えると、名前と機能が結び付きます。綴りは c-o-g-n-i-t-o で、「cognit」「congito」のように途中まで、または入れ替えて入力した場合も、AWSの認証サービスを探しているならこのCognitoが該当します。

Amazon Cognitoでできること：サインアップからパスキー・M2M認証まで

Cognitoが担うのは、アプリの「ユーザー認証まわり」をまとめて肩代わりすることです。代表的な機能は次のとおりで、どの機能プランで使えるかはAWS公式の機能プラン一覧に整理されています。

• サインアップ／サインイン：会員登録、ログイン、パスワードリセットなどの基本機能です。
• 多要素認証（MFA）：SMSと認証アプリ（TOTP）は全プランで使えます。メールのワンタイムコードによるMFAはEssentials以上です。
• ソーシャル／外部IdP連携：Google・Apple・Facebookなどのソーシャルログインと、SAML／OIDCの外部IDプロバイダーに対応します。
• パスワードレス認証：パスキー（FIDO2）と、メール・SMSのワンタイムコードによるログインに対応します。いずれもEssentials以上です。
• マネージドログイン：AWSがホストするログイン画面を、コンソールのビジュアルエディターでブランドに合わせて調整できます（Essentials以上）。Liteで使えるのは、カスタマイズ範囲の狭い従来のホストUIです。
• M2M（マシン間）認証：OAuth 2.0のクライアントクレデンシャルフローで、人ではないシステム同士の通信用にアクセストークンを発行します。2026年8月からは、ユーザープールのドメインを設定せずに GetClientToken APIでトークンを取る方法も加わりました。
• AWSリソースへのアクセス制御：認証済みユーザーに、S3やDynamoDBなどへの一時的なアクセス権を発行します。

これらを自前で実装するには、パスワードの安全な保存、ブルートフォース対策、トークンの署名と失効まで設計する必要があります。MFA・SSO・OIDCといった用語の関係を先に押さえたい場合は、認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】で全体像を確認できます。

ユーザープールとIDプールの違い：認証とAWSリソースへの認可

Cognitoを理解するうえで最初に押さえるのが、ユーザープールとIDプール（アイデンティティプール）という2つのコンポーネントです。

ユーザープールが「ログインの入口」、IDプールが「ログイン後にAWSの中で何をしてよいかを決める部分」です。IDプールの公式ドキュメントによると、IDプールはサインイン前のゲストにも狭い権限の一時認証情報を出せ、ユーザープールのトークンやSAMLアサーション、ソーシャルログインのトークンをAWSの認証情報に交換します。APIをAPI Gateway経由で公開し、バックエンドでトークンを検証する構成なら、ユーザープールだけで足ります。IDプールが要るのは、ブラウザやスマホからS3やDynamoDBを直接呼ばせるときです。手順はCognito IDプールの実装手順：一時認証情報の発行とロール選択・ユーザープールとの違いで解説しています。

ユーザープールが発行するIDトークンとアクセストークンはJWT形式です。トークンの構造と署名検証の考え方はJWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説で、IDトークンの位置づけはOIDC（OpenID Connect）とは？IDトークンの検証手順とOAuth 2.0との違いを解説で扱っています。

Amazon Cognitoの料金体系：Lite・Essentials・Plusの東京単価

Cognitoの課金は、原則としてMAU（月間アクティブユーザー）に対して発生します。アカウントを持っているだけのユーザーではなく、その月にサインインなどの操作があったユーザーが対象です。

ユーザープールの機能プランはLite／Essentials／Plusの3つで、新規に作成するユーザープールはEssentialsが既定です。プランはユーザープールごとに切り替えられます。ただし、下位プランで使えない機能を有効にしている場合は、先にその機能を無効化する必要があります。

EssentialsではLiteの機能に加えて、メールMFA、パスワードレスのワンタイムコード、アクセストークンへのクレーム追加が使えます。Plusはさらに、漏えい済みパスワードの検出や不審なサインインの判定（リスクベース認証）、ユーザー操作ログの外部出力を加えたプランです。以前「高度なセキュリティ機能（Advanced Security Features）」と呼ばれていた機能は、今はPlusの脅威保護に入っています。

単価はAmazon Cognitoの料金ページに掲載されています。東京リージョン（ap-northeast-1）の単価を、AWSの価格表API（Price List APIのAmazonCognito、2026年10月20日公開分）で確認した値は次のとおりです。

Liteは段階制で、10万MAUを超えると100万MAUまでが0.0046ドル、その先はさらに下がります。無料枠はAWSアカウント（またはAWS Organizations）単位で、12か月の無料利用期間が終わっても失効しません。M2M認証はMAUではなく、成功したトークン発行1件ごとの課金です（東京で25万件まで1件0.00225ドル）。2025年11月にM2Mのアプリクライアント単位の課金は廃止され、今はトークン発行数だけで決まります。SMSやメールの送信料は、SNS・SESの料金として別にかかります。

東京リージョンで試算する：1万・5万・10万MAUの月額目安

上の単価をもとに、ユーザーが直接（またはソーシャルログインで）サインインする場合の月額を計算すると次のようになります。税金と為替、SMS・メールの送信料は含めていません。なお、2024年11月22日（米国太平洋時間午前10時）より前から使っている顧客は、条件を満たせばLiteの無料枠が50,000MAUのまま続くと料金ページに記載があり、下の表はこの例外を含めない新規の試算です。

5万MAUのEssentialsは、無料枠を引いた40,000MAUに0.015ドルを掛けて600ドルです。Plusは無料枠が無いため、1万MAUでも200ドルかかります。パスキーやマネージドログインが不要ならLiteで抑えられ、不正ログイン対策が要件に入った時点でPlusとの差額を見積もる、という順で比べると決めやすくなります。単価は改定されることがあるため、見積もりの前に料金ページかAWS Pricing Calculatorで最新値を確認してください。

MAUに数えられる操作と数えられない操作：請求が膨らむ原因

Cognitoのクォータの公式ドキュメントでは、その月に次の操作が1回でもあったユーザーをMAUとして数えると定めています。

• サインアップ、または管理者によるユーザー作成（CSVでのユーザー一括インポートは数えない）
• アカウント確認・属性の検証、サインインとチャレンジ応答、サインアウトとトークン失効
• パスワードのセルフリセット、管理者によるパスワード設定（管理者によるリセット要求 AdminResetUserPassword は数えない）、属性やグループ所属の変更
• 管理者によるユーザー詳細の取得（AdminGetUser）

見落としやすいのが最後の項目です。バッチ処理で全ユーザーをAdminGetUserで1件ずつ読むと、その月にログインしていないユーザーまでMAUになります。公式ドキュメントが示す回避策は、一覧の取得にMAUに数えられないListUsersを使うか、ユーザー情報を外部のデータベースに持つことです。月の途中で機能プランを切り替えた場合は、各ユーザーがアクティブだった時点のうち最も高いプランで課金されます。

マルチリージョン複製とAPIレート上限引き上げの追加料金

MAUとは別に請求されるオプションが2つあります。1つは2026年6月に始まったマルチリージョン複製（MRR）で、ユーザーと設定を別リージョンの複製プールへほぼリアルタイムで同期し、障害時にサインインとトークン発行を引き継がせます。EssentialsかPlusのアドオンで、東京の価格表では1MAUあたりEssentialsが0.0045ドル、Plusが0.006ドル上乗せされます。複製先ではユーザーの新規作成とパスワードリセットができず、TOTPのMFAも使えないため、障害時はこれらの画面を止める前提で設計します。マルチリージョンKMSキーの用意も前提条件です。

もう1つはAPIの秒間リクエスト数（RPS）の追加です。サインイン系（UserAuthentication）の既定は120RPSで、超える分は有料で増やします。2026年7月からは、承認済みのアカウント上限内で、コンソールやAPIから適用レートを即時に増減できるようになりました。アカウント上限自体の引き上げには、引き続きService Quotasでの申請が必要です。東京の価格表では、追加1RPSあたり月20ドルの区分（full month）と、月45ドルの区分（partial month）があります。月の途中から短期間だけ増やす場合は後者で見積もります。テレビCMや一斉配信でログインが集中する予定があるなら、事前にこの費用も見込みます。

IAM・IAM Identity Center（旧AWS SSO）との違いと使い分けの境界

「Cognito」「IAM」「IAM Identity Center」はいずれもAWSの認証・アクセス管理に関わるため混同されがちですが、対象とする利用者が異なります。

IAMは「AWSを操作する人やサービスの権限」を管理する仕組みで、アプリの一般ユーザーを登録する用途には使いません。ユーザー・ロール・ポリシーの関係はAWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説で整理しています。IAM Identity Centerは2022年7月にAWS Single Sign-On（AWS SSO）から名称変更されたサービスで、IAM Identity Centerの公式ガイドのとおり、社員が複数のAWSアカウントや業務アプリへ1回のログインでアクセスするための社内向けSSO基盤です。権限セットの設計はAWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説で扱っています。

アプリの会員機能を作るならCognito、社内のAWS権限管理ならIAM、従業員の業務アプリのSSOならIAM Identity Centerです。Cognitoでエンドユーザーを認証し、IDプール経由でIAMロールを割り当てる、という組み合わせもよく使われます。

Amazon Cognitoの使い方：AWS CLIでユーザープール作成からログインまで

導入の流れは、(1) ユーザープールを作る、(2) アプリクライアントを登録する、(3) アプリにサインアップ・サインインを組み込む、(4) 発行されたトークンをバックエンドで検証する、の4段階です。コンソールでも同じ設定ができますが、再現しやすいようにAWS CLI（v2）で(1)から(3)までを通します。使うコマンドはcreate-user-pool、create-user-pool-client、sign-up、initiate-authの4つです。bashで実行する前提です。

# 前提: AWS CLI v2と、プール・クライアントの作成、ユーザーの管理者確認、プール削除を許可したAWS認証情報を用意する
# 0. 検証用の変数（メールアドレスは確認コードを受け取れる実在のものを入力する）
export AWS_REGION=ap-northeast-1
read -r -p "メールアドレス: " EMAIL
export PASSWORD='Passw0rd!Example'

# 1. メールアドレスでサインインするユーザープールを作成（機能プランはEssentials）
POOL_ID=$(aws cognito-idp create-user-pool \
  --pool-name demo-users \
  --username-attributes email \
  --auto-verified-attributes email \
  --user-pool-tier ESSENTIALS \
  --query UserPool.Id --output text)
echo "$POOL_ID"

# 2. アプリクライアントを作成（シークレットなし）
#    ユーザー存在エラーを隠し、読み書きできる属性を明示する
CLIENT_ID=$(aws cognito-idp create-user-pool-client \
  --user-pool-id "$POOL_ID" \
  --client-name demo-web \
  --no-generate-secret \
  --explicit-auth-flows ALLOW_USER_PASSWORD_AUTH ALLOW_REFRESH_TOKEN_AUTH \
  --prevent-user-existence-errors ENABLED \
  --read-attributes email email_verified name \
  --write-attributes email name \
  --query UserPoolClient.ClientId --output text)

# 3. テストユーザーを登録し、検証用に管理者権限で確認済みにする
aws cognito-idp sign-up --client-id "$CLIENT_ID" \
  --username "$EMAIL" --password "$PASSWORD"
aws cognito-idp admin-confirm-sign-up --user-pool-id "$POOL_ID" --username "$EMAIL"

# 4. ログインしてアクセストークンを取得
ACCESS_TOKEN=$(aws cognito-idp initiate-auth \
  --client-id "$CLIENT_ID" \
  --auth-flow USER_PASSWORD_AUTH \
  --auth-parameters USERNAME="$EMAIL",PASSWORD="$PASSWORD" \
  --query AuthenticationResult.AccessToken --output text)
echo "${ACCESS_TOKEN:0:40}..."

手順1の --username-attributes email が、後から変更できない「サインイン属性」の指定です。--user-pool-tier を省略するとEssentialsになります。手順2の --prevent-user-existence-errors から下の3行は、省略すると安全側にならない設定で、理由は後の章で説明します。ALLOW_USER_PASSWORD_AUTH はパスワードをそのままCognitoへ送る検証向けのフローで、ブラウザやスマホのアプリではSRPかマネージドログインを使います。手順3の admin-confirm-sign-up は確認コードの入力を省くための操作で、本番では利用者自身がメールの確認コードを入力します。終わったら aws cognito-idp delete-user-pool --user-pool-id "$POOL_ID" で片付けます。

コンソールでの操作、マネージドログインを使うOAuthのフロー、本番向けの設定値まで追う場合はCognitoで認証基盤を実装する手順：ユーザープール作成からaws-jwt-verifyでのJWT検証までで順を追って解説しています。ログイン画面の見た目と日本語化はAWS Cognito Hosted UI（マネージドログイン）のカスタマイズ・日本語化と設定手順を参照してください。

Node.jsのaws-jwt-verifyによるJWT検証

手順4で取得したアクセストークンは、APIを受けるバックエンドで必ず検証します。JWT検証の公式ドキュメントが求める確認は、署名（ユーザープールの公開鍵JWKSとの照合）、有効期限、発行元（iss）、用途（token_use）、クライアントIDの5点です。公開鍵は https://cognito-idp.<region>.amazonaws.com/<userPoolId>/.well-known/jwks.json で公開されています。

Node.jsなら、AWSが公開しているaws-jwt-verifyでこの5点をまとめて確認できます。npmの最新は5.2.1（2026年6月5日公開）で、Node.js 18以上で動きます。JWKSは初回に取得してキャッシュし、未知の鍵IDが来たときだけ取り直します。

// verify.mjs（事前に npm install aws-jwt-verify）
import { CognitoJwtVerifier } from "aws-jwt-verify";

const verifier = CognitoJwtVerifier.create({
  userPoolId: process.env.POOL_ID,   // 例: ap-northeast-1_XXXXXXXXX
  tokenUse: "access",                // IDトークンを検証するなら "id"
  clientId: process.env.CLIENT_ID,
});

try {
  const payload = await verifier.verify(process.argv[2]);
  console.log("valid:", payload.sub, payload.client_id, payload.exp);
} catch (err) {
  console.error("invalid:", err.message);
  process.exit(1);
}

CLIの続きで POOL_ID="$POOL_ID" CLIENT_ID="$CLIENT_ID" node verify.mjs "$ACCESS_TOKEN" と実行すると、正しいトークンでは valid: とユーザーの sub が表示されます。署名検証の失敗を試すには、JWTの3番目の部分（署名）の先頭1文字を、別のBase64url文字に変更して渡します。署名のバイト列が変わるため検証に失敗し、終了コード1になります。ユーザーを識別するキーには、メールアドレスではなく変わらない値の sub を使ってください。メールアドレスは利用者が後から変えられる属性です。

既定値のままだと危ない設定：自己サインアップ・属性の書き込み・トークン失効

Cognitoはコンソールで作るときと、CLI・API・IaCで作るときで既定値が違います。入門記事の手順どおりにCLIで作ると、次の4点が開いたままになりやすいので、作成時に決めておきます。

自己サインアップ：クライアントIDによる公開登録と制限設定

ユーザープールの AdminCreateUserConfig にある AllowAdminCreateUserOnly が false だと、APIリファレンスのとおり利用者がSignUp操作で自分のアカウントを作れます。上のCLI手順でsign-upが通ったのはこのためです。SPAやスマホアプリではクライアントIDが利用者の手元に渡るので、画面に登録ボタンが無くてもAPIを直接呼べば登録できます。社内向けや招待制のアプリでは、作成時に --admin-create-user-config AllowAdminCreateUserOnly=true を付けて管理者作成だけにします。

属性の書き込み権限：利用者による更新範囲の制限

アクセストークンを持つ利用者は、UpdateUserAttributes で自分の属性を更新できます。どの属性を書けるかはアプリクライアントの WriteAttributes で決まり、指定しないと広い範囲が書き込み可能になります。開発者ガイドの属性の章は「未指定なら標準属性とカスタム属性のすべてに書き込み権限」と書き、APIリファレンスは「標準属性」と書いていて、記述が揃っていません。どちらの読みでも、custom:plan や custom:role のように権限判定に使う属性を利用者に書かせない設定は、明示しない限り保証されません。権限に関わる値はグループかサーバー側のデータベースに置き、--write-attributes で書ける属性を列挙します。

既存のアプリクライアントを確かめるには aws cognito-idp describe-user-pool-client を使います。WriteAttributes は既定のままだと応答に含まれないので、項目が空なら既定の広い権限だと読めます。直すときの update-user-pool-client は、指定しなかった項目を既定値に戻す仕様です。describeの応答から更新APIが受け付ける設定項目を取り出し、現在値を維持したうえで、変えたい項目だけを書き換えて渡します。作成日時などの応答専用項目は除外します。

ユーザー存在エラー：登録済みメールアドレスの推測対策

ユーザー存在エラーの公式ドキュメントによると、APIで作ったアプリクライアントの PreventUserExistenceErrors は既定で LEGACY（抑止しない設定）で、コンソールで作ると ENABLED が選ばれます。LEGACYのままだと、存在しないユーザー名でサインインしたときに UserNotFoundException が返り、メールアドレスが会員かどうかを外部から調べられます。ENABLEDにすると、存在しない場合もパスワード誤りと同じエラーになり、パスワード再設定では架空の送信先へコードを送ったという応答になります。

サインアウト後のトークン：ローカル検証における失効確認の限界

GlobalSignOut や RevokeToken でトークンを失効させても、トークン失効の公式ドキュメントのとおり、署名と有効期限だけを見るJWTライブラリでは期限まで有効と判定されます。前章のaws-jwt-verifyもオフラインで検証するので、失効は検出しません。アクセストークンとIDトークンの既定の有効期限は1時間、リフレッシュトークンは30日で、前の2つは5分から1日の範囲で変えられます。期限を短くすると、失効が効くまでの時間を縮められるだけです。退会や強制ログアウトを即時に反映させたいAPIでは、サーバー側で利用者の状態を持ってリクエストごとに確かめるか、重要な操作の前にそのアクセストークンで GetUser を呼びます。aws.cognito.signin.user.admin スコープを含むアクセストークンなら、GlobalSignOutのAPIリファレンスのとおり、失効済みのものはCognitoのAPIが拒否します。ログイン試行回数の上限やパスワード再設定の設計はCognitoのパスワードリセット実装：ForgotPasswordと管理者リセット・ロックアウト設計で扱っています。

API Gateway・Lambdaトリガーとの連携によるAPI認可と認証フローの制御

CognitoはAWSのほかのサービスと組み合わせたときに手間が減ります。よく使われるのは次の2つです。

• API Gatewayのオーソライザー連携：REST APIでは COGNITO_USER_POOLS 型のオーソライザーをメソッドに設定すると、有効なトークンを Authorization ヘッダーで送ったリクエストだけがAPIに届きます。API Gatewayの公式ドキュメントでは、IDトークンは属性に基づく認可に、アクセストークンはカスタムスコープに基づく認可に使うと整理されています。HTTP APIではJWTオーソライザーにユーザープールの発行元を設定します。使い分けはAPI Gatewayの認証：Cognito・JWT・Lambdaオーソライザー・IAM認可の使い分けと設定例にまとめています。
• Lambdaトリガーによる認証フローのカスタマイズ：サインアップ前の入力検証（pre sign-up）、確認後のDB登録（post confirmation）、トークン発行前のクレーム追加（pre token generation）、確認メールの文面差し替え（custom message）などをAWS Lambdaで差し込めます。一覧はLambdaトリガーの公式ドキュメントにあります。アクセストークンへのクレーム追加はEssentials以上、IDトークンへの追加は全プランで使えます。

「このユーザーはこの請求書を見てよいか」といったリソース単位の認可まで外に出したい場合は、Cedarでポリシーを書くAmazon Verified Permissionsとは？Cedarの書き方と料金・API Gateway連携の手順と組み合わせる構成もあります。

2025〜2026年のAmazon Cognitoの主な変更点

Cognitoは2024年11月の機能プラン導入のあとも機能追加が続いています。AWSの新着情報に載った主な発表を、日付順に並べました。古い解説記事の前提と食い違うのは主にこの範囲です。

実務への影響が大きいのは3つです。パスワードハッシュの取り込みで、bcrypt・scrypt・Argon2id・PBKDF2-SHA256のハッシュを持つ既存会員は、移行後も再設定なしでログインできるようになりました。TOTPのリセット（AdminDeleteSoftwareToken）は、認証アプリの端末を失った利用者のためにアカウントを作り直す運用を不要にします。GetClientTokenはAWS SDKから直接M2Mトークンを取れるため、サーバー間連携のためだけにドメインを用意する必要がなくなりました。MFAの設定手順はCognito MFAの設定手順：TOTP・SMS・メールの有効化と必須化の判断で、パスキーはCognitoのパスキー実装手順：WebAuthnサインインの有効化とSDKでの登録・認証で扱っています。

Amazon Cognitoの用途とAuth0・Firebase Authとの比較

Cognitoが向いているのは、次のようなケースです。

• B2C向けWeb／モバイルアプリ：ECサイトや会員制サービスで、サインアップ・ログインを短期間で用意したい場合。
• 外部IdPと連携する業務アプリ：取引先や社員のSAML・OIDCのIDで入らせたい場合。SAML・OIDC連携のユーザーは無料枠が50MAUと小さい点に注意します。
• 不正ログイン対策が要件にあるアプリ：MFAとPlusの脅威保護を組み合わせ、漏えいパスワードや不審なサインインを止めたい場合。

同じ役割の認証サービスとして、Auth0・Keycloak・Firebase Authenticationがよく比較されます。CognitoはIDプールやAPI Gatewayの認証設定と連携でき、Lambdaトリガーで認証処理を拡張できます。費用は、必要な機能プランと認証方式、MAU、周辺サービスの料金をそろえて比較します。一方で、ログイン画面の作り込み、法人顧客ごとの組織管理、管理画面の使い勝手は、IDaaS専業の製品のほうが厚い傾向があります。製品ごとの違いはKeycloakとは？Oktaとの違いと連携手順｜Auth0・Cognito比較で導入を判断【2026年10月】とFirebase Authenticationとは？料金・認証方式・導入手順とMFA・IDトークン検証【2026年10月】で比べられます。

Amazon Cognito導入時の注意点：作成後に変えられない設定とクォータ

手軽に始められる一方で、後から変えられない設定があります。

• サインイン属性は最初に決める：メールアドレス・電話番号・ユーザー名のどれをサインインIDにするかは、ユーザー属性の公式ドキュメントのとおり作成後に変更できません。必須属性の指定も同様です。
• カスタム属性は消せない：カスタム属性は1プールあたり50個までで、追加後は削除も名前・型の変更もできません。頻繁に変わる値（ポイント残高など）は属性に入れず、DynamoDBなど別のデータストアに置きます。
• クォータを確認する：既定では1リージョンあたりユーザープール1,000個、1プールあたりアプリクライアント1,000個、ユーザー4,000万人が上限です。APIのリクエスト数は操作の種類ごとに上限があり、前述のとおり追加分は有料です。
• リージョンを決める：ユーザープールはリージョン単位のリソースで、東京（ap-northeast-1）と大阪（ap-northeast-3）のどちらでも作れます。障害時の切り替えまで求めるなら、最初からEssentials以上でMRRを前提にします。

Cognitoを採用する条件と見送る場面：受託開発での判断基準

採用してよい条件は、(1) アプリのバックエンドがAWS上にあり、API GatewayやLambda、S3と組み合わせる、(2) 要件がメール・ソーシャルログイン・MFA・パスキーといった標準的な会員ログインで足りる、(3) 会員数が数万〜数十万MAUで、1MAUあたりの単価を抑えたい、がそろう場合です。この条件ならCognitoを第一候補にします。認証の基本機能を自作する範囲を減らせるためです。最終判断では、属性権限やトークン失効の設計と、周辺サービスを含む総費用を確認します。

見送るか比較を厚くすべき場面は、(1) 主なシステムがAWSの外にあり、Cognitoのためだけにアカウントを運用することになる、(2) 法人顧客ごとの組織・ロール管理や招待フローなど、B2B向けのテナント機能を画面込みで求める、(3) 将来ほかの認証基盤へ移る可能性が高い、のいずれかに当てはまる場合です。(3)について補足すると、ListUsersなどの管理APIはパスワードのハッシュを返しません。移行先ではパスワードの再設定か、ログインのたびに旧基盤で確かめて移すジャストインタイム移行を用意する前提になります。

既存の会員データベースからCognitoへ移す道は、CSVインポートの公式ドキュメントのとおり3つです。パスワードを含まないCSVインポートでは、利用者は初回ログイン時にパスワードを再設定します。前述のハッシュ取り込みなら再設定は不要です。ハッシュの形式が合わない場合は、Lambdaトリガーで旧システムに照会するジャストインタイム移行を組みます。CSVインポート自体はMAUに数えられませんが、移行後のパスワード再設定はMAUになるため、試算に含めます。どの移し方が会員規模と運用に合うかの判断や、Cognitoか他製品かの選定から実装までを任せたい場合は、一創の認証基盤・ID管理システム開発でご相談いただけます。

よくある質問

Q. Amazon Cognitoの読み方と名前の由来は？

「コグニート」と読みます。AWSは由来を公式に説明していませんが、イタリア語の cognito（既知の）と同じ綴りで、この語はラテン語の cognitus（知られた）から来ています。英語の cognition（認知）や recognize（認識する）とも語根が同じです。綴りは c-o-g-n-i-t-o です。

Q. Amazon Cognitoの料金はいくらですか？無料で使えますか？

LiteとEssentialsは、直接サインインとソーシャルログインのユーザーについて月10,000MAUまで無料です。超過分は東京リージョンでEssentialsが1MAUあたり0.015ドル、Liteが0.0055ドルです。Plusには無料枠がなく0.020ドル、SAML・OIDCで連携するユーザーの無料枠は50MAUです。IDプールは料金がかかりません。最新値はAWS公式の料金ページで確認してください。

Q. CognitoとIAM・IAM Identity Center（旧AWS SSO）の違いは？

Cognitoはアプリのエンドユーザー（顧客）の認証、IAMはAWSを操作する開発者・運用者・サービスの権限管理です。IAM Identity Centerは、社員が複数のAWSアカウントや業務アプリへ1回のログインで入るためのシングルサインオン基盤です。アプリの会員機能を作るならCognitoを選びます。

Q. ユーザープールとIDプールの違いは何ですか？両方必要ですか？

ユーザープールはログインしてトークンを発行する認証の部分、IDプールはトークンをAWSの一時認証情報に交換する認可の部分です。APIをAPI Gateway経由で公開してバックエンドでトークンを検証する構成なら、ユーザープールだけで足ります。ブラウザやスマホからS3やDynamoDBを直接呼ばせる場合にIDプールを加えます。

Q. CognitoはAuth0やFirebase Authenticationとどう違いますか？

いずれもアプリの認証を担うサービスです。CognitoはIDプールやAPI Gatewayの認証設定と連携でき、Lambdaトリガーで認証処理を拡張できます。費用は必要な機能と認証方式をそろえて比較します。ログイン画面の作り込みや、法人顧客ごとのテナント管理を重視するならAuth0なども比較します。

関連記事

• Cognitoで認証基盤を実装する手順：ユーザープール作成からaws-jwt-verifyでのJWT検証まで
• AWS Cognito Hosted UI（マネージドログイン）のカスタマイズ・日本語化と設定手順
• Cognito IDプールの実装手順：一時認証情報の発行とロール選択・ユーザープールとの違い
• API Gatewayの認証：Cognito・JWT・Lambdaオーソライザー・IAM認可の使い分けと設定例
• AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説