SAA-033
モバイルアプリのエンドユーザー向けに、サインアップ・サインインとGoogleなど外部IDプロバイダー連携を実装します。認証後はAmazon API Gatewayで公開したREST APIへのアクセス制御にも同じ認証結果を使いたいです。最も適した構成はどれですか？
選択肢
解説と正解
解説と正解を読む（先に自分で回答してから開くのがおすすめです）
正解：D. Amazon Cognitoユーザープールでユーザーを管理し、発行されたトークンをAPI GatewayのCognitoオーソライザーで検証する
解説
アプリのエンドユーザー認証にはAmazon Cognitoユーザープールが適しています。サインアップ・サインイン、MFA、外部IDプロバイダー連携をマネージドで提供し、発行されるIDトークン・アクセストークンをAPI GatewayのCognitoオーソライザーでそのまま検証できます。
選択肢ごとの解説
A. エンドユーザーごとにIAMユーザーを作成し、アプリにアクセスキーを埋め込んでSigV4署名でAPIを呼び出す
IAMはAWSリソースを操作する主体（社内の人・アプリケーション）のための仕組みで、アプリのエンドユーザーを個別のIAMユーザーとして管理する設計ではありません。長期のアクセスキーをアプリへ埋め込む点も安全ではありません。
B. AWS IAM Identity Centerでエンドユーザーを管理し、SAMLアサーションをアプリへ連携する
IAM Identity Centerは従業員などワークフォースのシングルサインオン向けで、一般消費者のセルフサービスなサインアップは想定されていません。
C. ユーザー名とパスワードのハッシュをAWS Secrets Managerに保存し、Lambdaで自前の認証処理を実装する
認証処理を自前実装するとパスワード保管、MFA、トークン失効、外部IdP連携をすべて自作することになります。Secrets Managerはアプリケーションが使う認証情報の保管が用途で、ユーザーディレクトリではありません。
D. Amazon Cognitoユーザープールでユーザーを管理し、発行されたトークンをAPI GatewayのCognitoオーソライザーで検証する
正解です。ユーザープールがユーザーディレクトリとトークン発行を担い、API GatewayのCognitoオーソライザーがトークン検証を担うため、認証処理を自前実装せずに済みます。
実務での使いどころ
Amazon Cognito は「ユーザープール」と「IDプール（フェデレーティッドアイデンティティ）」という 2 つの機能から構成される。ユーザープールはアプリのユーザーディレクトリで、サインアップ・サインイン・パスワードポリシー・MFA・メール/SMS 検証・Google や Apple などの外部 IdP との連携をマネージドで提供し、認証成功時に OpenID Connect の ID トークン、アクセストークン、リフレッシュトークンを発行する。ID プールはこれらのトークン（あるいは他の IdP のトークン）と引き換えに一時的な AWS 認証情報を払い出す仕組みで、アプリから S3 や DynamoDB を直接呼びたい場合に使う。 設計上は「誰を認証したいのか」で使い分けを決める。アプリの一般ユーザーはユーザープール、AWS リソースを操作する社内の人や CI/CD は IAM、従業員のシングルサインオンは IAM Identity Center という切り分けになる。API Gateway と組み合わせる場合、REST API では Cognito オーソライザーを設定するとトークンの署名・有効期限・aud/iss をマネージドで検証してくれるため、Lambda オーソライザーを自作する必要がなくなる。より細かい制御（スコープやカスタムクレームによる分岐）が必要なときのみ Lambda オーソライザーを併用する。 SAA-C03 では「モバイルアプリ / Web アプリのユーザー認証」「ソーシャルログイン」「サインアップ機能」といった要件で Amazon Cognito が正解になる。誤答としてエンドユーザーごとの IAM ユーザー作成が頻出するが、IAM ユーザーにはアカウントあたりの上限があり、そもそもエンドユーザー管理を意図した機能ではないため設計として不適切である。IAM Identity Center（ワークフォース向け）との役割の違いも問われやすい。