Amazon CognitoとGoogle Cloud Identity Platform / Firebase Authenticationは、どちらもアプリ利用者のログインを組み込むためのマネージド型サービスです。選ぶときは、認証方式の数だけでなく、AWSのリージョンサービスとして管理するのか、Google Cloudのプロジェクトやテナントを単位に管理するのかを見ると違いをつかみやすくなります。
AWSのリージョンを基準にユーザープールを置き、ホストされたログイン画面も使いたいならAmazon Cognitoが候補です。Google Cloudのプロジェクト内に認証を組み込み、B2Bアプリでは顧客ごとの分離を明確にしたいならGoogle Cloud Identity Platform / Firebase Authenticationが合います。
Amazon Cognito
こんな人に
AWSのリージョンとユーザープールを管理の中心にしたい
Google Cloud Identity Platform / Firebase Authentication
こんな人に
Google CloudのプロジェクトやB2B向けテナントを管理の中心にしたい
| 比較点 | Amazon Cognito | Google Cloud Identity Platform / Firebase Authentication |
|---|---|---|
| 提供形態 | AWSが運用するリージョンサービス | Google Cloudプロジェクト内で有効にするマネージド認証サービス |
| ログイン画面 | サインアップ、サインイン、多要素認証、パスワード再設定に対応するmanaged login | SDKと構築済みのFirebaseUIを使ってログインの流れを構成 |
| 主な認証方式 | パスワード、パスキー、メールまたはSMSのワンタイムパスワード | メール、OAuth、電話番号、カスタム認証、OIDC、SAML |
| 多要素認証 | SMSまたは認証アプリを使うTOTPを任意または必須に設定 | Identity Platform固有機能として提供 |
| ユーザー管理 | 自己登録、管理者やAPIによる作成、CSV取り込み、グループ管理 | Admin SDKによる作成、更新、削除、取り込み、カスタム属性の管理 |
| B2Bでの分離 | グループ管理と外部IDプロバイダー連携を利用 | 顧客ごとにユーザー、IDプロバイダー、認証方式、監査・IAM、割り当て上限を分離できるマルチテナント機能 |
両者とも外部ユーザー向けアプリの認証基盤です。従業員が社内システムへ入るためのID管理とは分けて考えます。また、認証は「誰がログインしたか」を確かめる工程です。ログイン後にどのデータや操作を許可するかという権限制御は、トークンを受け取るAPIやアプリ側の設計も含めて確認する必要があります。
Amazon Cognitoのuser poolは、Webやモバイルアプリの利用者を管理するユーザーディレクトリです。選んだAWSリージョンのエンドポイントで提供されるため、認証基盤をどのリージョンに置くかをAWS側の構成と一緒に決めたい場合に整理しやすい選択肢です。
ログイン画面を一から用意したくない場合は、managed loginを利用できます。サインアップ、サインイン、多要素認証、パスワード再設定までをホストされた画面で扱えます。パスワードに加えて、パスキー、メールまたはSMSのワンタイムパスワードも選べます。
外部の認証元とは、ソーシャルログイン、SAML 2.0、OIDCで連携できます。認証後はIDトークン、アクセストークン、更新トークンが発行され、APIからトークンの失効も扱えます。ここでいうSAMLやOIDCは、別のサービスで管理しているIDを使ってログインするための標準的な連携方式です。
運用面では、利用者自身の登録だけでなく、管理者やAPIによる作成、CSVからの取り込み、グループ管理に対応します。ただし、managed loginには、利用者が自分でプロフィール属性を変更する画面までは含まれません。プロフィール編集が必要なら、アプリ側で用意する範囲に入ります。
Google Cloud Identity Platformは、アプリやサービスに認証とユーザー資格情報の管理を組み込むサービスです。Google Cloudプロジェクト内で有効にして使うため、プロジェクトを管理単位にしたい場合に選びやすくなります。
ログインの流れはSDKと構築済みのFirebaseUIを使って構成します。メールアドレスとパスワードのほか、OAuth、電話番号、カスタム認証、OIDC、SAMLを扱えます。クライアント側のSDKがIDトークンを取得・更新し、サーバー側で検証してセッションを扱う構成です。
B2Bアプリでは、マルチテナント機能が大きな判断材料になります。顧客ごとにユーザー、IDプロバイダー、認証方式、監査・IAM、割り当て上限を分けられるため、複数の顧客企業を一つのサービスで受け入れながら、認証設定を分離したい場合に向きます。
ユーザーはConsoleまたはAdmin SDKから管理でき、作成、更新、削除、取り込みに加えて、カスタム属性も扱えます。なお、テナント固有のblocking functionとアカウントリンクの無効化には対応していません。これらが要件に入る場合は、導入前に設計を照らし合わせる必要があります。
次は2026年8月7日に確認されたGLOBAL公式料金の無料入口です。MAUは、1か月の間に利用したアクティブユーザー数を指します。
| 項目 | Amazon Cognito | Google Cloud Identity Platform / Firebase Authentication |
|---|---|---|
| 無料の入口 | directまたはsocial sign-inはaccount/AWS organizationあたり月10,000 MAUのfree tier。 | email、phone、anonymous、socialのTier 1は月50,000 MAUまで無料。 |
注意
GLOBAL公式料金を基準としています。両製品とも、市場、通貨、契約周期、追加機能の料金を公開前に再確認してください。
表は一般的なログイン方法の無料入口を比べたものです。企業のID基盤と連携する場合は別に見ます。Amazon CognitoのSAML/OIDC連携は月50 MAUまで無料です。Google Cloud Identity PlatformのOIDC/SAMLにあたるTier 2もプロジェクトあたり月50 MAUまで無料で、50 MAUを超えた分は1 MAUあたり月0.015米ドルです。
追加の保護機能も費用に影響します。Amazon Cognitoでは、脅威対策などの高度なセキュリティ機能に、基本のMAU料金とは別のMAU課金があります。無料枠の大きさだけで決めず、通常のログイン、企業IDとの連携、追加保護の利用者数を分けて見積もるのがポイントです。
どちらも自社サーバーへインストールして運用する製品ではなく、クラウド側が運用するサービスです。一方で、設定までクラウド事業者へ任せられるわけではありません。
Amazon Cognitoでは、AWSの責任共有モデルに沿って、サービス側のセキュリティ対策と利用者側の設定責任を分けます。配置するAWSリージョン、許可する認証方式、多要素認証を任意にするか必須にするかを自社で決めます。
Google Cloud Identity Platformでは、Google Cloudプロジェクトを基準に認証データとアクセス制御を管理します。B2B用途なら、どの顧客をどのテナントへ分け、認証方式やIDプロバイダーをどこまで共通化するかが設計の中心になります。
Q.どちらも自社サーバーで運用できる？
A.どちらもクラウド事業者が運用するマネージド型サービスです。Amazon CognitoはAWSのリージョンサービス、Google Cloud Identity PlatformはGoogle Cloudプロジェクト内で有効にするサービスとして提供されます。
Q.B2BアプリならGoogle Cloud Identity Platform一択？
A.一択ではありません。Google Cloud Identity Platformには、顧客ごとにユーザーや認証設定などを分離するマルチテナント機能があります。Amazon Cognitoではグループ管理やSAML・OIDC連携を使えます。必要なのが顧客単位の分離なのか、外部IDとの連携なのかを先に分けてください。
Q.無料枠だけを見て選んでよい？
A.無料枠の対象が異なるため、それだけでは決められません。一般的なログインとSAML・OIDC連携を分け、追加のセキュリティ機能も含めて見積もる必要があります。
確認日: 2026-08-07（記載の各公式ページで確認。価格などは変わることがあります）
Amazon Cognito
Google Cloud Identity Platform / Firebase Authentication