コストのモニタリング - Amazon Cognito

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

コストのモニタリング

Amazon Cognito では、使用量の以下のディメンションに対して料金が発生します。

  • ユーザープールの月間アクティブユーザー (MAUs)

  • OIDC または SAML フェデレーションでサインインしたユーザープール MAUs

  • 高度なセキュリティ機能を備えたユーザープールMAUs

  • アクティブなユーザープールアプリクライアントと、クライアント認証情報付与によるマシンツーマシン (M2M) 認証のリクエストボリューム

  • 一部のカテゴリのユーザープール APIs のデフォルトクォータを超える購入使用量

さらに、E メールメッセージ、SMS メッセージ、Lambda トリガーなどのユーザープールの機能では、依存サービスにコストが発生する可能性があります。完全な概要については、Amazon Cognito の料金」を参照してください。

コストの表示と予測

AWS Billing and Cost Management コンソール で AWS コストを表示およびレポートできます。Amazon Cognito の最新の料金は、請求と支払いセクションで確認できます。請求サービス別の料金 で、 をフィルタリングCognitoして使用状況を表示します。詳細については、AWS Billing ユーザーガイドの「請求書の表示」を参照してください。

API リクエストレートをモニタリングするには、Service Quotas コンソールで使用率メトリクスを確認します。例えば、クライアント認証情報リクエストは ClientAuthentication 、リクエストのレートとして表示されます。請求書では、これらのリクエストは、それらを生成したアプリクライアントに関連付けられています。この情報により、マルチテナントアーキテクチャ のテナントに公平にコストを割り当てることができます。

一定期間の M2M リクエストの数を取得するには、分析のためにAWS CloudTrail イベントを CloudWatch Logs に送信することもできます。クライアント認証情報の付与 CloudTrail Token_POSTを使用してイベントをクエリします。次の 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 プロバイダーでサインインするユーザーは、ローカルユーザー よりもコストが高くなります。これらのユーザーをローカルユーザープロファイル にリンクできます。リンクされたユーザーは、フェデレーティッドユーザーに付属する属性とアクセスを使用して、ローカルユーザーとしてサインインできます。SAML または OIDC のユーザーが 1 か月以内に、リンクされたローカルアカウントでのみサインイン IdPs すると、ローカルユーザーとして課金されます。

リクエストレートの管理

ユーザープールがクォータの上限に近づいている場合は、ボリュームを処理するための追加容量の購入を検討してください。アプリケーション内のリクエストの量を減らすことができる場合があります。詳細については、「クォータ制限のリクエストレートを最適化する」を参照してください。

必要な場合にのみ新しいトークンをリクエストする

クライアント認証情報の付与によるマシンツーマシン (M2M) 認証は、大量のトークンリクエストに達する可能性があります。新しいトークンリクエストはそれぞれ、リクエストレートのクォータと請求書のサイズに影響します。コストを最適化するには、トークンの有効期限設定とトークン処理をアプリケーションの設計に含めます。

  • アクセストークンをキャッシュして、アプリケーションが新しいトークンをリクエストしたときに、以前に発行されたトークンのキャッシュバージョンを受け取るようにします。この方法を実装すると、キャッシュプロキシは、以前に取得したトークンの有効期限を認識せずにアクセストークンをリクエストするアプリケーションに対するガードとして機能します。キャッシュトークンは、Lambda 関数や Docker コンテナなどの有効期間の短いマイクロサービスに最適です。

  • トークンの有効期限を考慮したトークン処理メカニズムをアプリケーションに実装します。以前のトークンの有効期限が切れるまで、新しいトークンをリクエストしないでください。各アプリケーションの機密性と可用性のニーズを評価し、適切な有効期間でアクセストークンを発行するようにユーザープールアプリクライアントを設定します。カスタムトークンの有効期間は、認証情報のリクエストの頻度を永続的に管理できる存続期間の長い APIs とサーバーに最適です。

未使用のクライアント認証情報アプリケーションクライアントを削除する

M2M 認証は、トークンリクエストのレートと、クライアント認証情報を付与するアプリケーションクライアントの数という 2 つの要素に基づいて請求します。M2M 認証用のアプリケーションクライアントが使用されていない場合は、クライアント認証情報を発行するための認可を削除するか、削除します。アプリケーションクライアント設定の管理の詳細については、「」を参照してくださいユーザープールアプリクライアント

高度なセキュリティを管理する

ユーザープールでアドバンストセキュリティ機能を設定すると、アドバンストセキュリティ請求レートがユーザープール内のすべての MAUs に適用されます。高度なセキュリティ機能を必要としないユーザーがいる場合は、別のユーザープールに分割します。