Amazon Cognito Pricing: Tiers, MAU Counting, and Billing
An in-depth look at Amazon Cognito pricing as of Oct 12, 2026, exploring MAU rules, tier defaults, and architectural patterns to keep bills predictable.
Stock photo for illustration only, not from the actual event
- Amazon Cognito bills based on Monthly Active Users (MAU) with higher-priced default tiers.
- Background jobs and token refreshes can inadvertently inflate monthly MAU counts.
- Free tiers are shared across an entire AWS account or organization, not per user pool.
- Legacy user pools created before November 22, 2024, retain distinct free-tier rules.
Amazon Cognito is often one of those cloud services that teams fail to budget for early on. While a generous free tier easily covers development phases, unexpected traffic spikes, data migrations, or background batch jobs touching every user can turn the Cognito line item into a substantial monthly expense.
Usually, a surprisingly high bill has little to do with genuine end-user traffic. Instead, it stems from early architectural decisions made when creating the user pool: the selected feature tier, how the application handles tokens, user import strategies, and automated jobs reading user data. All pricing figures below derive from the official Amazon Cognito pricing page as checked on October 12, 2026.
User pools are billed per monthly active user (MAU), with rates depending on the feature tier across three available levels. Unless specified otherwise, new user pools default to the Essentials tier at $0.015 per MAU, whereas Lite costs $0.0055 per MAU and drops to $0.0046 past 100,000 MAUs. This means the default tier is nearly three times more expensive than the cheapest alternative.
Stock photo for illustration only, not from the actual event
The billing page defines an MAU as any user for whom the application generates an identity operation during the calendar month. Triggering events include user sign-ins, sign-ups, password resets, attribute updates, token refreshes, and administrative API calls such as AdminGetUser. Once counted, subsequent user sessions within that month incur no additional costs.
However, unexpected costs arise from code-level patterns rather than natural user behavior. Examining background scripts, automated token refreshes, and administrative user creations reveals how hidden MAU inflation occurs across standard cloud architectures.
Understanding the exact mechanics of Cognito MAU accounting is critical for cloud cost optimization. Managed authentication services often introduce subtle billing traps through background tasks and automated synchronizations, emphasizing the need for clean caching and precise API usage strategies.
The first common pattern involves nightly reporting jobs or CRM synchronization scripts calling AdminGetUser for every single profile. This turns dormant accounts into billable MAUs. Developers can mitigate this by caching user attributes locally during sign-in or updating records via application triggers rather than repeatedly querying Cognito.
The second pattern stems from background token refreshes. Mobile applications set to refresh credentials upon launch or via background tasks will treat every installed copy as an active MAU. Restricting token refreshes solely to API calls that explicitly require fresh credentials prevents this unnecessary inflation.
"Administrative creation counts. If you move 500,000 users into a new pool with AdminCreateUser in one month, that month bills 500,000 MAUs: $7,350 on Essentials, even if most of those users never come back."
Dev.to
The third pattern involves administrative bulk creations. Migrating 500,000 users into a new pool using AdminCreateUser in a single month immediately bills 500,000 MAUs—costing $7,350 on the Essentials tier. Utilizing a Migrate User Lambda trigger ensures that users are only created and billed when they actively return to sign in.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment