Cognito（ユーザープールとIDプール）難易度 標準無料
モバイルアプリで、ユーザーにメールアドレス／パスワードでサインアップ・サインインさせ、さらにサインイン後は一時的なAWS認証情報を発行して、モバイルSDKから直接S3バケットへ画像をアップロードできるようにしたい。この要件を満たす設計として最も適切なものを選べ。（単一選択）
- ACognitoユーザープールだけを使い、サインイン成功時に発行されるIDトークンをそのままS3へのアクセス認証情報として使う
- BCognitoユーザープールでメール/パスワード認証を行い、発行されたトークンをCognitoIDプールに連携して、認証済みユーザー用IAMロールの一時的なAWS認証情報を取得し、モバイルSDKからS3へ直接アクセスする
- CユーザーごとにIAMユーザーを作成し、そのアクセスキーをアプリに埋め込んでS3へアクセスさせる
- DCognitoIDプールだけを使い、メールアドレスとパスワードによる認証もIDプール側の機能で完結させる
正解・解説・誤答理由・ひっかけを見る▼ open
✓ 正解：BAI作成・AIで再検証済
解説
Amazon Cognitoの2つのコンポーネントは役割がはっきり分かれている。
- Cognitoユーザープール（User Pool）：ユーザーディレクトリ機能。サインアップ・サインイン、パスワードポリシー、MFA、 外部IdP（Google/SAML等）連携を提供し、認証成功時にJWT（IDトークン・アクセストークン）を発行する。ユーザープール単体ではAWSリソースへの直接アクセス用の認証情報は発行しない。
- CognitoIDプール（Identity Pool / Federated Identities）：ユーザープールなど各種IdPが発行したトークンを受け取り、 STSを介して一時的なAWS認証情報（IAMロールに基づく）に交換する。この一時認証情報を使ってモバイルSDKがS3等へ直接アクセスできる。
したがって「ユーザープールで認証 → 発行されたトークンをIDプールに連携し、認証済みユーザー用IAMロールの一時認証情報を取得してS3へ直接アクセス」という組み合わせが正解となる。
- Aユーザープールが発行するのはJWT（IDトークン等）であり、S3等のAWS APIを直接呼び出せるAWS認証情報ではない。AWSリソースへのアクセスにはIDプールを介した交換が必要。
- Cユーザー数分のIAMユーザー管理はスケールせず、長期アクセスキーをモバイルアプリに埋め込むのはベストプラクティスに反する（漏えいリスク・失効困難）。
- DIDプール自体はメール/パスワードのようなユーザーディレクトリ認証機能を持たない。認証は外部IdP（ユーザープール等）に委ね、IDプールはそれを一時的なAWS認証情報に交換する役割。
ひっかけ： 「ユーザープールだけでAWS認証情報が取れる（A）」という誤解が典型的。認証（誰であるか）はユーザープール、
認可（AWSリソースへのアクセス権）はIDプールという役割分担を混同しないこと。
公式ドキュメント・関連Amazon Cognito Developer Guide ― Amazon Cognito user pools↗Amazon Cognito Developer Guide ― Amazon Cognito identity pools (federated identities)↗
AIが作成し、別の手順のAIで誤りを点検した解説です（有資格者による監修は経ていません）