はじめに
AWS Solutions Architect Associate (SAA) の学習中に整理した Cognito / Directory Service 関連の知識をまとめました。
User Pools と Identity Pools の違い、Directory Service の選択フロー、IAM Identity Center との連携など、認証・認可に関する設計パターンを網羅しています。
本記事は個人の学習ノートをベースにしています。誤りがあればコメントでご指摘いただけると助かります。
サービス概要
Cognito User Pools vs Identity Pools
| User Pools | Identity Pools | |
|---|---|---|
| 目的 | ユーザー認証（サインイン / サインアップ） | AWS 一時認証情報の取得 |
| ALB 統合 | ✅ 直接統合可能 | ❌ |
| CloudFront 統合 | ❌（Lambda@Edge が必要） | ❌ |
| 出力 | JWT トークン | AWS 一時認証情報（STS） |
User Pools は「誰か確認する（認証）」、Identity Pools は「AWS リソースへのアクセス権を取得する（認可）」と覚えましょう。
AWS Directory Service の選択肢
| サービス | 用途 | 信頼関係 | ディレクトリ対応ワークロード | ユーザー数 |
|---|---|---|---|---|
| AWS Managed Microsoft AD | フル AD 機能、ハイブリッド | ✅ | ✅ | 5,000超 |
| AD Connector | オンプレ AD へのプロキシ（ログインのみ） | ❌ | ❌ | 制限なし |
| Simple AD | 基本的な AD 機能（Samba 4 ベース） | ❌ | △ | 5,000以下 |
判断フロー
信頼関係やディレクトリ対応ワークロード（SQL Server 等）が必要なら AWS Managed Microsoft AD、オンプレ AD へのログインだけなら AD Connector、基本的な AD で5,000ユーザー以下なら Simple AD です。
IAM Identity Center
- マルチアカウント SSO の一元管理
- AWS Managed AD / オンプレ AD / 外部 IdP を ID ソースとして利用可能
- Permission Sets でアカウントへのアクセス権限を一元管理
試験で問われる設計パターン
Cognito 系
ALB でユーザー認証をオフロード → Cognito User Pools + ALB
シナリオ: アプリケーション側で認証ロジックを実装せずに、ALB レベルでユーザー認証を行いたいです。どの方法が最適でしょうか？
正解: Cognito User Pools を ALB に統合
- User Pools = 認証（誰か確認）
- Identity Pools = 認可（AWS 認証情報取得）
- CloudFront と User Pools の直接統合はできない（Lambda@Edge が必要）
Directory Service 系
ディレクトリ対応ワークロード + 信頼関係 + SSO → AWS Managed Microsoft AD
シナリオ: SQL Server などのディレクトリ対応ワークロードを実行し、オンプレミスの AD と信頼関係を構築して SSO を実現したいです。どの Directory Service を選ぶべきでしょうか？
正解: AWS Directory Service for Microsoft AD
- 信頼関係・ディレクトリ対応ワークロード → Managed AD
- AD Connector はプロキシのみ（信頼関係不可）
- Simple AD は信頼関係非対応
オンプレ AD + マルチアカウント SSO → IAM Identity Center + AWS Managed AD
シナリオ: オンプレミスの AD と連携して、Organizations 内の複数アカウントに SSO でアクセスしたいです。
正解: IAM Identity Center + AWS Managed AD + 双方向信頼関係
- 双方向信頼関係 → AWS Managed AD（AD Connector は不可）
- Cognito は Web アプリ認証（マルチアカウント SSO には不向き）
API 認証系
JWT 検証 + OIDC + ネイティブ対応 + コスト効率 → API Gateway HTTP API + JWT Authorizer
シナリオ: API の認証で JWT トークンを検証したいです。ネイティブ対応でコスト効率の良い方法はどれでしょうか？
正解: API Gateway HTTP API + ネイティブ JWT Authorizer
- HTTP API は JWT Authorizer をネイティブサポート
- REST API は Lambda Authorizer が必要
- HTTP API は REST API より最大71%安い
- WebSocket API は双方向通信用
おわりに
Cognito と Directory Service は「Web アプリの認証 → Cognito」「企業の AD 連携 → Directory Service」と使い分けます。特に「User Pools = 認証、Identity Pools = 認可」「信頼関係 → Managed AD 一択」「CloudFront + User Pools = Lambda@Edge が必要」は試験の頻出ポイントです。
間違いや補足があればぜひコメントで教えてください。