Amazon Cognito
Amazon Cognito は、自社の Web アプリやモバイルアプリの利用者（エンドユーザー）に、サインアップ・サインインの機能と、AWS のリソースを使うための一時的な権限を提供するサービスです。SAA では、ユーザープールと ID プールの違いと、ALB・API Gateway と組み合わせた認証の設計が問われます。
ひとことで言うと: ユーザープールは「会員名簿と受付（本人確認をして会員証を渡す）」、ID プールは「会員証を AWS の入館証（一時的な認証情報）に交換する窓口」です。
たとえるなら、テーマパークの受付で本人確認をして会員証（トークン）をもらい、その会員証を見せると、アトラクションに入れる当日限りのチケット（AWS の一時的な認証情報）に交換してもらえる仕組みです。
このページで押さえる論点
ユーザープールと ID プールの違い
Cognito は 2 つの部品でできています。名前が似ていますが、役割がまったく違います。
| 観点 | ユーザープール | ID プール（フェデレーテッドアイデンティティ） |
|---|---|---|
| 役割 | 認証（あなたは誰か）。利用者の名簿と、サインインの仕組み | 認可（AWS で何をしてよいか）。AWS のリソースを使う権限を渡す |
| 渡すもの | JWT（JSON Web Token）形式の ID トークン・アクセストークン・更新トークン | AWS STS が発行する一時的な AWS 認証情報（アクセスキー ID・シークレットアクセスキー・セッショントークン） |
| 主な使い道 | アプリのログイン画面、API へのアクセスの確認 | アプリから S3・DynamoDB などの AWS のサービスを直接呼び出す |
| 受け付ける相手 | ユーザープールに登録した利用者、ソーシャル ID プロバイダー、SAML・OIDC の ID プロバイダー | ユーザープール、ソーシャル ID プロバイダー、SAML・OIDC、独自の認証、未認証（ゲスト）の利用者 |
両方を組み合わせるのが典型です。利用者がユーザープールでサインインしてトークンを受け取り、そのトークンを ID プールで一時的な AWS 認証情報に交換して、S3 などに直接アクセスします。
ユーザープールでサインインし、ID プール経由で S3 に写真をアップロードする
※簡略化しています: 実際には、ID プールはまず利用者ごとの ID を払い出し、その ID で AWS STS に認証情報を求めます。図では ID プールと STS を 1 つの箱にまとめています。AWS の SDK を使うと、トークンの交換や認証情報の更新は自動で行われます。
ユーザープール
ユーザープールは、アプリの利用者の名簿（ユーザーディレクトリ）と、OAuth 2.0 / OpenID Connect（OIDC）に対応した認証サーバーを兼ねるものです。自分でログイン機能やパスワードの保管を作らずに済みます。
- サインアップ・サインイン: メールアドレスや電話番号での登録、確認コードでの本人確認、パスワードを忘れたときの再設定をまとめて提供します。AWS が用意したログイン画面（マネージドログイン）も使えます。
- MFA: 多要素認証（SMS・認証アプリなど）を有効にできます。
- 外部 ID プロバイダーとのフェデレーション: Google・Facebook・Apple・Amazon などのソーシャルアカウントや、企業の SAML 2.0・OIDC の ID プロバイダーでサインインさせ、どこからサインインしても同じ形式のトークンをアプリに渡します。
- JWT: サインインに成功すると、ID トークン（利用者の情報）、アクセストークン（API を呼ぶ権限の証明）、更新トークン（新しいトークンをもらうためのもの）が発行されます。API 側はトークンの署名を検証して、正しい利用者かを確認します。
- Lambda トリガー: サインアップの前後やトークンの発行時などに Lambda 関数を呼び出し、独自のチェックや処理を加えられます。
- グループ: 利用者をグループに分け、グループごとに IAM ロールを対応付けられます（ID プールと組み合わせたとき、権限の出し分けに使えます）。
- 保護: ユーザープールには AWS WAF のウェブ ACL を関連付けて、ログイン画面や API への攻撃を防げます（WAF のページを参照）。
ID プール
ID プールは、利用者に一時的な AWS 認証情報を渡し、アプリから S3・DynamoDB などの AWS のサービスを直接使えるようにします。裏側では AWS STS が一時的な認証情報を発行するので、アプリにアクセスキーを埋め込む必要がありません（アクセスキーを埋め込むと、アプリを解析されたときに漏れてしまいます）。
- 認証済みの利用者と未認証（ゲスト）の利用者で別々の IAM ロールを割り当てられます。たとえば、ゲストには商品カタログの読み取りだけ、サインインした会員には自分のデータの書き込みも許可する、という設計ができます。
- ロールの選び方: 全員に同じロールを割り当てるほか、トークンの内容（ユーザープールのグループや属性）に応じてロールを選ぶルールを設定できます。
- 利用者ごとのアクセス制御: IAM ポリシーの中で、利用者の ID を表す変数（cognito-identity.amazonaws.com:sub）を使うと、「S3 の自分用のフォルダ（プレフィックス）だけ」「DynamoDB の自分のパーティションキーの項目だけ」に限定できます。
権限は IAM ロールで決まるので、ロールのポリシーは最小権限の原則で書きます。
ALB・API Gateway・AppSync との連携
| 連携先 | 仕組み | ポイント |
|---|---|---|
| Application Load Balancer | リスナールールに「ユーザーを認証」アクション（authenticate-cognito）を設定する。未ログインの利用者はユーザープールのログイン画面に送られ、認証済みの利用者のリクエストだけがターゲットに転送される | HTTPS リスナーでのみ使える。アプリ側にログイン処理を作らずに済む。Cognito を使わず、OIDC 準拠の ID プロバイダーを直接指定する（authenticate-oidc）こともできる |
| API Gateway（REST API） | Cognito オーソライザーを設定する。リクエストのトークンを API Gateway が検証し、正しくなければ Lambda などのバックエンドを呼ばずに拒否する | バックエンドでトークンを検証するコードが不要 |
| API Gateway（HTTP API） | JWT オーソライザーで、ユーザープールが発行したトークンを検証する | — |
| AWS AppSync | GraphQL API の認可方式として、ユーザープールを指定できる | — |
「サーバーレスの API を、ログインした利用者だけに使わせたい」なら、API Gateway ＋ Cognito オーソライザーが定番の答えです。「既存の Web アプリ（ALB の背後の EC2）にログイン機能を追加したいが、コードは変えたくない」なら、ALB の認証アクションです。
IAM・IAM Identity Center との使い分け
「サインイン」に関わるサービスは複数あります。誰がサインインするのかで選びます。
| 誰が | 何のために | 使うサービス |
|---|---|---|
| 自社のアプリのお客様（エンドユーザー）。数が多く、増減も激しい | アプリにサインインする。アプリから AWS のリソースを使う | Amazon Cognito |
| 社員（ワークフォース） | 複数の AWS アカウントや業務アプリにサインインする | IAM Identity Center（Organizations のページ） |
| AWS 上のアプリ・サービス | AWS のリソースを操作する | IAM ロール（IAM のページ） |
お客様ごとに IAM ユーザーを作るのは誤りです。IAM ユーザーは長期的な認証情報を持ち、大量の利用者を管理する仕組みではありません。
問題文のキーワード → 選ぶべき答え
| 問題文の言い回し | 答えと理由 |
|---|---|
| 「モバイルアプリの利用者のサインアップ・サインイン機能を素早く追加」 | Cognito ユーザープール |
| 「Google・Facebook アカウントでログイン」「ソーシャルログイン」 | ユーザープールの外部 ID プロバイダーとのフェデレーション |
| 「アプリから S3 や DynamoDB に直接アクセス。アクセスキーを埋め込まない」 | Cognito ID プール（一時的な AWS 認証情報） |
| 「ログインしていないゲストにも一部のリソースを読ませる」 | ID プールの未認証 ID（ゲスト用の IAM ロール） |
| 「利用者ごとに S3 の自分のフォルダだけにアクセスさせる」 | ID プール ＋ IAM ポリシーの利用者 ID の変数でプレフィックスを限定 |
| 「API Gateway の API を、ログインした利用者だけに使わせる」 | Cognito オーソライザー（ユーザープール） |
| 「ALB の背後のアプリに、コードを変えずに認証を追加」 | ALB のリスナールールの認証アクション（HTTPS リスナー） |
| 「アプリの利用者に MFA を必須にする」 | ユーザープールの MFA |
| 「社員が複数の AWS アカウントにシングルサインオン」 | Cognito ではなく IAM Identity Center |
引っかけポイント
- 「ユーザープールから AWS の一時的な認証情報を直接もらう」→ ✕。ユーザープールが渡すのは JWT。AWS の認証情報は ID プールが渡す
- 「ID プールで利用者のパスワードを管理する」→ ✕。名簿とパスワードはユーザープール（または外部 ID プロバイダー）。ID プールは認証情報を交換する窓口
- 「アプリの利用者ごとに IAM ユーザーを作り、アクセスキーをアプリに入れる」→ ✕。Cognito の ID プールで一時的な認証情報を使う
- 「ALB の認証アクションを HTTP リスナーに設定する」→ ✕。認証アクションは HTTPS リスナーでのみ使える
- 「社員の AWS アカウントへのシングルサインオンに Cognito を使う」→ ✕。社員は IAM Identity Center、お客様は Cognito
まとめ: SAA 試験で押さえるポイント
- ユーザープール = 認証（名簿とサインイン、JWT を発行）、ID プール = 認可（一時的な AWS 認証情報を発行）
- ソーシャルログインや SAML・OIDC の外部 ID プロバイダーは、ユーザープールでフェデレーションしてまとめる
- アプリから AWS のサービスを直接使うなら ID プール。アクセスキーはアプリに埋め込まない。ゲストにも別のロールで権限を渡せる
- API の保護は API Gateway の Cognito オーソライザー、既存の Web アプリには ALB の認証アクション（HTTPS のみ）
- お客様は Cognito、社員は IAM Identity Center、アプリ・サービスは IAM ロール
確認問題
参考リンク
AWS 公式ドキュメント（外部サイトが開きます）。
- Amazon Cognito とは（ユーザープールと ID プール）
- Amazon Cognito ユーザープール
- サードパーティー ID プロバイダーによるユーザープールへのサインイン
- ユーザープールのトークンの使用（JWT）
- Amazon Cognito ID プール
- ID プールの IAM ロール（認証済み・未認証）
- Application Load Balancer を使用してユーザーを認証する（HTTPS リスナーのみ）
- Amazon Cognito ユーザープールをオーソライザーとして使用して REST API へのアクセスを制御する
- HTTP API の JWT オーソライザー
- AWS WAF で保護できるリソース（Cognito ユーザープールを含む）