Monitoring and managing costs - Amazon Cognito
Viewing and anticipating costsManaging costs

Monitoring and managing costs

Like with any other AWS service, it's important to understand the effect of your Amazon Cognito configuration and usage on your AWS bill. As part of your preparations for the deployment of user pools to production, set up monitoring and safeguards for activity and resource consumption. When you know where to look and what actions produce additional cost, you can set up precautions against surprises in your bill.

Amazon Cognito charges for the following dimensions of your usage.

  • User pool monthly active users (MAUs)

  • User pool MAUs signed in with OIDC or SAML federation

  • MAUs in a user pool with advanced security features

  • Active user pool app clients and request volume for machine to machine (M2M) authorization with client credentials grants

  • Purchased usage above default quotas for some categories of user pool APIs

Additionally, features of your user pool like email messages, SMS messages, and Lambda triggers can incur costs in dependent services. For a complete overview, see Amazon Cognito Pricing.

Viewing and anticipating costs

High-volume events like product launches and opening up to new userbases can increase your MAU count and have a cost impact. Estimate the new user count in advance and watch activity as it happens. You might find that you want to accommodate the volume with a purchase of additional quota capacity, or control the volume with additional security measures.

You can view and report on your AWS costs in the AWS Billing and Cost Management console. You can find your most recent charges for Amazon Cognito in the Billing and payments section. Under Bills, Charges by service, filter on Cognito to view your usage. For more information, see Viewing your bill in the AWS Billing User Guide.

To monitor API request rates, review the Utilization metric in the Service Quotas console. For example, client credentials requests display as Rate of ClientAuthentication requests. In your bill, these requests are associated with the app client that produced them. With this information, you can equitable allocate costs to the tenants in a multi-tenant architecture.

To get a count of M2M requests for a period of time, you can also send AWS CloudTrail events to CloudWatch Logs for analysis. Query your CloudTrail events for Token_POST events with a client credentials grant. The following CloudWatch Insights query returns this count.

filter eventName = "Token_POST" and @message like '"grant_type":["client_credentials"]' | stats count(*)

Managing costs

Amazon Cognito bills based on user count, feature usage, and request volume. The following are some tips to manage cost in Amazon Cognito,

Don't activate inactive users

Typical operations that make a user active are sign-in, sign-up, and password reset. For a more thorough list, see Monthly active users. Amazon Cognito doesn't count inactive users toward your bill. Avoid any operations that set a user active. Instead of the AdminGetUser API operation, query users with the ListUsers operation. Don't perform high-volume administrative testing of user pool operations with inactive users.

Link federated users

Users who sign in with a SAML 2.0 or OpenID Connect (OIDC) identity provider have a higher cost than local users. You can link these users to a local user profile. A linked user can sign in as a local user with the attributes and access that come with their federated user. Users from SAML or OIDC IdPs who, in the course of a month, only sign in with a linked local account are billed as local users.

Manage request rates

If your user pool is approaching the upper limit of your quota, you might consider purchasing additional capacity to handle the volume. You might be able to reduce the volume of requests in your application. For more information, see Optimize request rates for quota limits.

Request a new token only when you need one

Machine to machine (M2M) authorization with client credentials grants can reach a high volume of token requests. Each new token request has an effect on your request-rate quota and the size of your bill. To optimize cost, include token expiration settings and token handling in the design of your applications.

  • Cache access tokens so that when your application requests a new token, it receives a cached version of a previously-issued token. When you implement this method, your caching proxy acts as a guard against applications that request access tokens without awareness of the expiration of previously-acquired tokens. Caching tokens is ideal for short-lived microservices like Lambda functions and Docker containers.

  • Implement token-handling mechanisms in your applications that account for token expiration. Don’t request a new token until previous tokens are about to expire. As a best practice, refresh tokens at about 75% of the token lifetime. This practice maximizes token duration while ensuring user continuity in your application.

    Evaluate the confidentiality and availability needs of each application and configure the user pool app client to issue access tokens with an appropriate validity period. Custom token duration works best with longer-lived APIs and servers that can persistently manage the frequency of requests for credentials.

Delete unused client credentials app clients

M2M authorization bills based on two factors: the rate of token requests and the number of app clients that do client credentials grants. When app clients for M2M authorization aren’t in use, delete them or remove their authorization to issue client credentials. For more information about managing app client configuration, see Application-specific settings with app clients.

Manage advanced security

When you configure advanced security features in a user pool, the advanced security billing rate applies to all MAUs in the user pool. If you have users that don't need advanced security features, separate them into another user pool.