---
title: "Amazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/3108/"
published: 2024-07-19
updated: 2026-10-20
categories: ["AWS"]
publisher: "株式会社一創"
---

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

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

この記事では、読み方と意味から、できること・料金・使い方、混同しやすいIAMやIAM Identity Center（旧AWS SSO）との違いまでを、初心者にもわかる順序で整理します。料金は東京リージョンの単価で月額を試算し、使い方はAWS CLIでユーザープールを作ってログインし、発行されたトークンを検証するところまでコードで示します。数値と仕様の確認に用いた出典は、2026年10月10日時点のAWS公式情報です。

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

- Amazon Cognito（コグニート）は、アプリのユーザー認証を安全に短時間で実装するためのAWSのCIAMサービスです。中核はユーザープール（認証）とIDプール（AWSリソースへの認可）の2つです。
- 2024年11月以降、ユーザープールはLite／Essentials／Plusの3つの機能プランから選ぶ形になり、新規作成時の既定はEssentialsです。
- 課金はMAU（その月に認証などの操作があったユーザー数）単位です。東京リージョンでは、Essentialsが月10,000MAUまで無料で超過分は1MAUあたり0.015ドル、Plusは無料枠なしで0.020ドルです（2026年9月25日公開の価格表）。
- IAMはAWSを操作する人とサービスの権限、IAM Identity Centerは社員のシングルサインオン、Cognitoはアプリの顧客のログイン、と対象が分かれます。
- サインインに使う属性（メールアドレスか電話番号か）と必須属性は、ユーザープール作成後に変更できません。最初に決めてから作ります。
- AWS中心の構成で、標準的な会員ログインを早く安く用意したいなら有力な選択肢です。AWS外のシステムが主体の場合や、組織単位の複雑なテナント管理が要る場合は、ほかのIDaaSも比較してから決めます。

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

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

名称はラテン語の `cognitio`（認知・知ること）に由来します。「ユーザーを認識し、本人であることを確認する」という認証サービスの役割を、そのまま名前に込めたものです。綴りは c-o-g-n-i-t-o で、「cognit」と途中まで入力して調べている場合も、AWSの認証サービスを探しているならこのCognitoが該当します。まずは「コグニート＝AWSの認証サービス」と覚えておけば十分です。

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

Cognitoが担うのは、アプリの「ユーザー認証まわり」をまるごと肩代わりすることです。代表的な機能は次のとおりで、どの機能プランで使えるかは[AWS公式の機能プラン一覧](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-sign-in-feature-plans.html)に整理されています。

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

これらを自前で実装する場合には、相応の工数とセキュリティ知識が必要です。Cognitoなら設定とSDK連携で実現でき、開発者はアプリ本来の機能に時間を回せます。MFA・SSO・OIDCといった用語の関係を先に押さえたい場合は、[認証・ID管理とは？MFA・SSO・OIDC・IDaaSの違いと選定を解説【2026年版】](https://www.issoh.co.jp/column/details/13631/)で全体像を確認できます。

## ユーザープールとIDプールの違い：認証と認可のどちらを担うかで分ける

Cognitoを理解するうえで最初に押さえるのが、**ユーザープール**と**IDプール（アイデンティティプール）**という2つのコンポーネントです。役割がはっきり分かれているため、まずは下の表で整理します。

| 項目     | ユーザープール          | IDプール              |
| ------ | ---------------- | ------------------ |
| 主な役割   | ユーザーの認証（誰かを確かめる） | AWSリソースへの認可（権限を渡す） |
| 扱うもの   | ユーザー情報・パスワード・MFA | 一時的なAWSクレデンシャル     |
| 発行するもの | IDトークン／アクセストークン  | IAMロールに基づく一時認証情報   |
| 代表的な用途 | アプリのログイン基盤       | S3アップロードなどの権限付与    |
| 料金     | MAU単位の従量課金       | 無料（料金ページに明記）       |

ざっくり言えば、ユーザープールが「ログインの入口」、IDプールが「ログイン後にAWSの中で何をしてよいかを決める部分」です。[IDプールの公式ドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-identity.html)によると、IDプールはサインイン前のゲストにも狭い権限の一時認証情報を出せ、ユーザープールのトークンやSAMLアサーション、ソーシャルログインのトークンをAWSの認証情報に交換します。多くのアプリではユーザープールだけで認証機能の要件を満たせる構成です。認証済みユーザーにS3やDynamoDBへ直接アクセスさせたい場合に、ユーザープールとIDプールを組み合わせます。IDプールの実装手順は[Cognito IDプールの実装手順：一時認証情報の発行とロール選択・ユーザープールとの違い](https://www.issoh.co.jp/tech/details/18520/)で解説しています。

ユーザープールが発行するIDトークンとアクセストークンはJWT形式です。トークンの構造や署名検証の考え方は[JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説](https://www.issoh.co.jp/tech/details/13453/)で、IDトークンの位置づけは[OIDC（OpenID Connect）とは？IDトークンの検証手順とOAuth 2.0との違いを解説](https://www.issoh.co.jp/tech/details/6532/)で詳しく扱っています。

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

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

2024年11月から、ユーザープールに**Lite／Essentials／Plus**の3つの機能プラン（ティア）が導入されました。新規に作成するユーザープールは**Essentialsが既定**で、プランはユーザープールごとにいつでも切り替えられます。機能の違いは次のとおりです。

| ティア        | 位置づけ       | 主な機能                     |
| ---------- | ---------- | ------------------------ |
| Lite       | 従来相当の基本プラン | サインイン、SMS・TOTPのMFA、外部IdP |
| Essentials | 新規作成時の既定   | Lite＋マネージドログイン、パスキー等     |
| Plus       | 高セキュリティ向け  | Essentials＋脅威保護、ログ出力     |

EssentialsではLiteの機能に加えて、メールMFA、パスワードレスのワンタイムコード、アクセストークンのクレーム追加が使えます。Plusはさらに、漏えい済みパスワードの検出や不審なサインインの判定（リスクベース認証）、ユーザー操作ログの外部出力を加えたプランです。

単価は[Amazon Cognitoの料金ページ](https://aws.amazon.com/cognito/pricing/)に掲載されており、リージョンの選択で表示が変わります。東京リージョン（ap-northeast-1）の単価を、AWSの価格表API（Price List API、2026年9月25日公開分）で確認した値は次のとおりです。

| 区分          | 無料枠（月）    | 超過分の単価（1MAU）       |
| ----------- | --------- | ------------------ |
| Lite        | 10,000MAU | 0.0055ドル（10万MAUまで） |
| Essentials  | 10,000MAU | 0.015ドル            |
| Plus        | なし        | 0.020ドル            |
| SAML・OIDC連携 | 50MAU     | 0.015ドル            |
| IDプール       | 全量無料      | 0ドル                |

Liteは段階制で、10万MAUを超えると100万MAUまでが0.0046ドル、その先はさらに下がります。無料枠はAWSアカウント（またはAWS Organizations）単位で、12か月の無料利用期間が終わっても失効しません。M2M認証はMAUではなく、成功したトークン発行1件ごとの課金です（東京で25万件まで1件0.00225ドル）。SMSやメールの送信料はSNS・SESの料金として別にかかります。単価は改定されることがあるため、見積もりの前に料金ページかAWS Pricing Calculatorで最新値を確認してください。

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

上の単価をもとに、ユーザーが直接（またはソーシャルログインで）サインインする場合の月額を計算すると次のようになります。税金と為替、SMS・メールの送信料は含めていません。

| 月間MAU   | Lite  | Essentials | Plus    |
| ------- | ----- | ---------- | ------- |
| 10,000  | 0ドル   | 0ドル        | 200ドル   |
| 50,000  | 220ドル | 600ドル      | 1,000ドル |
| 100,000 | 495ドル | 1,350ドル    | 2,000ドル |

たとえば5万MAUのEssentialsは、無料枠を引いた40,000MAUに0.015ドルを掛けて600ドルです。Plusは無料枠が無いため、1万MAUでも200ドルかかります。パスキーやマネージドログインが不要ならLiteで抑えられ、不正ログイン対策が要件に入った時点でPlusの差額を見積もる、という順で比べると判断しやすくなります。

### MAUに数えられる操作と数えられない操作：月額課金の対象と判断基準

[Cognitoのクォータの公式ドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/quotas.html)では、その月に次の操作が1回でもあったユーザーをMAUとして数えると定めています。

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

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

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

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

| サービス                | 主な対象             | 役割                   |
| ------------------- | ---------------- | -------------------- |
| Amazon Cognito      | アプリのエンドユーザー（顧客）  | アプリのログイン・会員管理（CIAM）  |
| IAM                 | AWSの開発者・運用者・サービス | AWSリソースへのアクセス権限の管理   |
| IAM Identity Center | 組織の従業員           | 複数AWSアカウント／SaaSへのSSO |

IAMは「AWSを操作する人やサービスの権限」を管理する仕組みで、アプリの一般ユーザーを登録する用途には使いません。ユーザー・ロール・ポリシーの関係は[AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](https://www.issoh.co.jp/tech/details/15427/)で整理しています。一方、**IAM Identity Centerは2022年7月にAWS Single Sign-On（AWS SSO）から名称変更**されたサービスです。[IAM Identity Centerの公式ガイド](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)のとおり、社員が複数のAWSアカウントや業務アプリへ1回のログインでアクセスするための社内向けSSO基盤で、技術・APIは旧AWS SSOと互換があります。権限セットの設計は[AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説](https://www.issoh.co.jp/tech/details/15900/)で扱っています。

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

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

初めて導入する場合の基本的な流れは、おおまかに次の4ステップです。

- **1\. ユーザープールを作成**：サインイン方法（メール・電話番号など）、MFAの要否、機能プランを決めて作成します。
- **2\. アプリクライアントを登録**：プールに対してアプリを登録し、コールバックURLや許可する認証フローを設定します。
- **3\. アプリに認証を組み込む**：AWS Amplifyなどのライブラリやマネージドログインを使い、サインアップ・サインインの画面と処理をアプリに組み込みます。
- **4\. トークンを検証して制御**：ログイン後に発行されるトークンをバックエンドで検証し、ユーザーがアクセスできる機能やデータを制御します。

コンソールでも同じ設定ができますが、手順を再現しやすいようにAWS CLI（v2）で1から4の前半までを通してみます。使うコマンドは[create-user-pool](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool.html)、[create-user-pool-client](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/create-user-pool-client.html)、[sign-up](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/sign-up.html)、[initiate-auth](https://docs.aws.amazon.com/cli/latest/reference/cognito-idp/initiate-auth.html)の4つで、各オプションの意味は公式のコマンドリファレンスで確認できます。bashで実行する前提です。

```
# 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 \
  --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になり、`LITE` や `PLUS` を指定するとそのプランで作られます。手順3の `admin-confirm-sign-up` は確認コードの入力を省くための検証用の操作で、本番ではユーザー自身によるメールの確認コードの入力が必要です。パスワードを環境変数に置くのも検証用の扱いで、終わったら `aws cognito-idp delete-user-pool --user-pool-id "$POOL_ID"` で片付けます。サインアップとサインインはMAUに数えられますが、1人分なら無料枠に収まります。

コンソールでの画面操作、ホストされたログイン画面を使うOAuthのフロー、本番向けの設定値まで追いたい場合は、[Cognitoで認証基盤を実装する手順：ユーザープール構築からJWT検証まで](https://www.issoh.co.jp/tech/details/17445/)で順を追って解説しています。ログイン画面の見た目や日本語化は、[AWS Cognito Hosted UI（マネージドログイン）のカスタマイズ・日本語化と実装手順](https://www.issoh.co.jp/tech/details/3441/)を参考にしてください。フロントエンドをAmplifyで組む場合は、[AWS Amplifyとは？Gen 2のバックエンド定義と料金・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15590/)でCognitoとの関係を確認できます。

## 発行されたJWTをNode.jsのaws-jwt-verifyで検証する手順と注意点

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

Node.jsなら、AWSが公開している[aws-jwt-verify](https://github.com/awslabs/aws-jwt-verify)でこの5点をまとめて確認できます。2026年10月時点の最新は5.2系（5.2.1、2026年6月公開）で、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` が表示されます。末尾の1文字を書き換えたトークンを渡すと署名検証で失敗し、終了コード1になります。ユーザーを識別するキーには、メールアドレスではなく変わらない値の `sub` を使ってください。メールアドレスは利用者が後から変更できる属性だからです。

## API Gateway・Lambdaトリガーとの連携でAPIと認証フローを制御する

Cognitoの強みは、AWSの他サービスと組み合わせたときに出ます。とくにAPIの保護と認証フローのカスタマイズで使われることが多く、代表的なのが次の2つです。

- **API Gatewayのオーソライザー連携**：REST APIでは、`COGNITO_USER_POOLS` 型のオーソライザーを作ってメソッドに設定すると、有効なトークンを `Authorization` ヘッダーで送ったリクエストだけがAPIに届きます。[API Gatewayの公式ドキュメント](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-integrate-with-cognito.html)では、IDトークンはユーザーの属性に基づく認可に、アクセストークンはカスタムスコープに基づく認可に使うと整理されています。HTTP APIの場合は、JWTオーソライザーにユーザープールの発行元を設定して同じ目的を果たします。
- **Lambdaトリガーによる認証フローのカスタマイズ**：サインアップ前の入力検証（pre sign-up）、確認後のユーザー情報のDB登録（post confirmation）、トークン発行前のクレーム追加（pre token generation）、確認メール・SMSの文面の差し替え（custom message）などを**AWS Lambda**で差し込めます。使えるトリガーの一覧は[Lambdaトリガーの公式ドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-working-with-lambda-triggers.html)にまとまっています。なお、アクセストークンへのクレーム追加はEssentials以上、IDトークンへの追加は全プランで使えます。

このようにCognitoは単体の認証サービスにとどまらず、API GatewayやLambdaと組み合わせることで、少ない実装量で安全なバックエンドを組めます。「このユーザーはこの請求書を見てよいか」といったリソース単位の認可まで外に出したい場合は、Cedarでポリシーを書く[Amazon Verified Permissionsとは？Cedarの書き方と料金・API Gateway連携の手順](https://www.issoh.co.jp/tech/details/4766/)と組み合わせる構成もあります。

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

Cognitoは幅広いアプリで使えますが、とくに向いているのは次のようなケースです。

- **B2C向けWeb／モバイルアプリ**：ECサイトや会員制サービスで、安全なサインアップ・ログインを短期間で用意したい場合。
- **エンタープライズアプリ**：社員やパートナー向けに、外部IdP（SAML・OIDC）と連携した認証を一元管理したい場合。
- **高いセキュリティが求められるアプリ**：MFAやPlusの脅威保護を組み合わせ、不正アクセスやなりすましを抑えたい場合。顔の生体検知でなりすましを防ぐなら、FaceLivenessDetectorの実装｜Amplify UIのなりすまし検知とチャレンジ設定・しきい値設計のような手法と組み合わせられます。パスキーの仕組みそのものは[WebAuthnとは？パスキー認証を実装する仕組みと登録・認証フロー・RP実装の要点](https://www.issoh.co.jp/tech/details/15375/)で解説しています。

認証後の「誰が何にアクセスしてよいか」をきめ細かく制御したい場合は、外部の認可エンジンと組み合わせる方法もあります。OSSの認可エンジンTopazの現状はAserto Topazとは？商用サービス終了後もOSSで使えるのか【2026年8月時点】にまとめています。

同じ役割の認証サービスとして、Auth0・Keycloak・Firebase Authenticationがよく比較されます。CognitoはAWSのIAMやAPI Gateway、Lambdaと設定だけでつながる点と、MAU単価の低さで優位です。一方で、ログイン画面の作り込みや組織単位のテナント管理、管理画面の使い勝手は、IDaaS専業の製品のほうが厚い傾向があります。製品ごとの違いは[Keycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】](https://www.issoh.co.jp/tech/details/7663/)と[Firebase Authenticationとは？料金・認証方式・導入手順とIDトークン検証【2026年9月】](https://www.issoh.co.jp/tech/details/5921/)で比べられます。

## Amazon Cognito導入時の注意点：作成後に変えられない設定と課金

手軽に始められる一方で、後から変更できない設定があります。導入前に押さえておきたい点を挙げます。

- **サインイン属性は最初に決める**：メールアドレス・電話番号・ユーザー名のうちどれをサインインIDにするか（ユーザー名属性またはエイリアス属性）は、[ユーザー属性の公式ドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/user-pool-settings-attributes.html)のとおり作成後に変更できません。必須属性の指定も同様です。
- **カスタム属性は消せない**：カスタム属性は1プールあたり50個まで追加でき、追加後は削除も名前・型の変更もできません。頻繁に変わる値（利用状況やポイント残高など）は属性に入れず、DynamoDBなど別のデータストアに置きます。
- **料金はMAUベースで試算する**：想定ユーザー数と機能プランを決め、前章の表やPricing Calculatorで事前に試算しておくと、公開後のコストのぶれを抑えられます。AdminGetUserを全件に回すバッチは、ログインしていないユーザーまでMAUにする点も確認します。
- **セキュリティ機能はティア再編に注意**：かつての「高度なセキュリティ機能（ASF）」に相当する脅威保護（リスクベース認証・漏えい認証情報の検出など）は、現在は**Plus**に整理されています。Essentialsが加えるのはマネージドログインやパスワードレスで、脅威保護は含みません。不正ログイン対策が要件にあるなら、新規はPlusを前提に見積もってください。
- **クォータを確認する**：既定では1リージョンあたりユーザープール1,000個、1プールあたりアプリクライアント1,000個、ユーザー4,000万人が上限です。APIのリクエスト数にも操作の種類ごとの上限があり、大規模な一斉ログインを想定するなら引き上げ申請（有料の追加オプション）も検討します。

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

ここまでの機能と料金を踏まえると、Cognitoを選ぶかどうかは次の条件で判断できます。

**採用してよい条件**は、(1) アプリのバックエンドがAWS上にあり、API GatewayやLambda、S3と組み合わせる、(2) 要件がメール・ソーシャルログイン・MFA・パスキーといった標準的な会員ログインで足りる、(3) 会員数が数万〜数十万MAUで、1MAUあたりの単価を抑えたい、の3つがそろう場合です。この条件なら、自前で認証を書くより安全で、IDaaS専業の製品より安く済む見込みが高くなります。

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

既存の会員データベースからCognitoへ移す場合は、[CSVインポートの公式ドキュメント](https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-using-import-tool.html)に3つの道が示されています。既定のCSVインポートはパスワードを含まず、利用者は初回ログイン時にパスワードの再設定が必要です。対応済みのユーザープールなら、bcrypt・scrypt・Argon2id・PBKDF2-SHA256のパスワードハッシュを取り込み、再設定なしでログインさせられます。ハッシュの形式が合わない場合は、Lambdaトリガーで旧システムに照会するジャストインタイム移行を組みます。CSVインポート自体はMAUに数えられませんが、パスワード再設定の操作はMAUになるため、この操作も試算の対象です。どの移し方が自社の会員規模と運用に合うかの判断や、Cognitoか他製品かの選定から実装までを任せたい場合は、一創の[認証基盤・ID管理システム開発](https://www.issoh.co.jp/service/system/identity/)でご相談いただけます。

## よくある質問

### Q. Amazon Cognitoの読み方は？

「コグニート」です。ラテン語の `cognitio`（認知・知ること）が名称の由来で、ユーザーを認識・認証する役割を表しています。綴りは c-o-g-n-i-t-o で、「cognit」で調べている場合もこのサービスを指すことがほとんどです。

### Q. Cognitoは無料で使えますか？

LiteとEssentialsは、直接サインインとソーシャルログインのユーザーについて月10,000MAUまで無料です。無料枠はアカウント単位で、12か月の無料期間が終わっても続きます。Plusには無料枠がなく、SAML・OIDCで連携するユーザーの無料枠は50MAUです。IDプールは料金がかかりません。単価は改定されることがあるため、最新値はAWS公式の料金ページで確認してください。

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

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

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

いずれもアプリの認証を担うサービスです。CognitoはAWSのエコシステムと統合しやすく、S3やLambdaなど他のAWSサービスと組み合わせる構成で運用コストを抑えやすいのが強みです。AWS中心の構成ならCognitoが有力な選択肢になり、ログイン画面の作り込みやB2B向けのテナント管理を重視するならAuth0なども比較します。

### Q. ユーザープールとIDプールは両方必要ですか？

多くのアプリではユーザープールだけで足ります。IDプールが必要になるのは、認証済みユーザーやゲストにS3やDynamoDBなどAWSリソースへ直接アクセスさせたい場合です。APIをAPI Gateway経由で公開し、バックエンドでトークンを検証する構成なら、IDプールは使いません。

## 関連記事

- [Cognitoで認証基盤を実装する手順：ユーザープール構築からJWT検証まで](https://www.issoh.co.jp/tech/details/17445/)
- [AWS Cognito Hosted UI（マネージドログイン）のカスタマイズ・日本語化と実装手順](https://www.issoh.co.jp/tech/details/3441/)
- [AWS IAM Identity Centerとは？権限セット設計とCLI認証・IAMとの使い分けを実装者目線で解説](https://www.issoh.co.jp/tech/details/15900/)
- [JWTとは？構造・署名検証の仕組みとセッション・OAuth/OIDCとの違いを実装視点で解説](https://www.issoh.co.jp/tech/details/13453/)
- [Keycloakとは？メリット・デメリットとAuth0・Okta・Cognito比較で導入を判断【2026年版】](https://www.issoh.co.jp/tech/details/7663/)
- [Aserto Topazとは？商用サービス終了後もOSSで使えるのか【2026年8月時点】](https://www.issoh.co.jp/tech/details/4609/)

---

出典: [Amazon Cognito（コグニート）とは？料金・できること・使い方をCLIとコード例で解説【2026年10月】](<https://www.issoh.co.jp/tech/details/3108/>)（株式会社一創）