はじめに：そのID管理、混ぜるな危険！CognitoとIdentity Centerの致命的な勘違い
AWS上でSaaSアプリケーションの認証基盤を設計する際、多くのエンジニアが一度は同じ疑問にぶつかります。
「ID管理には、Amazon CognitoとAWS IAM Identity Center（旧AWS SSO）、一体どちらを使うべきなんだ？」
この2つのサービスは、どちらも「ID」と「アクセス管理」に関連するため混同されがちですが、この問い自体が、実は致命的な勘違いに基づいています。なぜなら、CognitoとIAM Identity Centerは、解決しようとしている課題が根本的に異なるからです。
この「最初のボタン」を掛け違えると、セキュリティリスクを抱え、スケーラビリティを損なう、修正困難なアーキテクチャが出来上がってしまいます。
結論から言います。
- 顧客（テナントのエンドユーザー）の認証・認可 → Amazon Cognito
- 社内（開発者・運用者）のAWS環境へのアクセス管理 → AWS IAM Identity Center
この記事では、この大原則に基づき、両サービスの役割を明確に分離し、それぞれをSaaSアーキテクチャのどこで、どのように使うべきか、その最適解を徹底的に解説します。この記事を読めば、あなたはもう二度とSaaSのID管理で迷うことはありません。
【顧客ID管理の王道】Amazon Cognito Deep Dive
Amazon Cognitoは、あなたのSaaSアプリケーションを利用する、不特定多数のエンドユーザーのためのID管理サービスです。ユーザーのサインアップ、サインイン、プロファイル管理、パスワードリセットといった、B2C向けのあらゆる機能を提供します。
Cognitoの役割と主要機能
- User Pools: ユーザー情報を保持するメインのディレクトリです。ID/パスワードによる認証はもちろん、GoogleやFacebookといったソーシャルログイン、SAML 2.0やOpenID Connect (OIDC) に対応した外部IdP（例: Okta, Azure AD）との連携も可能です。
- Identity Pools: Cognito User Poolsや外部IdPで認証されたユーザーに対して、AWSの各種サービス（S3やDynamoDBなど）へ直接アクセスするための一時的なAWS認証情報（IAMロール）を払い出す機能です。モバイルアプリなどが直接AWSリソースを操作する際に利用されます。
SaaSにおける設計パターン
SaaSの認証基盤としてCognitoを設計する際の最重要ポイントは、テナントの分離です。
- プールモデル（推奨）: 最も一般的でコスト効率の良い方法は、単一のUser Poolを全テナントで共有し、ユーザーのカスタム属性として
custom:tenant_idを持たせる方法です。ユーザーがログインすると、Cognitoはtenant_idを含むJWTを発行します。このJWTをAPI Gateway経由でバックエンドのLambdaに渡すことで、後続の処理は常にテナントのコンテキストで実行されます。 - サイロモデル: セキュリティ要件が極めて厳しいエンタープライズテナント向けに、テナントごとに専用のUser Poolを作成するアプローチです。コストと管理のオーバーヘッドは増えますが、テナントごとのパスワードポリシー設定など、高度なカスタマイズが可能になります。
【社内ID管理の要】AWS IAM Identity Center Deep Dive
一方、AWS IAM Identity Centerは、あなたのSaaSを開発・運用する社内の開発者、運用者、サポート担当者のためのサービスです。
Identity Centerの役割と主要機能
その目的は、複数のAWSアカウントや、Salesforce、Microsoft 365といったクラウドアプリケーションへのシングルサインオン（SSO）と、一元的な権限管理を実現することです。
- 外部IdPとの連携: 多くの企業では、すでにOktaやAzure ADといったIdP（Identity Provider）で社員情報を管理しています。Identity CenterはこれらのIdPと連携し、社員は普段使っているIDとパスワードで、複数のAWSアカウントにログインできます。
- 権限セット（Permission Sets）: 「開発者ロール」「読み取り専用ロール」「請求管理者ロール」といった権限セットをあらかじめ定義しておき、それをユーザーやグループに割り当てることで、AWSアカウントへのアクセス権限を一元的に、かつきめ細かく管理できます。
SaaSにおける設計パターン
SaaSプロバイダーは通常、開発（Development）、ステージング（Staging）、本番（Production）のように、環境ごとにAWSアカウントを分離します。Identity Centerは、こうしたマルチアカウント環境の管理に絶大な効果を発揮します。
- 開発者は、自身のIdPアカウントでIdentity Centerにログインするだけで、担当プロジェクトの開発環境やステージング環境のAWSマネジメントコンソールに、適切な権限でアクセスできます。
- 本番環境へのアクセスは、より限定的な「読み取り専用ロール」や、緊急時用の「管理者ロール」に制限することで、セキュリティを担保します。
【比較表】Cognito vs Identity Center 一目でわかる違い
| 観点 | Amazon Cognito | AWS IAM Identity Center |
|---|---|---|
| 主な用途 | 顧客（エンドユーザー）の認証・認可 | 社内（開発者・運用者）の認証・認可 |
| 対象ユーザー | 不特定多数の外部ユーザー | 特定多数の内部ユーザー |
| 主要機能 | サインアップ/イン、ソーシャルログイン、JWT発行 | マルチアカウントSSO、権限セット管理 |
| 連携先 | SaaSアプリケーション | AWSマネジメントコンソール、各種SaaSアプリ |
実践的リファレンスアーキテクチャ：2つのサービスをどう組み合わせるか
セキュアなSaaSのID管理は、この2つのサービスを適切に組み合わせることで実現します。
graph TD
subgraph "SaaS顧客（テナント）"
A[エンドユーザー] --> B{SaaS Application}
B -- ログイン要求 --> C[Amazon Cognito]
C -- JWT発行 --> B
end
subgraph "SaaS提供者（社内）"
D[開発者/運用者] --> E{企業IdP (Okta/Azure AD)}
E -- SAML/OIDC --> F[AWS IAM Identity Center]
F -- SSO --> G[AWS Management Console]
F -- SSO --> H[SaaS管理ダッシュボード]
end
B -- API Call (JWT) --> I[API Gateway]
I --> J[Lambda]
J --> K[DynamoDB]
G -- AWSリソース操作 --> K
- 顧客のフロー: エンドユーザー（A）は、SaaSアプリケーション（B）のログイン画面から、Cognito（C）を使って認証されます。
- 開発者のフロー: 開発者（D）は、自社のIdP（E）経由でIAM Identity Center（F）にログインし、AWSコンソール（G）や、SaaSの内部管理用ダッシュボード（H）にアクセスします。
まとめ：適切なID管理が、セキュアなSaaSの礎となる
CognitoとIAM Identity Centerは、競合するサービスではなく、SaaSのID管理における車の両輪です。
- 顧客ID管理はCognito
- 社内ID管理はIdentity Center
この大原則を理解し、2つのサービスをそれぞれの目的に合わせて正しく使い分けること。それこそが、スケーラブルで、セキュア、かつ運用しやすいSaaS認証基盤を構築するための、最も確実な一歩なのです。
コメント