TL Terralien
Security, Identity, and Compliance

Amazon Cognito

生成AIアプリの一般エンドユーザーを認証・認可する仕組み。Bedrock AgentCore Identityのチュートリアルが最初の一歩としてCognitoユーザープールを使っています。

  • B｜実装まわり
  • D2 実装と統合
  • D3 安全性・セキュリティ・ガバナンス

最終更新: 2026年8月18日

ひとことで言うと

アプリの一般エンドユーザーを認証し、必要ならAWSリソースへの一時的な資格情報も発行する仕組みです。ユーザープール（認証）とアイデンティティプール（AWS認証情報の発行）という、独立して使える2つの部品でできています。

要するに、来館者受付です。ユーザープールが受付で本人確認をしてバッジ（IDトークン）を渡し、アイデンティティプールがそのバッジと引き換えに「このフロアだけ入れる」一時的な入館証（STSの一時AWS認証情報）を発行します。生成AIアプリでエージェントを呼び出すのは、正確には「バッジを持った来館者」であって、エージェント自身ではありません。

なぜ生まれたか

Cognitoが無いと受け皿
アプリごとに独自の認証システムをゼロから作るユーザープールがサインアップ・サインイン・MFAを提供
ソーシャルログイン（Google・Facebook等）を個別に統合する必要があるユーザープールがOIDC/SAML/ソーシャルIdPを吸収し、統一したJWTを発行
認証したユーザーにAWSリソースへの一時アクセスをどう渡すか自作するアイデンティティプールがAWS STSの一時認証情報を発行

生成AIの文脈では、Bedrock AgentCore Identityの入門チュートリアルが「Cognitoユーザープールを作成し、認証済みエージェントをデプロイする」という流れを最初のステップに置いています。エージェントを人間のユーザーに代わって動かす前提として、まずその人間を認証する必要があるからです。

何に使うか

用途使い方関連ドメイン
生成AIアプリのエンドユーザー認証ユーザープールでサインイン・MFA・JWT発行D2
エージェントアプリへの一時AWS認証情報付与アイデンティティプールがロールベース／属性ベースでSTS認証情報を発行D2・D3
AgentCore Identityでの認証済みエージェント構築チュートリアルの出発点としてCognitoユーザープールを利用D2
認証フロントエンドの保護CognitoユーザープールにAWS WAFのWeb ACLを関連付け可能D3

試験でどう問われるか

問われ方正解に寄る条件引っかけの選択肢
生成AIチャットアプリの一般ユーザーにサインイン機能を持たせたいユーザープールでJWTを発行IAMユーザーを利用者ごとに作成する
認証済みユーザーの部門ごとに、呼び出せるAWSリソースを分けたいアイデンティティプールの**属性ベースアクセス制御（ABAC）**でプリンシパルタグを付与アプリのコード側で条件分岐してAPIを呼び分ける
エージェントそのものをAWSの主体として認証したいCognitoは人間のエンドユーザーが主対象。エージェント自体のAWS内での身元管理はAgentCore Identityやワークロード側の仕組みCognitoでエージェント専用ユーザーを作りIAMロールのように扱う
ゲストユーザーにも限定的にAWSリソースへアクセスさせたいアイデンティティプールのunauthenticated identities（未認証アクセス）ゲスト専用のIAMユーザーを都度発行する

ユーザープールとアイデンティティプールは独立して使えます。「認証だけ必要でAWSリソースへの直接アクセスは不要」なアプリなら、ユーザープール単体で完結し、アイデンティティプールは不要です。

実務でどう使うか

  • ロールベースアクセス制御とABACは併用できます。 グループ所属でロールを選びつつ、属性を使ってそのロール内でさらに絞り込む、という二段構えが可能です
  • アイデンティティプールは開発者認証済みID（developer-authenticated identities）もサポートします。 独自の認証方式を持つ既存システムからでも、AWS認証情報を発行する経路として使えます

MFA・カスタム認証フロー・セキュリティ監視はフェデレーテッドユーザー（外部IdP経由でサインインしたユーザー）には提供されません。ローカルユーザー限定の機能である点は見落としやすいところです。

取り違えやすいもの

迷う相手切り分けの一言
IAM Identity CenterCognitoは自社アプリの一般エンドユーザー向け。Identity Centerは社内ワークフォースが複数AWSアカウント・管理アプリに入るため
IAMCognitoはアプリ利用者の認証。IAMはAWSリソース側（サービスロール等）の権限。アイデンティティプールがこの2つを橋渡しする
AWS Secrets ManagerCognitoは利用者の身元を扱う。Secrets Managerはアプリやサービスが使う資格情報（APIキー等）を扱う。対象が人か値かで分かれる

想起チェック

Q1. ユーザープールとアイデンティティプールの役割の違いは？

**ユーザープールは認証（サインイン・JWT発行）、アイデンティティプールは認可（AWS STSの一時的な認証情報の発行）**です。ユーザープールのJWTをアイデンティティプールに渡して交換する、という一方向の連携が基本形です。

Q2. Cognitoで認証したユーザーの部門ごとに、アクセスできるAWSリソースを分けたい。どちらの制御方式が向いている？

**属性ベースアクセス制御（ABAC）**です。ユーザーの属性（例：部門）をSTSの一時セッションのプリンシパルタグに変換し、IAMポリシー側の条件キーでリソースアクセスを絞り込みます。

出典（AWS公式）