翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
Amazon Cognito のクォータ
Amazon Cognito には、アカウントで実行できる操作の最大数のデフォルトクォータ (以前は制限と呼ばれていました) があります。Amazon Cognito では、Amazon Cognito リソースの最大数と最大サイズのクォータがあります。
各 Amazon Cognito クォータは、1 つの 内の 1 AWS リージョン つの 内のリクエストの最大量を表します AWS アカウント。例えば、アプリは、米国東部 (バージニア北部) のすべてのユーザープールに対して、UserAuthentication
オペレーションのデフォルトクォータ (RPS) レートまでの API リクエストを行うことができます。アジアパシフィック (東京) のアプリは、自分のリージョン内のすべてのユーザープールに対して同じ量のリクエストを生成できます。 は、一度に 1 つのリージョンでのみクォータ引き上げリクエストを許可 AWS できます。米国東部 (バージニア北部) でクォータを引き上げても、アジアパシフィック (東京) の最大リクエストレートには影響しません。
トピック
API リクエストレートクォータについて
クォータのカテゴリ
Amazon Cognito は API オペレーションの最大リクエストレート適用します。Amazon Cognito で利用できる API オペレーションの詳細については、ユーザープールとアイデンティティプールに関する API リファレンスガイドを参照してください。ユーザープールについては、これらの操作は、UserAuthentication
または UserCreation
などの一般的なユースケースのカテゴリに分類されます。ユーザープール API オペレーションのカテゴリ別リストについては、「Amazon Cognito ユーザープール API オペレーションカテゴリとリクエストレートクォータ」を参照してください。
Service Quotas コンソール
操作のクォータは、カテゴリ内のすべての操作について、1 秒あたりのリクエスト (RPS) の最大数として定義されます。Amazon Cognito ユーザープールサービスは、各カテゴリのすべての操作にクォータを適用します。例えば、カテゴリ UserCreation
には SignUp
、ConfirmSignUp
、AdminCreateUser
、および AdminConfirmSignUp
の 4 つのオペレーションが含まれます。これには合計で 50 RPS のクォータが割り当てられています。同時に複数のオペレーションが実行される場合は、オペレーションごとに最大 50 の RPS を別々に、または合わせて呼び出すことができます。
注記
カテゴリクォータはユーザープールにのみ適用されます。Amazon Cognito は、各 ID プールクォータを 1 つのオペレーションに適用します。カテゴリごとおよびオペレーションごとのリクエストレートクォータの両方で、 は、1 つのリージョン AWS アカウント の 内のすべてのユーザープールまたはアイデンティティプールからのすべてのリクエストの集計レート AWS を測定します。
リクエストレートの特別な取り扱いを使用した Amazon Cognito ユーザープール API オペレーション
オペレーションクォータは、カテゴリレベルでのリクエストの合計数で測定され、適用されますが、特別な取扱いルールが適用される AdminRespondToAuthChallenge
および RespondToAuthChallenge
オペレーションに対しては例外になります。
UserAuthentication
カテゴリには、Amazon Cognito ユーザープール API のうち、AdminInitiateAuth
、InitiateAuth
、AdminRespondToAuthChallenge
、RespondToAuthChallenge
の 4 つのオペレーションが含まれます。さらに、ホストされた UI のユーザー認証はこのクォータにカウントされます。InitiateAuth
および AdminInitiateAuth
オペレーションは、カテゴリクォータごとに測定され、施行されます。マッチングオペレーション RespondToAuthChallenge
および AdminRespondToAuthChallenge
は、別のクォータの対象であり、UserAuthentication
カテゴリの制限の 3 倍です。クォータが拡大されているので、アプリケーションで設定される複数の認証チャレンジに対応できます。このクォータは、ほとんどのユースケースに十分対応できます。アプリケーションが認証チャレンジに最大 3 つの応答を行った後は、追加のリクエストは UserAuthentication
カテゴリクォータにカウントされます。多要素認証 (MFA)、デバイス認証、カスタム認証はすべて、ユーザープールに設計する可能性のあるチャレンジプロンプトの例です。
例えば、UserAuthentication
カテゴリのクォータが 80 RPS である場合、RespondToAuthChallenge
または AdminRespondToAuthChallenge
を最大 240 RPS (3 x 80 RPS) を呼び出すことができます。ユーザープールが認証ごとに 4 ラウンドのチャレンジを要求し、1 秒あたり 70 人のユーザーがサインインした場合、合計 RespondToAuthChallenge
は 280 RPS (70 x 4) で、クォータを 40 RPS 上回ります。40 RPS が 70 回 の InitiateAuth
コールに追加されたことで、UserAuthentication
カテゴリの総使用量 は 110 RPS (40 + 70) になります。この値は、80 RPS に設定されたカテゴリクォータを 30 RPS 超えるため、Amazon Cognito はアプリケーションからのリクエストをスロットリングします。
月次のアクティブユーザー
Amazon Cognito がユーザープールの請求を計算すると、月間アクティブユーザー (MAU) ごとに料金が請求されます。クォータ引き上げリクエストの計画では、MAU 数の現在値と予測値を考慮してください。暦月内に、ユーザーに関連した ID オペレーションがある場合、そのユーザーは MAU としてカウントされます。フェデレーションユーザーをローカルユーザーにリンクする場合、MAU 数は 1 + n になります。ここで、n は、リンクされた ID でサインインしたものの数です。ユーザーをアクティブにするアクティビティには、次のものが含まれます。
-
ユーザーのサインアップまたは管理作成。ユーザー CSV のインポートは MAU 数には影響しません。
-
サインイン
-
サインアウト
-
ユーザーアカウントの確認または属性検証
-
パスワードのリセット
-
ユーザー属性、グループのメンバーシップ、または MFA 設定を変更する
-
ユーザーの詳細属性をクエリする
-
ユーザーのアクティブ化または非アクティブ化
注記
ユーザーの詳細属性のクエリというカテゴリには、API オペレーション AdminGetUser が含まれますが、ListUsers は含まれません。大規模なユーザープールのuser-by-user詳細なクエリは、 AWS 請求書に大きな影響を与える可能性があります。超過料金を回避するには、ListUsers
を使用してユーザーデータを収集するか、外部データベースにユーザー情報を保存します。
アクティブなユーザー、または暦月内にアクティブでなかったユーザーによる追加のセッションに対しては課金されません。Lite、Essentials、および Plus の利用可能なオプション間でユーザープール機能プランを変更した月では、その月の請求は、各階層の月間アクティブユーザー (MAUs) の合計から計算され、各 MAU はユーザーがアクティブだったときに割り当てられた最高価格の階層に割り当てられます。以下に例を示します。
-
月初に、ユーザープールは Plus 機能プランの対象になります。
-
ユーザー A は月の最初の日にサインインします。
-
ユーザー B は、その月の最初の日と最後の日にサインインします。
-
毎月 10 日に、機能プランを Essentials に切り替えます。
-
ユーザー C は月末にサインインします。
このシナリオでは、ユーザー A とユーザー B は Plus MAUsで、ユーザー C は Essentials MAU です。
- ライト MAU
-
ユーザープールが Lite 機能プランに含まれていたとき、少なくとも 1 か月に 1 回アクティブであり、ユーザープールが Essentials プランまたは Plus プランに含まれていたときにアクティブではなかったユーザー。
- 必須 MAU
-
ユーザープールが Essentials 機能プランに含まれていたときに 1 か月に少なくとも 1 回アクティブだったが、ユーザープールが Plus プランに含まれていたときにアクティブではなかったユーザー。
- プラス MAU
-
ユーザープールが Plus プランにあったときに、少なくとも 1 か月に 1 回アクティブだったユーザー。
詳細については、「ユーザープール機能プラン」を参照してください。
API リクエストレートクォータ
クォータ要件を特定する
重要
UserAuthentication
、UserCreation
、または AccountRecovery
のようなカテゴリに対して Amazon Cognito クォータを引き上げた場合に、他の AWS のサービスのクォータを引き上げる必要が生じることがあります。例えば、Amazon Cognito が Amazon Simple Notification Service (Amazon SNS) または Amazon Simple Email Service (Amazon SES) で送信するメッセージは、これらのサービスでリクエストレートのクォータが不十分な場合に失敗することがあります。
クォータ要件を計算するには、特定の期間内にアプリケーションとやり取りするアクティブなユーザーの数を判断します。例えば、アプリケーションに 8 時間の期間内に平均 100 万人のアクティブユーザーによるサインインがあることを想定する場合、1 秒あたり平均 35 人のユーザーを認証できる必要があります。
さらに、平均的なユーザーセッションが 2 時間であると仮定し、トークンが 1 時間後に期限切れになるように設定している場合、各ユーザーは、セッション中にトークンを 1 回更新する必要があります。この負荷をサポートするために UserAuthentication
カテゴリに必要な平均クォータは 70 RPS になります。
8 時間の期間内でのユーザーのサインイン頻度の変動を考慮して、ピーク対平均の比を 3:1 と仮定する場合、望ましい UserAuthentication
クォータは 200 RPS にする必要があります。
注記
ユーザーアクションごとに複数のオペレーションを呼び出す場合は、カテゴリレベルで個々のオペレーションのコールレートを合計する必要があります。
クォータ制限のリクエストレートを最適化する
API レート制限を増やすと AWS 請求にコストがかかるため、クォータの引き上げをリクエストする前に、使用量モデルの調整を検討してください。以下は、リクエストレートを最適化するアプリケーションアーキテクチャの例です。
- バックオフ待機期間後に再試行する
-
API コールごとにエラーをキャッチし、バックオフ期間後に再試行することができます。バックオフアルゴリズムは、ビジネスのニーズと負荷に応じて調整できます。Amazon SDK には、組み込みの再試行ロジックがあります。詳細については、「構築するツール」を参照してください AWS。
- 頻繁に更新される属性に外部データベースを使用する
-
アプリケーションが、カスタム属性の読み取りと書き込みにユーザープールへの複数のコールを必要とする場合は、外部ストレージを使用します。優先データベースを使用してカスタム属性を保存する、またはキャッシュレイヤーを使用してサインイン時にユーザープロファイルをロードすることができます。このプロファイルは、ユーザープールからユーザープロファイルを再ロードしないでも、必要に応じてキャッシュから参照することができます。
- クライアント側で JSON ウェブトークン (JWT) を検証する
-
アプリケーションは、JWT トークンを信頼する前にそれらを検証する必要があります。トークンの署名と有効期間は、API リクエストをユーザープールに送信することなく、クライアント側で検証できます。トークンが検証されたら、トークン内のクレームを信頼して、さらに多くの
getUser
API コールを実行せずにクレームを使用することができます。詳細については、「JSON Web トークンの検証」を参照してください。 - 待合室でウェブアプリケーションへのトラフィックを調整する
-
試験の受験やライブイベントへの参加など、時間が限られているイベント中に多数のユーザーがサインインするトラフィックが予想される場合は、セルフスロットリングメカニズムを使用してリクエストトラフィックを最適化できます。例えば、セッションが利用可能になるまでユーザーが待機できる待合室を設定して、使用可能な容量がある間にリクエストを処理できます。待合室のリファレンスアーキテクチャについては、「AWS Virtual Waiting Room
」を参照してください。 - JWT のキャッシング
-
アクセストークンの有効期限が切れるまで再利用します。API Gateway でトークンキャッシングを使用するフレームワークの例については、「ユーザープールトークンの有効期限とキャッシュの管理」を参照してください。ユーザー情報をクエリする API リクエストを生成する代わりに、ID トークンを有効期限が切れるまでキャッシュし、キャッシュからユーザー属性を読み取ります。
での API リクエストレートの操作の詳細については AWS、「ワークロードでの API スロットリングの管理とモニタリング
クォータの使用状況を追跡する
Amazon Cognito では、アカウントレベルでの各 API オペレーションカテゴリの Amazon CloudWatch の CallCount
および ThrottleCount
メトリクスが生成されます。お客様が実行するカテゴリ関連のコールの合計数を追跡するには、CallCount
を使用できます。カテゴリ関連のスロットルされたコールの合計数は、ThrottleCount
を使用して追跡できます。カテゴリ内のコールの合計数を計上するには、Sum
統計で CallCount
および ThrottleCount
メトリクスを使用できます。詳細については、「Amazon CloudWatch メトリクスを使用する」を参照してください。
サービスクォータをモニタリングする場合、使用率 は使用中のサービスクォータの割合です。例えば、クォータの値が 200 リソースで 150 リソースが使用中の場合、使用率は 75% です。使用状況 は、サービスクォータに対する使用中のリソースまたはオペレーションの数です。
CloudWatch メトリクスを使用した使用状況の追跡
CloudWatch を使用して、Amazon Cognito ユーザープールの使用率メトリクスを追跡し、収集することができます。CloudWatch ダッシュボードには AWS のサービス 、使用するすべての に関するメトリクスが表示されます。CloudWatch を使用すると、メトリクスアラームを作成して通知を受けたり、モニタリングしている特定のリソースを変更したりできます。CloudWatch メトリクスの詳細については、「CloudWatch と Service Quotas でのクォータと使用状況の追跡」を参照してください。
Service Quotas メトリクスを使用した使用率の追跡
Amazon Cognito ユーザープールは、サービスクォータの使用状況を表示して管理するためのコンソールインターフェイスである Service Quotas と統合されています。Service Quotas コンソールでは、特定のクォータの値を調べること、モニタリング情報を表示すること、クォータの引き上げをリクエストすること、および CloudWatch アラームをセットアップすることができます。アカウントがアクティブ状態になってからしばらくすると、リソース使用率のグラフを表示できます。
Amazon Cognito ユーザープール
月間アクティブユーザー数 (MAU) を追跡する
ユーザープール内の月間アクティブユーザー (MAU) の数は、リクエストレートクォータの引き上げに関する計画に対して重要なデータを提供します。API リクエストレートを、特定の期間においてアクティブであったユーザーの数と比較できます。このデータがあれば、アプリケーションのアクティブユーザーの増加が、使用状況モデルのクォータにどのように影響するかを計算できます。例えば、米国西部 (オレゴン) 内のアプリケーション全体で 1 か月のアクティブユーザーが 200 万人になり、UserAuthentication
カテゴリが 120 リクエスト/秒 (RPS) のデフォルトクォータで時折スロットリングエラーを受け取ったとします。広告キャンペーンが成功する前の 1 か月間は、100 万 MAU であって、アプリケーションが 80 RPS を超えることはなかったとします。新しいテレビスポットを実施した結果として同様の急増が予想される場合は、ユーザー増加分の 100 万人に対応するために追加の 40 RPS を購入して、調整後のクォータが 160 RPS になるようにできます。
MAU を確認するには
[AWS Billing
コンソール]
クォータ引き上げのリクエスト
Amazon Cognito には、それぞれのユーザープールと ID プールで実行できる 1 秒あたりの最大オペレーション数のクォータがあります AWS リージョン。調整可能な Amazon Cognito ユーザープール API リクエストレートクォータの引き上げを購入できます。現在のクォータを確認し、Service Quotas コンソールで、または Service Quotas API オペレーションの ListAWSDefaultServiceQuotas
と RequestServiceQuotaIncrease
を用いて引き上げを購入します。
-
Service Quotas コンソールを使用してクォータの引き上げを購入するには、「Service Quotas ユーザーガイド」の「Requesting a API quota increase」を参照してください。
-
AWS は、クォータ引き上げリクエストを 10 日以内に完了することを目標としています。ただし、いくつかの考慮事項により、リクエストの処理期間が 10 日を超える場合があります。例えば、リクエストによっては Amazon Cognito が追加のハードウェア容量をプロビジョニングする必要が生じたり、リクエストボリュームの季節的な増加により遅延が発生する場合もあります。
-
Service Quotas でクォータが利用できない場合は、Service limit increase フォーム
を使用してください。
重要
クォータは、調整可能なもののみを引き上げることができます。クォータ容量の引き上げ分を購入する必要があります。クォータ引き上げ分の料金については、「Amazon Cognito 料金
Amazon Cognito ユーザープール API オペレーションカテゴリとリクエストレートクォータ
Amazon Cognito には、認可モデルが異なる API オペレーションのクラスが重複しているため、各オペレーションはいずれかのカテゴリに属します。各カテゴリには、アカウント内の 1 つの AWS リージョン 内のすべてのユーザープールで、すべてのメンバー API オペレーションに対して独自のプールされたクォータがあります。調整可能なカテゴリのクォータについてのみ、引き上げをリクエストできます。詳細については、「クォータ引き上げのリクエスト」を参照してください。クォータ調整は、単一リージョンのアカウント内のユーザープールに適用されます。Amazon Cognito では、一部のカテゴリ3でのオペレーションを制限し、ユーザープールごとのリクエスト数/秒 (RPS) を 5 にしています。デフォルトクォータ (RPS) は、 AWS アカウント内のすべてのユーザープールに追加で適用されます。
注記
各カテゴリのクォータは、月間アクティブユーザー数 (MAU) で測定されます。MAU が 200 万未満の AWS アカウント は、デフォルトのクォータ内で動作できます。MAU が 100 万未満で、Amazon Cognito がリクエストをスロットリングしている場合は、アプリケーションの最適化を検討してください。詳細については、「クォータ制限のリクエストレートを最適化する」を参照してください。
カテゴリオペレーションクォータは、1 つの AWS リージョン内のユーザープールのすべてのユーザーに適用されます。Amazon Cognito は、アプリが 1 人のユーザーに対して生成できるリクエストの数にも制限を設けています。ユーザーごとの API リクエストを以下のテーブルに示すとおり、制限する必要があります。
Amazon Cognito ユーザープールのユーザーあたりのリクエストレートクォータ
Operation | ユーザーあたりのオペレーション数 (1 秒あたりのオペレーション数) |
---|---|
読み込みユーザープロファイル 例: |
10 |
書き込みユーザープロファイル 例: |
10 |
次の表に示すとおり、カテゴリ別の API リクエストを制限する必要があります。
Amazon Cognito ユーザープールのカテゴリごとのリクエストレートクォータ
カテゴリ | 説明 | デフォルトクォータ (RPS) | 調整可能 |
---|---|---|---|
UserAuthentication
|
ユーザーを認証 (サインイン) するオペレーション。 これらのオペレーションは リクエストレートの特別な取り扱いを使用した Amazon Cognito ユーザープール API オペレーション の対象となります。 |
120 | はい |
UserCreation |
Amazon Cognito ローカルユーザーを作成または確認するオペレーション。これは、Amazon Cognito ユーザープールによって直接作成され、検証されるユーザーです。 | 50 | あり |
UserFederation サードパーティー ID プロバイダーを使用してユーザーを Amazon Cognito ユーザープールにフェデレート (認証) するオペレーション。 |
ユーザープールフェデレーションエンドポイントに IdP レスポンスを送信するオペレーション。IdP トークンを生成する OIDC またはソーシャルプロバイダーのオペレーション、およびすべての SAML リクエストが、このクォータに寄与します。 | 25 | はい |
UserAccountRecovery |
ユーザーのアカウントを回復する、またはユーザーのパスワードを変更もしくは更新するオペレーション。 | 30 | いいえ |
UserRead |
ユーザープールからユーザーを取得する操作。 | 120 | あり |
UserUpdate |
ユーザーとユーザー属性を管理するために使用するオペレーション。 | 25 | いいえ |
UserToken |
トークン管理のオペレーション | 120 | あり |
UserResourceRead |
記憶されているデバイスやグループメンバーシップなどのユーザーリソース情報を Amazon Cognito から取得するオペレーション。 | 50 | はい |
UserResourceUpdate |
記憶されているデバイスやグループメンバーシップなど、ユーザーのリソース情報を更新するオペレーション。 | 25 | いいえ |
UserList |
ユーザーのリストを返す操作。 | 30 | いいえ |
UserPoolRead |
ユーザープールを読み取る操作。 | 15 | いいえ |
UserPoolUpdate |
ユーザープールを作成、更新、または削除するオペレーション。 | 15 | いいえ |
UserPoolResourceRead |
ユーザープールからグループやリソースサーバーなどのリソースに関する情報を取得するオペレーション。3 | 20 | いいえ |
UserPoolResourceUpdate |
ユーザープールのグループやリソースサーバーなどのリソースを変更するオペレーション。3 | 15 | いいえ |
UserPoolClientRead |
ユーザープールクライアントに関する情報を取得するオペレーション。3 | 15 | いいえ |
UserPoolClientUpdate |
ユーザープールクライアントを作成、更新、削除するオペレーション。3 | 15 | いいえ |
ClientAuthentication トークンエンドポイントに対する |
マシン間リクエストの承認に使用される認証情報を生成するオペレーション | 150 | いいえ |
1 A RespondToAuthChallenge
または AdminRespondToAuthChallenge
レスポンスで、NEW_PASSWORD_REQUIRED
の ChallengeName
があるものは、UserAccountRecovery
カテゴリにカウントされます。他のすべてのチャレンジレスポンスは、UserAuthentication
カテゴリにカウントされます。
2 サインイン中のホストされた UI オペレーションごとに 1 つのリクエストとして、クォータにカウントされます。例えば、サインインして MFA コードを入力したユーザーは 2 つのリクエストとしてカウントされます。許可コード付与でのトークンの引き換えには、UserAuthentication
カテゴリのクォータと同じレートで追加のクォータ割り当てが適用されます。
3 このカテゴリの個々のオペレーションには、単一のユーザープールに対して 5 RPS を超えるレートでオペレーションが呼び出されないようにする制約があります。
Amazon Cognito ID プール (フェデレーティッドアイデンティティ) API オペレーションリクエストレートのクォータ
Operation | 説明 | デフォルトクォータ (RPS)1 | 調整可能 | クォータ引き上げの対象 |
---|---|---|---|---|
GetId |
ID プールからアイデンティティ ID を取得します。 | 25 | あり | アカウントチームにお問い合わせください。 |
GetOpenIdToken |
クラシックワークフローの ID プールから OpenID トークンを取得します。 | 200 | はい | アカウントチームにお問い合わせください。 |
GetCredentialsForIdentity |
拡張ワークフローの ID プールから AWS 認証情報を取得します。 | 200 | はい | アカウントチームにお問い合わせください。 |
GetOpenIdTokenForDeveloperIdentity |
デベロッパーワークフローの ID プールから OpenID トークンを取得します。 | 50 | あり | アカウントチームにお問い合わせください。 |
ListIdentities |
アイデンティティプール内の ID のリストを取得します。 | 5 | あり | アカウントチームにお問い合わせください。 |
DeleteIdentities |
アイデンティティプールから登録した ID を 1 つ以上削除します。 | 10 | [Yes (はい)] | アカウントチームにお問い合わせください。 |
TagResource |
アイデンティティプールにタグを適用します。 | 5 | あり | アカウントチームにお問い合わせください。 |
UntagResource |
アイデンティティプールからタグを削除します。 | 5 | あり | アカウントチームにお問い合わせください。 |
ListTagsForResource |
アイデンティティプールに適用されたタグのリストを表示します。 | 10 | [Yes (はい)] | アカウントチームにお問い合わせください。 |
1 デフォルトのクォータは、 AWS リージョン 内の任意の の ID プールの最小リクエストレートクォータです AWS アカウント。リージョンによっては RPS クォータが高くなる場合があります。
リソースの番号とサイズのクォータ
リソースクォータは、Amazon Cognito のリソース、入力フィールド、期間、およびその他の機能の最大数またはサイズです。
一部のリソースクォータの調整は、サービスクォータコンソールまたはサービス制限の引き上げフォーム
注記
リージョンあたりのユーザープールなど、 AWS アカウント レベルのリソースクォータは、それぞれの Amazon Cognito リソースに適用されます AWS リージョン。例えば、米国東部 (バージニア北部) に 1,000 個のユーザープールを持ち、欧州 (ストックホルム) に別の 1,000 個のユーザープールを持つことができます。
次の表は、デフォルトのリソースクォータと、それらが調整可能かどうかを示しています。
Amazon Cognito ユーザープールのリソースクォータ
リソース | クォータ | 調整可能 | 最大クォータ |
---|---|---|---|
ユーザープールあたりのアプリケーションクライアント | 1,000 | あり | 10,000 |
リージョンごとのユーザープール | 1,000 | あり | 10,000 |
ユーザープールあたりのアイデンティティプロバイダー | 300 | あり | 1,000 |
ユーザープールあたりのリソースサーバー | 25 | あり | 300 |
ユーザープールあたりのユーザー数 | 40,000,000 | あり | アカウントチームにお問い合わせください。 |
トークン生成前の Lambda トリガーの合計変更数1 | 5,000 | あり | アカウントチームにお問い合わせください。 |
ユーザープールあたりのマネージドログインブランドスタイル | 10 | いいえ | 該当なし |
ユーザープールあたりのカスタム属性数 | 50 | いいえ | 該当なし |
属性あたりの文字数 | 2,048 バイト | いいえ | 該当なし |
カスタム属性名の文字数 | 20 | いいえ | 該当なし |
パスワードポリシーに最低限必要なパスワード文字数 | 6~99 | いいえ | 該当なし |
ごとに毎日送信される E メールメッセージ AWS アカウント2 | 50 | いいえ | 該当なし |
E メール件名の文字数 | 140 | いいえ | 該当なし |
E メールメッセージの文字数 | 20,000 | いいえ | 該当なし |
SMS 検証メッセージの文字数 | 140 | いいえ | 該当なし |
パスワードの文字数 | 256 | いいえ | 該当なし |
ID プロバイダー名の文字数 | 32 | いいえ | 該当なし |
SAML レスポンスの文字 | 100,000 | いいえ | 該当なし |
ID プロバイダーあたり識別子数 | 50 | いいえ | 該当なし |
ユーザーにリンクされた ID 数 | 5 | いいえ | 該当なし |
アプリケーションクライアントあたりのコールバック URL 数 | 100 | いいえ | 該当なし |
アプリケーションクライアントあたりのログアウト URL 数 | 100 | いいえ | 該当なし |
リソースサーバーあたりのスコープ | 100 | いいえ | 該当なし |
アプリケーションクライアントあたりのスコープ数 | 50 | いいえ | 該当なし |
アカウントあたりのカスタムドメイン数 | 4 | いいえ | 該当なし |
各ユーザーが所属できるグループ数 | 100 | いいえ | 該当なし |
ユーザープールあたりのグループ | 10,000 | いいえ | 該当なし |
1 このクォータは、トークン生成前の Lambda トリガー からのトークンで発生する場合があります。トランザクション 1 つにおけるアクセストークンと ID トークンの既存および追加のクレームとスコープの数の合計は、このクォータ以下になる必要があります。抑制されたクレームとスコープは、このクォータには加算されません。
2 このクォータは、Amazon Cognito ユーザープールでデフォルトの E メール機能を使用している場合にのみ適用されます。E メールの配信ボリュームがより高い場合は、Amazon SES の E メール設定を使用するようにユーザープールを設定します。詳細については、「Amazon Cognito ユーザープールの E メール設定」を参照してください。
Amazon Cognito ユーザープールセッションの有効性パラメータ
トークン | クォータ |
---|---|
ID トークン | 5 分~1 日 |
更新トークン | 1 時間~3,650 日 |
アクセストークン | 5 分~1 日 |
ホストされた UI セッション cookie | 1 時間 |
認証セッショントークン | 3 分~15 分 |
Amazon Cognito ユーザープールコードセキュリティリソースクォータ (調整不可)
リソース | クォータ |
---|---|
サインアップ確認コードの有効期間 | 24 時間 |
ユーザー属性検証コードの有効期間 | 24 時間 |
多要素認証 (MFA) コードの有効期間 | 3~15 分 |
パスワードを忘れた場合のコードの有効期間 | 1 時間 |
ユーザーあたりの ConfirmForgotPassword および ForgotPassword リクエストの最大数/時間1 |
5~20 |
ユーザーあたりの ResendConfirmationCode リクエストの最大数/時間 |
5 |
ユーザーあたりの ConfirmSignUp リクエストの最大数/時間 |
15 |
ユーザーあたりの ChangePassword リクエストの最大数/時間 |
5 |
ユーザーあたりの GetUserAttributeVerificationCode リクエストの最大数/時間 |
5 |
ユーザーあたりの VerifyUserAttribute リクエストの最大数/時間 |
15 |
1 Amazon Cognito は、パスワード更新リクエストのリスク要因を評価し、評価したリスクレベルに応じたクォータを割り当てます。詳細については、「パスワードを忘れた場合の対応」を参照してください。
Amazon Cognito ユーザープールへのユーザーインポートジョブのリソースクォータ
リソース | クォータ | 調整可能 | 最大クォータ |
---|---|---|---|
ユーザープールあたりのユーザーインポートジョブ | 1,000 | あり | アカウントチームにお問い合わせください。 |
ユーザーインポート CSV 行あたりの最大文字数 | 16,000 | いいえ | 該当なし |
最大 CSV ファイルサイズ | 100 MB | いいえ | 該当なし |
CSV ファイルあたりのユーザーの最大数 | 500,000 | いいえ | 該当なし |
Amazon Cognito ID プール (フェデレーティッドアイデンティティ) リソースのクォータ
リソース | クォータ | 調整可能 | 最大クォータ |
---|---|---|---|
アカウントあたりのアイデンティティプール | 1,000 | あり | 該当なし |
ID プールあたりの Amazon Cognito ユーザープールプロバイダー数 | 50 | あり | 1,000 |
ID プール名の文字長 | 128 バイト | いいえ | 該当なし |
ログインプロバイダー名の文字長 | 2,048 バイト | いいえ | 該当なし |
ID プールあたりのアイデンティティ数 | 無制限 | いいえ | 該当なし |
ロールマッピングを指定できる ID プロバイダー数 | 10 | いいえ | 該当なし |
単一のリストまたは lookup コールからの結果の数 | 60 | いいえ | 該当なし |
ロールベースのアクセス制御 (RBAC) ルール | 25 | いいえ | 該当なし |
Amazon Cognito Sync リソースクォータ
リソース | クォータ | 調整可能 | 最大クォータ |
---|---|---|---|
アイデンティティあたりのデータセット | 20 | あり | アカウントチームにお問い合わせください。 |
データセットあたりのレコード | 1,024 | あり | アカウントチームにお問い合わせください。 |
1 つのデータセットのサイズ | 1 MB | あり | アカウントチームにお問い合わせください。 |
データセット名の文字数 | 128 バイト | いいえ | 該当なし |
正常なリクエスト後の一括発行の待機時間 | 24 時間 | いいえ | 該当なし |