翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # マルチテナントアプリケーションのベストプラクティス Amazon Cognito ユーザープールは、Amazon Cognito クォータ内に収める必要がある大量のリクエストを生成するマルチテナントアプリケーションで動作します。顧客ベースが拡大したときにこの容量をスケールアップするには、[追加のクォータ容量を購入](quotas.md#managing-request-rate-quotas.title)できます。 **注記** Amazon Cognito [クォータ](https://docs.aws.amazon.com/cognito/latest/developerguide/limits.html)は、 AWS アカウント および ごとに適用されます AWS リージョン。これらのクォータは、アプリケーション内のすべてのテナント間で共有されます。Amazon Cognito サービスクォータをチェックして、クォータがアプリケーションの想定されるボリュームとテナント数に対応できることを確認してください。 このセクションでは、同じリージョン および 内の Amazon Cognito リソース間でテナントを分離するために実装できる方法について説明します AWS アカウント。テナントを複数の AWS アカウント またはリージョンに分割し、それぞれに独自のクォータを与えることもできます。マルチリージョンマルチテナンシーのその他のメリットには、可能な限り高い分離レベル、グローバルに分散されたユーザーに対する最短ネットワーク転送時間、組織の既存のディストリビューションモデルへの準拠などがあります。 単一リージョンのマルチテナンシーは、顧客や管理者にとってもメリットがあります。 次のリストは、共有リソースを使用したマルチテナンシーのメリットの一部を示しています。マルチテナンシーのメリット **共通ユーザーディレクトリ** マルチテナンシーは、顧客が複数のアプリケーションにアカウントを持つモデルをサポートします。[サードパーティープロバイダーの ID をリンク](cognito-user-pools-identity-federation.md#cognito-user-pools-identity-federation.title)する先を 1 つの一貫したユーザープールプロファイルすることができます。ユーザープロファイルがテナントに固有である場合、単一のユーザープールを持つマルチテナンシー戦略では、ユーザー管理へのエントリポイントは 1 つになります。 **共通セキュリティ** 共有ユーザープールでは、単一のセキュリティ標準を作成し、同じ[脅威保護](cognito-user-pool-settings-threat-protection.md#cognito-user-pool-settings-threat-protection.title)、[多要素認証](user-pool-settings-mfa.md#user-pool-settings-mfa.title) (MFA)、および [AWS WAF](user-pool-waf.md#user-pool-waf.title) 標準をすべてのテナントに適用できます。 AWS WAF ウェブ ACL は関連付けるリソース AWS リージョン と同じ に存在する必要があるため、マルチテナンシーは複雑なリソースへの共有アクセスを提供します。マルチリージョン Amazon Cognito アプリケーションで一貫したセキュリティ設定を維持する場合は、リソース間で設定を複製する運用標準を適用する必要があります。 **共通カスタマイズ** ユーザープールと ID プールは でカスタマイズできます AWS Lambda。ユーザープールでの [Lambda トリガー](cognito-user-pools-working-with-lambda-triggers.md#cognito-user-pools-working-with-lambda-triggers.title)の設定や、アイデンティティプールでの [Amazon Cognito イベント](cognito-events.md#cognito-events.title)の設定は、複雑になる可能性があります。Lambda 関数は、ユーザープールまたは ID プール AWS リージョン と同じ にある必要があります。共有 Lambda 関数は、カスタム認証フロー、ユーザー移行、トークン生成、リージョン内の他の関数について標準を適用できます。 **共通メッセージング** Amazon Simple Notification Service (Amazon SNS) では、ユーザーに [SMS メッセージ](user-pool-sms-settings.md#user-pool-sms-settings.title)を送信する前に、特定のリージョンでの追加の設定が必要になります。特定のリージョン内に含まれる、Amazon Simple Email Service (Amazon SES) で検証済みの ID とドメインを使用して [E メールメッセージ](user-pool-email.md#user-pool-email.title)を送信できます。 マルチテナンシーを使用すると、この設定とメンテナンスのオーバーヘッドをすべてのテナント間で共有できます。Amazon SNS と Amazon SES はすべての AWS リージョンで利用できるわけではないため、リソースをリージョン間で分割するには追加の考慮事項が必要になります。 [カスタムメッセージングプロバイダー](user-pool-lambda-custom-sender-triggers.md#user-pool-lambda-custom-sender-triggers.title)を使用すると、メッセージ配信の管理に単一の Lambda 関数を使用し、*共通カスタマイズ*を適用できます。 [[マネージドログイン]](cognito-user-pools-managed-login.md#cognito-user-pools-managed-login.title) は、ブラウザにセッション Cookie を設定し、認証済みのユーザーを認識します。ユーザープール内の*ローカルユーザー*を認証する場合、ローカルユーザーのセッション Cookie は、同じユーザープール内のすべてのアプリケーションクライアントに対してユーザーを認証します。ローカルユーザーは、外部 IdP を介したフェデレーションなしに、ユーザープールディレクトリにのみ存在します。セッション Cookieは 1 時間有効です。セッション Cookie の有効期間を変更することはできません。 ホストされた UI セッション Cookie を使用した複数のアプリケーションクライアント間でのサインインを防ぐには、2 つの方法があります。 + ユーザーをテナントごとのユーザープールに分割します。 + ホストされた UI サインインを Amazon Cognito ユーザープール API サインインに置き換えます。 **Topics** + [ユーザープールマルチテナンシーのベストプラクティス](bp_user-pool-based-multi-tenancy.md) + [アプリケーションクライアントマルチテナンシーのベストプラクティス](application-client-based-multi-tenancy.md) + [ユーザーグループのマルチテナンシーのベストプラクティス](group-based-multi-tenancy.md) + [カスタム属性マルチテナンシーのベストプラクティス](custom-attribute-based-multi-tenancy.md) + [カスタムスコープマルチテナンシーのベストプラクティス](scope-based-multi-tenancy.md) + [マルチテナンシーのセキュリティに関する推奨事項](multi-tenancy-security-recommendations.md)