Amazon Cognito入門｜ユーザー認証基盤をゼロから構築するAWS実践ガイド

「WebアプリにログインPageを追加したいけど、認証基盤を自前で構築するのは大変すぎる」「Active Directoryでユーザー管理してきたけど、クラウド移行したら認証はどうすればいいのか」——そんな悩みを抱えるインフラエンジニアは多いはずです。

オンプレ環境では、Active Directory（AD）やLDAPがユーザー認証の中核を担っていました。しかしクラウドネイティブなWebアプリやモバイルアプリでは、MFAやソーシャルログイン（Google、Facebookなど）、トークンベースの認証（JWT）が当たり前になっています。これを自前で構築しようとすると、セキュリティの維持・スケーラビリティの確保・トークン管理と、想像以上の工数がかかります。

そこで登場するのが Amazon Cognito です。AWSが提供するマネージドの認証・認可サービスで、ユーザーの登録・ログイン・MFA・JWTトークン発行までをまるごと引き受けてくれます。

この記事では、Amazon Cognitoの基本概念（ユーザープールとIDプールの違い）、コンソールでの設定手順、料金体系、現場で使える実務Tipsまで、オンプレ経験者にもわかりやすく解説します。

なぜ Amazon Cognito なのか？――オンプレ認証基盤との違い

オンプレのActive Directoryは「社内システムへのログイン」に特化した設計です。LDAP認証やKerberos、SMBプロトコルとの統合が強みですが、インターネット向けのWebアプリに対応させるにはAzure Entra ID（旧Azure AD）やADFSなど追加のコンポーネントが必要で、構成が複雑になりがちでした。

Amazon Cognitoが解決する主な課題は次の4点です。

・認証基盤の運用コスト削減: サーバー管理・パッチ適用・HA構成をAWSが担う
・ソーシャルログイン対応: Google、Facebook、Appleのソーシャルプロバイダーと数クリックで連携
・MFA・パスワードポリシー: TOTP認証やSMSコードによる多要素認証を標準実装
・スケーラビリティ: 数百万のユーザーを管理しても追加の設計作業が不要

オンプレとの対比で整理すると、次のようなイメージです。

Amazon Cognito の2大コンポーネント

Cognitoを使いこなすには、まず「ユーザープール」と「IDプール」の違いを押さえることが最重要です。ここで混乱するエンジニアが多いので、しっかり整理します。

ユーザープール（User Pool）

ユーザープールは 「誰であるか（認証）」 を管理する機能です。メールアドレスやパスワードでユーザーを登録し、ログイン時にJWTトークンを発行します。

・ユーザーの登録・管理（メール確認・パスワードリセット含む）
・ソーシャルプロバイダー（Google、Facebook、Apple）との連携
・SAML/OIDCフェデレーション（企業ADとの連携に使用）
・JWTトークン（IDトークン・アクセストークン）の発行
・MFA（TOTP / SMS）の強制または任意設定

IDプール（Identity Pool）

IDプールは 「何をしてよいか（認可）」 を管理する機能です。ユーザープールや外部プロバイダーから渡されたトークンを受け取り、AWSリソースへのIAM一時認証情報に変換します。

・認証済みユーザーに一時的なIAMロールを付与
・未認証ユーザー（ゲスト）へのAWS操作を制御
・モバイルアプリからS3への直接アップロードなど、クライアント側からAWSリソースへ直接アクセスする構成に使用

シンプルなWebアプリのログイン機能なら ユーザープールだけ で十分です。モバイルアプリからAWSリソース（S3、DynamoDBなど）に直接アクセスさせたい場合にIDプールを追加します。

基本的な使い方（コンソール操作）

1. ユーザープールを作成する

AWSコンソールにログインし、検索バーに「Cognito」と入力してAmazon Cognitoサービスへ移動します。「ユーザープールを作成」をクリックし、以下の設定を進めます。

・サインインオプション: 「メールアドレス」または「ユーザー名」を選択（作成後に変更不可なので慎重に）
・パスワードポリシー: 最小長・大文字小文字・記号の要件を設定
・MFA: 「必須」「オプション」「オフ」から選択（本番環境では「オプション」以上を推奨）
・セルフサービスアカウント回復: メールによるパスワードリセットを有効化

2. アプリクライアントを作成する

ユーザープールを作成したら、次にアプリケーションが認証に使う「アプリクライアント」を作成します。

・アプリクライアント名: 任意（例：my-web-app-client）
・クライアントシークレット: サーバーサイドアプリには生成する。SPAや純粋なフロントエンドアプリは「生成しない」を選択
・OAuth 2.0 付与タイプ: 「認証コード」を選択（インプリシット付与は非推奨）
・コールバックURL: 認証後にリダイレクトするURL（例：https://yourapp.example.com/callback）

3. ホストドUIでログインをテストする

Cognitoには ホストドUI という、AWSが提供するビルトインのログインページがあります。カスタムUIを実装する前に、認証フローの動作確認として活用できます。

「アプリクライアント」→「ホストドUIを表示」から確認URLにアクセスし、ユーザー登録→メール確認→ログインの一連の流れをテストできます。ログインURLは以下の形式になります。

# ホストドUIのログインURL構成（ブラウザで直接アクセス可）
# https://.auth.ap-northeast-1.amazoncognito.com/login
#   ?response_type=code
#   &client_id=
#   &redirect_uri=https://yourapp.example.com/callback

# アプリクライアントの情報をAWS CLIで確認
aws cognito-idp describe-user-pool-client \
  --user-pool-id ap-northeast-1_XXXXXXXXX \
  --client-id XXXXXXXXXXXXXXXXXXXXXXXXXX \
  --region ap-northeast-1

認証成功後、コールバックURLに code=xxxxxxxx パラメータが付与されてリダイレクトされます。このコードをバックエンドでトークンと交換するのが「認証コードフロー」の流れです。

4. JWTトークンをバックエンドで検証する

Cognitoが発行するJWTトークンは、バックエンドAPIで必ず検証する必要があります。検証に必要な公開鍵（JWKS）は以下のエンドポイントで取得できます。

# CognitoのJWKSエンドポイント（HTTPSでGET可能）
# https://cognito-idp.ap-northeast-1.amazonaws.com//.well-known/jwks.json

# Python（PyJWT）でのトークン検証例
import requests
import jwt

REGION = "ap-northeast-1"
USER_POOL_ID = "ap-northeast-1_XXXXXXXXX"
APP_CLIENT_ID = "XXXXXXXXXXXXXXXXXXXXXXXXXX"

jwks_url = f"https://cognito-idp.{REGION}.amazonaws.com/{USER_POOL_ID}/.well-known/jwks.json"
jwks = requests.get(jwks_url).json()

# audクレームとissクレームを必ず検証すること
decoded = jwt.decode(
    token,
    jwks,
    algorithms=["RS256"],
    audience=APP_CLIENT_ID,
    issuer=f"https://cognito-idp.{REGION}.amazonaws.com/{USER_POOL_ID}"
)

料金の仕組み（コスト感覚）

Amazon Cognitoの料金は MAU（Monthly Active Users：月間アクティブユーザー数） ベースです（2026年3月時点）。MAUは「ある月に1回でも認証操作を行ったユーザー」としてカウントされます。

月間アクティブユーザーが50,000人以下であれば事実上無料で使えるため、スタートアップや社内ツールの認証基盤として非常にコスパが高い選択肢です。

【コスト注意点】SAML / OIDCフェデレーション（Active Directoryとの連携など）を使うユーザーは、通常MAUとは別に追加料金（約$0.015/MAU）が発生します（2026年3月時点）。Active Directory連携を計画している場合は、事前にコスト試算を行ってください。

応用・実務Tips

【Tips 1】 既存のActive DirectoryをSAML連携でつなぐ

社内にActive Directoryが存在する場合、ADFSやAzure Entra IDをSAMLプロバイダーとしてCognitoに登録することで、社員が社内の資格情報でクラウドWebアプリにログインできます。

「ユーザープール」→「フェデレーション」→「IDプロバイダー」→「SAML」からADFSのメタデータXMLをアップロードするだけで設定完了です。オンプレからクラウドへのシングルサインオン（SSO）移行の橋渡しとして非常に有効です。

【Tips 2】 Lambdaトリガーでユーザー登録フローをカスタマイズ

Cognitoにはサインアップ・ログイン・トークン発行などのタイミングでAWS Lambdaを呼び出す「トリガー」機能があります。

・Pre-signupトリガー: 特定ドメインのメールアドレスのみ登録を許可する
・Post-confirmationトリガー: 登録完了時にAmazon SESでWelcomeメールを送信する
・Pre-token generationトリガー: JWTトークンにカスタムクレームを追加してバックエンドへの情報連携を拡張する

【Tips 3】 Amplify SDKでフロントエンド実装を効率化

ReactやVue.jsなどのSPAからCognitoを利用する場合、AWS AmplifyのJavaScript SDKを使うと、トークン管理・リフレッシュ・ローカルストレージ保存などの実装を大幅に省力化できます。

# AWS Amplify SDKのインストール
npm install aws-amplify

# Cognito設定（JavaScript）
import { Amplify } from 'aws-amplify';
Amplify.configure({
  Auth: {
    Cognito: {
      userPoolId: 'ap-northeast-1_XXXXXXXXX',
      userPoolClientId: 'XXXXXXXXXXXXXXXXXXXXXXXXXX',
      loginWith: { email: true }
    }
  }
});

# サインイン実行
import { signIn } from 'aws-amplify/auth';
const result = await signIn({
  username: 'user@example.com',
  password: 'Password123!'
});

よくあるトラブルと対処法

【トラブル 1】 「Invalid client_id」エラーでホストドUIが開けない

原因: アプリクライアントにコールバックURLが未設定、またはCognitoドメインが有効化されていない状態でホストドUIにアクセスしている。

対処: コンソールで「アプリクライアント」→「ホストドUIを編集」を開き、コールバックURLとサインアウトURLを少なくとも1つ以上設定してください。また「Cognitoドメイン」が有効化されているかも確認します。

【トラブル 2】 JWTトークンの検証で「TokenExpiredException」が頻発する

原因: Cognitoのアクセストークンのデフォルト有効期限は1時間です。フロントエンドがトークンをリフレッシュせずにAPIを呼び続けると発生します。

対処: Amplify SDKを使っている場合は自動リフレッシュが有効です。自前実装の場合は、リフレッシュトークンを使ったトークン更新処理（InitiateAuth API + REFRESH_TOKEN_AUTH フロー）を実装してください。リフレッシュトークンの有効期限はデフォルト30日で、コンソールから変更できます。

【トラブル 3】 ユーザープールを削除・再作成したらアプリが動かなくなった

原因: ユーザープールIDとアプリクライアントIDは再作成すると必ず変わります。フロントエンド・バックエンドにハードコードされた設定を更新し忘れると、認証全体が機能しなくなります。

対処: ユーザープールIDとクライアントIDは環境変数（AWS Systems Manager パラメータストアまたはAWS Secrets Manager）で管理し、コードにハードコードしないことが鉄則です。また本番環境のユーザープールを削除するとユーザーデータは完全に失われるため、削除前に必ず確認を取ってください。

【トラブル 4】 MFAを「必須」にしたらテストユーザーでログインできなくなった

原因: MFAを必須に設定後、既存ユーザーがTOTPアプリを未設定の状態で残っているとログインフローがMFA設定画面で止まります。

対処: 管理者側からAWS CLIで対象ユーザーのMFA設定をリセットできます。

# AWS CLI: 特定ユーザーのMFA設定を確認
aws cognito-idp admin-get-user \
  --user-pool-id ap-northeast-1_XXXXXXXXX \
  --username testuser@example.com \
  --query 'MFAOptions' \
  --region ap-northeast-1

# 管理者側でTOTP MFAを無効化
aws cognito-idp admin-set-user-mfa-preference \
  --user-pool-id ap-northeast-1_XXXXXXXXX \
  --username testuser@example.com \
  --software-token-mfa-settings Enabled=false,PreferredMfa=false \
  --region ap-northeast-1

本記事のまとめ

Amazon Cognitoは、「認証基盤を自前で構築・運用するコスト」を大幅に削減しながら、現代のWebアプリに求められるソーシャルログイン・MFA・JWTベースの認証を標準で備えた強力なマネージドサービスです。

まずは50,000 MAUまで無料のフリーティアを活用して、開発・ステージング環境で動作確認を行うことをお勧めします。ホストドUIで認証フローを体験し、慣れてきたらLambdaトリガーやカスタムUIへと段階的に発展させていく進め方が現場では定着しやすいです。

クラウドEC2上で動かすLinuxサーバーの構築・運用については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。Cognitoで認証基盤を整えたあとのサーバーサイド設計にも役立ててください。