翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
コストのモニタリングと管理
他の と同様に AWS のサービス、Amazon Cognito の設定と使用状況が AWS 請求に与える影響を理解することが重要です。ユーザープールを本番環境にデプロイするための準備の一環として、アクティビティとリソースの消費のモニタリングと保護を設定します。どこを見て、どのアクションが追加コストを発生させるかがわかったら、請求書のサプライズに対する予防策を設定できます。
Amazon Cognito は、使用量の以下のディメンションに対して課金します。
-
ユーザープールの月間アクティブユーザー (MAUs)
-
OIDC または SAML フェデレーションでMAUsサインインしたユーザープール
-
MAUs 高度なセキュリティ機能を備えたユーザープール内
-
アクティブユーザープールアプリケーションクライアントと、クライアント認証情報許可によるマシンツーマシン (M2M) 認証のリクエストボリューム
-
一部のカテゴリのユーザープールのデフォルトクォータを超える購入使用量 APIs
さらに、E メールメッセージ、SMSメッセージ、Lambda トリガーなどのユーザープールの機能によって、依存サービスにコストが発生する可能性があります。概要については、Amazon Cognito の料金
コストの表示と予測
製品の発売や、最大 の新しいユーザーベースへのオープンなどの大量のイベントは、MAU数を増やし、コストに影響を与える可能性があります。新しいユーザー数を事前に見積もり、アクティビティが発生したときに監視します。クォータ容量を追加購入してボリュームに対応させたり、追加のセキュリティ対策でボリュームを制御したりする場合があります。
AWS Billing and Cost Management コンソールCognito
をフィルタリングします。詳細については、AWS Billing ユーザーガイドの「請求書の表示」を参照してください。
API リクエストレートをモニタリングするには、Service Quotas コンソールで 使用率メトリクスを確認します。例えば、クライアント認証情報リクエストは ClientAuthentication リクエストのレート として表示されます。請求書では、これらのリクエストは、それらを生成したアプリケーションクライアントに関連付けられています。この情報により、マルチテナントアーキテクチャ のテナントに公平にコストを割り当てることができます。
一定期間の M2M リクエストの数を取得するには、分析のためにAWS CloudTrail イベントを CloudWatch Logs に送信することもできます。クライアント認証情報の付与を使用してToken_POST
イベント CloudTrail をクエリします。次の CloudWatch Insights クエリは、このカウントを返します。
filter eventName = "Token_POST" and @message like '"grant_type":["client_credentials"]' | stats count(*)
のコスト管理
Amazon Cognito は、ユーザー数、機能使用状況、リクエストボリュームに基づいて請求します。以下は、Amazon Cognito のコストを管理するためのヒントです。
非アクティブなユーザーをアクティブ化しない
ユーザーをアクティブにする一般的なオペレーションは、サインイン、サインアップ、パスワードのリセットです。詳細なリストについては、「」を参照してください月次のアクティブユーザー。Amazon Cognito は、非アクティブなユーザーを請求にカウントしません。ユーザーをアクティブに設定する操作は避けてください。AdminGetUser API オペレーションの代わりに、 ListUsersオペレーションでユーザーをクエリします。非アクティブなユーザーに対して、ユーザープールオペレーションの大量の管理テストを実行しないでください。
フェデレーティッドユーザーのリンク
SAML 2.0 または OpenID Connect (OIDC) ID プロバイダーでサインインするユーザーは、ローカルユーザー よりもコストが高くなります。これらのユーザーをローカルユーザープロファイル にリンクできます。リンクされたユーザーは、フェデレーティッドユーザーに含まれる属性とアクセスを使用して、ローカルユーザーとしてサインインできます。1 か月の間に、リンクされたローカルアカウントでのみサインインOIDC IdPs する SAMLまたは のユーザーは、ローカルユーザーとして課金されます。
リクエストレートの管理
ユーザープールがクォータの上限に近づいている場合は、ボリュームを処理するための追加の容量の購入を検討してください。アプリケーション内のリクエストの量を減らすことができる場合があります。詳細については、「クォータ制限のリクエストレートを最適化する」を参照してください。
必要な場合にのみ新しいトークンをリクエストする
クライアント認証情報の付与によるマシンツーマシン (M2M) 認証は、大量のトークンリクエストに達する可能性があります。新しいトークンリクエストはそれぞれ、リクエストレートのクォータと請求書のサイズに影響します。コストを最適化するには、アプリケーションの設計にトークンの有効期限設定とトークン処理を含めます。
-
アクセストークンをキャッシュして、アプリケーションが新しいトークンをリクエストしたときに、以前に発行されたトークンのキャッシュされたバージョンを受け取るようにします。この方法を実装すると、キャッシュプロキシは、以前に取得したトークンの有効期限を認識せずにアクセストークンを要求するアプリケーションに対するガードとして機能します。キャッシュトークンは、Lambda 関数や Docker コンテナなどの有効期間の短いマイクロサービスに最適です。
-
トークンの有効期限を考慮したトークン処理メカニズムをアプリケーションに実装します。以前のトークンの有効期限が切れるまで、新しいトークンをリクエストしないでください。ベストプラクティスとして、トークンの有効期間の約 75% でトークンを更新します。このプラクティスは、アプリケーションのユーザー継続性を確保しながら、トークン期間を最大化します。
各アプリケーションの機密性と可用性のニーズを評価し、適切な有効期間でアクセストークンを発行するようにユーザープールアプリケーションクライアントを設定します。カスタムトークン期間は、認証情報のリクエストの頻度を永続的に管理できる、より長い有効期間のサーバーAPIsやサーバーに最適です。
未使用のクライアント認証情報アプリケーションクライアントを削除する
M2M 認証は、トークンリクエストのレートと、クライアント認証情報が付与されるアプリケーションクライアントの数という 2 つの要素に基づいて請求されます。M2M 認証用のアプリケーションクライアントが使用されていない場合は、それらを削除するか、クライアント認証情報を発行するための認証を削除します。アプリケーションクライアント設定の管理の詳細については、「」を参照してくださいアプリケーションクライアントでのアプリケーション固有の設定。
高度なセキュリティの管理
ユーザープールで高度なセキュリティ機能を設定する場合、高度なセキュリティ請求レートはユーザープールMAUs内のすべての に適用されます。高度なセキュリティ機能を必要としないユーザーがいる場合は、別のユーザープールに分割します。