Clerk vs AWS Cognito: Developer Experience vs Scale Economics - Part 3
Part 3 of 3. Start with Clerk vs AWS Cognito: Developer Experience vs Scale Economics.
This is the third and final part of a series comparing Clerk and AWS Cognito. Part 1 covered developer experience, and Part 2 focused on enterprise capabilities. In this part, we focus on scale economics, the cost of ownership, pricing crossover, vendor lock-in, and when to choose each platform.
Scale economics: implementation cost vs. cost of ownership
Most Clerk-vs-Cognito comparisons stop at one number: price per user. The honest comparison has two axes. Split the upfront cost of implementation from the recurring cost of ownership, then correct for the fact that Cognito bills per MAU and Clerk bills per MRU. At low-to-mid volume Clerk is often both cheaper and faster to ship. At extreme volume, Cognito's Lite tier wins on raw per-user price, if you can live with its limits.
Cost of implementation (upfront)
Implementation cost is engineering hours times a loaded rate. The hour counts below are estimates as of June 2026, drawn from vendor and agency write-ups, and they vary with team experience and scope.
For standard consumer auth (sign-in, sign-up, email verification, password reset, profile, and TOTP MFA), a managed UI gets you live fast. Building the same surface against Cognito's APIs and a custom UI takes substantially longer.
Those ranges line up across independent sources: Contra's 2026 Cognito-vs-Clerk breakdown, WorkOS estimating 40-60 hours just for a custom Cognito UI, and Supabase pegging a from-scratch auth build at 320-680 hours. The B2B gap is the widest part. Orgs, SAML, and SCIM are mostly product surface you assemble yourself on Cognito, while Clerk ships them as configured features.
Two rates, both labeled, so you can pick the one that matches how your finance team accounts for engineering. The Salary.com median for a Senior Software Developer is about $56/hr as of June 2026; from that we use $84/hr fully-loaded in-house (salary plus benefits, overhead, and taxes) and $150/hr contractor-equivalent. At $84/hr, 8 hours of Clerk consumer setup is about $672; 60 hours of Cognito setup is about $5,040. Same work, roughly a $4,400 swing before a single user signs in.
Cost of ownership over time
The bill that never stops is maintenance. A managed integration runs about 0.1 FTE, roughly 15 hours a month, mostly version bumps and config changes. Self-built or DIY auth runs higher. Duende puts ongoing build-it-yourself identity maintenance at about 0.5 to 1.0 FTE, and those are estimates as of June 2026.
Where a given Cognito deployment lands depends on how much you built. Custom UI, multi-tenancy logic, SCIM endpoints, and Lambda triggers are all code you now own and patch, which trends toward the higher end of that FTE range. Clerk shifts most of that upkeep to the vendor, so ongoing hours stay near the 0.1 FTE figure. Over a multi-year horizon, maintenance usually dwarfs the original build, which is why subscription price alone is a poor proxy for total cost.
How each platform prices and counts users
The single most misleading move in any comparison is putting Cognito's per-MAU price next to Clerk's per-MRU price as if they count the same thing. They don't.
Cognito bills per MAU (Monthly Active User): any user with an identity operation in a given month — sign-up, sign-in, sign-out, token refresh, a password change, or an attribute query. A user counts at most once per month no matter how many operations they perform, but token refresh is one of those operations, so even a silently refreshed long-lived session marks a user active and billable for that month. New user pools get a 10,000-MAU free tier (legacy pools created before November 22, 2024 keep 50,000), and federated SAML/OIDC users get only 50 free. Cognito has three tiers. Lite is the lowest per-MAU price and is feature-limited, metering at $0.0055/MAU to 100,000 users and $0.0046/MAU above that. Essentials is the default for new pools and includes managed login, email MFA, passkeys, and access-token customization. Plus adds threat protection (formerly Advanced Security Features): compromised-credentials detection, risk-based adaptive auth, IP allow/deny lists, and exportable logs.
Clerk bills per MRU (Monthly Retained User): a user who returns at least one day after signing up. Clerk's "First Day Free" model excludes sign-up-and-bounce users from the billable count. The free Hobby tier covers 50,000 MRU; Pro is $25/mo ($20 annual); Business is $300/mo ($250 annual). Overage is graduated: $0.02 per MRU from 50K-100K, $0.018 from 100K-1M, $0.015 from 1M-10M, and $0.012 above 10M. You can confirm the current numbers on Clerk's pricing page.
Here is the subscription cost only, single region, with each platform's new-pool free tiers applied. These are list subscription figures, not total cost of ownership.
The honest caveat: that table compares a MAU count against an MRU count. For any app with trial or bounce traffic, Clerk's billable count is structurally lower than a naive MAU comparison implies, because the users who sign up and never come back are excluded from MRU. So Clerk's real-world numbers in the rightmost column tend to land lower than a strict 1:1 read suggests.
A few add-ons sit outside the core table and matter at scale. Cognito Plus is +$0.005/MAU (about 33%) over Essentials and has no free tier, so teams that need threat protection pay from the first user. Basic MFA (email, SMS, TOTP) ships on Essentials and does not require Plus. Multi-region replication adds $0.0045/MAU on Essentials or $0.006/MAU on Plus per replica region and requires a multi-region KMS key. Federated MAUs bill at $0.015 with only 50 free. AWS WAF (about $5 per web ACL-month plus $1 per rule-month plus $0.60 per million requests) and customer-managed KMS keys are billed separately, not bundled. On Clerk, the B2B Authentication add-on (Enhanced tier) is $100/mo ($85 annual) and covers org-linked connections, Custom Roles and Rolesets, and unlimited org members; enterprise connections are 1 free then $75 / $60 / $30 / $15 tiered, and Directory Sync (SCIM) is bundled free with a connection.
Pricing at scale and the crossover
The interesting question is where Clerk Pro and Cognito Essentials cross. Assuming 1 MRU = 1 MAU (a deliberately conservative assumption that favors Cognito), set the two overage formulas equal in the 100K-1M band where the crossover falls:
0.018N - 775 = 0.015N - 150
0.003N = 625
N = about 208,000 usersBelow about 208,000 users, Clerk Pro is cheaper. Above it, Cognito Essentials is modestly cheaper, roughly 11-14% across the 500K-to-1M range. That is the precise, defensible claim. Cognito is not blanket-cheaper at scale.
Two things push the crossover in Clerk's favor in practice. First, the math above assumes 1 MRU equals 1 MAU; real MRU is lower than MAU because first-day bounces are excluded, so the same population of sign-ups produces a smaller Clerk bill. Second, this compares Essentials, not Plus. If you need threat protection, the right Cognito comparison is the Plus column, where Clerk stays cheaper well past 1,000,000 users.
The honest case for Cognito: AWS ecosystem savings
Cognito has a real economic edge, and it's worth stating plainly. If you're already on AWS, the savings are structural, not marketing.
Auth lands on your existing AWS invoice, which means it can draw down committed-spend discounts and Enterprise Discount Program commitments you've already negotiated, instead of becoming a new line-item vendor. Customization runs through Lambda triggers, so the same AWS skills and CI/CD your team already uses extend to auth, with no new platform to learn. Cognito identity pools issue AWS credentials natively, so granting a signed-in user scoped access to S3 or DynamoDB is a first-class flow rather than a bolt-on. And the next-generation Cognito storage infrastructure rolled out in June 2026 adds throughput headroom, with multi-region replication for cross-region disaster recovery. For an AWS-committed org running at high volume, those four factors are a genuine reason to choose Cognito.
Cost calculator
Here is a transparent model you can reproduce. Plug in your own MAU or MRU, hours, and rate.
clerk_pro_monthly = 25 + 0.02*min(max(MRU-50000,0),50000) + 0.018*max(MRU-100000,0)
cognito_essentials_mo = 0.015 * max(MAU - 10000, 0)
one_year_tco = subscription_monthly*12 + implementation_hours*rate + maintenance_hours_per_month*12*rateThe worked example below is consumer auth, Clerk Pro vs Cognito Essentials, computed at $84/hr with illustrative estimates: implementation of 8 hours for Clerk and 60 hours for Cognito (midpoints of the ranges above), and maintenance of about 15 hours/month for Clerk versus about 60 hours/month for Cognito (a deliberately conservative figure for Cognito, below the 0.5 FTE DIY floor). Subscription is the locked monthly figure times 12. All hour counts are estimates as of June 2026.
For the engineering math at $84/hr: Clerk implementation is 8 * 84 = $672; Cognito implementation is 60 * 84 = $5,040. Clerk maintenance is 15 * 12 * 84 = $15,120/yr; Cognito maintenance is 60 * 12 * 84 = $60,480/yr. To price at the $150/hr contractor rate instead, multiply every engineering figure by about 1.79 (150 / 84); subscription is unchanged.
Read the shape, not the decimals. At 10,000 and 100,000 users, engineering dominates the total and the gap favors Clerk by a wide margin. At 1,000,000 users, subscription starts to dominate: Cognito Essentials' subscription is about $28,500/yr lower, but Clerk's far lower engineering load still keeps its 1-year TCO below Essentials in this midpoint model. Push the maintenance assumption down for Cognito, or up for Clerk, and that ordering can flip, which is exactly the point. If you need rock-bottom per-user price at extreme scale and can accept its feature limits, Cognito Lite (not shown here, since this example uses Essentials) is the cheapest subscription of any option in the earlier table.
Re-run the model with your own numbers: your real MRU-to-MAU ratio, your team's hours, your blended rate, and the tier whose features you actually need. The formulas above are everything you need to rebuild it.
Vendor lock-in and data portability
Lock-in is really two questions: how hard is it to leave, and how much of your setup is frozen in place. Cognito couples your identity layer to your AWS account, freezes many user pool settings after creation, and won't export password hashes. Clerk's export includes hashed passwords and issues standards-based tokens, so leaving is a supported path rather than a one-way door.
The drawbacks of being locked into Cognito
User pools are largely immutable after creation. The settings you cannot change later include the sign-in identifier type, username case-sensitivity, required attributes, custom-attribute type and mutability, and a user's username value. Changing any of these means standing up a new user pool and migrating your users into it.
Cognito does not export password hashes. AWS documents this directly: "we don't support importing hashes." When you bulk-import users, they land in a RESET_REQUIRED state, so a naive exit forces a mass password reset on your entire user base.
Tokens are bound to your AWS account and region. The iss claim and the JWKS endpoint are both pinned to your region and pool, and refresh tokens are opaque and non-transferable. You can't lift those tokens and point them at another verifier.
Clerk's portability stance
Clerk's Dashboard CSV export includes hashed passwords, and you can pull the same data programmatically through the Backend API with getUserList(). Tokens are standards-based JWTs that any compliant library can verify. Leaving Clerk is a documented, supported path, so portability is a feature rather than a trap. See the migration overview for the export specifics, including hashed passwords.
Migrating from AWS Cognito to Clerk
Because Cognito won't return password hashes, a naive migration forces every user to reset their password. Clerk's Cognito password migrator removes that step. It lets your end users keep signing in with their existing Cognito passwords, so the cutover is invisible to them.
Here's the mechanism. You bulk-create Clerk users through the Backend API, setting password_hasher to awscognito and password_digest to the template awscognito#<POOL_ID>#<CLIENT_ID>#<identifier>. On a user's first sign-in, Clerk validates the entered password against Cognito's ALLOW_USER_PASSWORD_AUTH flow. If it checks out, the user is signed in and no reset is required.
One prerequisite matters: you need a Cognito public app client with password auth enabled, because that's what Clerk calls to validate the first sign-in. Backend API rate limits are 100 requests per 10 seconds in development and 1,000 per 10 seconds in production, so size your batch loop accordingly.
The minimal per-user create call looks like this.
import { createClerkClient } from '@clerk/backend'
const clerk = createClerkClient({ secretKey: process.env.CLERK_SECRET_KEY })
// For each user exported from your Cognito pool:
await clerk.users.createUser({
emailAddress: [email],
passwordHasher: 'awscognito',
passwordDigest: `awscognito#${POOL_ID}#${CLIENT_ID}#${cognitoUsername}`,
})Current @clerk/backend types include 'awscognito' as a valid passwordHasher, so this snippet compiles cleanly with no @ts-expect-error override — older copies of the migration guide still show one, but it is no longer needed.
The high-level shape of the migration is short:
- Export your pool's users (for example via
ListUsers). - Create a Clerk user for each one with the digest set as above.
- Validate by signing in a single known test user through your Account Portal.
- Cut over your application to Clerk.
Clerk's migration guide is the primary source for the full script and pre-flight checks. The honest framing: this turns one of Cognito's sharpest lock-in pains, the frozen password hashes, into a smooth path off Cognito.
When AWS Cognito is the better choice
Cognito is the right call in several real situations, and they're worth stating plainly.
- Your architecture is deeply AWS-native and you want identity living inside your AWS account, with IAM and identity-pool credential issuance wired into the rest of your stack.
- You operate at very high MAU volume and are willing to trade features and engineering effort for Cognito Lite's per-MAU pricing.
- You already have AWS and Cognito expertise and tooling on the team, and you value consolidation on one cloud over best-in-class auth DX.
- You need June 2026's Cognito multi-region replication for cross-region disaster recovery, or the throughput headroom of its next-generation storage infrastructure.
If your situation lands in this list, Cognito earns the choice on its own merits.
When Clerk is the better choice
Clerk fits a different center of gravity.
- Product teams that value developer experience and speed-to-market.
- B2B SaaS that needs organizations, RBAC, and enterprise SSO/SCIM without building them in-house.
- Teams that want prebuilt-but-customizable UI and current-framework SDKs (Next.js 16, React, React Router, Astro, TanStack Start, Expo).
- Teams that want a clean migration path and predictable, retention-based (MRU) billing.
- Teams operating below about 200,000 users, where Clerk is also cheaper on subscription, not only faster to build.
Conclusion
The through-line is simple. Cognito is an infrastructure primitive you assemble: a capable identity store that hands you the parts and expects you to build the product experience around them. Clerk is a product that ships the assembled experience, with the UI, SDKs, and B2B features already in the box.
Cost splits across two timeframes. Implementation cost is what you spend to get to a working, secure auth system, and that's where Clerk's DX advantage compounds. Ownership cost is what you pay to run it over years, and at extreme scale that's where Cognito Lite's per-MAU model pulls ahead.
So the fair verdict: pick Cognito if you're AWS-native or running at extreme scale, especially on Lite. Pick Clerk if you're a product team that prioritizes developer experience, B2B features, speed-to-market, and portability, and note that Clerk is also the cheaper subscription for most teams below about 200,000 users.
If you remember nothing else:
- Cognito is parts; Clerk is the assembled product.
- Cognito wins ownership cost at extreme scale on Lite; Clerk wins below about 200,000 users.
- Clerk's DX advantage shows up most in implementation cost and time-to-launch.
- Cognito freezes pool settings and won't export password hashes; Clerk's export includes them.
- Clerk's Cognito password migrator turns the exit-from-Cognito pain into a smooth, no-reset cutover.
Re-run the cost model with your own MAU, growth, and feature requirements before you decide. Every figure in this article is dated and linked to its primary source inline.
In this final part, we examined the true cost of ownership for both platforms, showing that while Cognito Lite wins on raw per-user price at extreme scale, Clerk's developer experience advantage often makes it the more economical choice for most teams. We also covered the lock-in risks of Cognito and how Clerk provides a smooth migration path.
Frequently asked questions
How do Clerk and AWS Cognito count billable users?
Cognito bills per Monthly Active User (MAU): any user who performs an identity operation in a month — including a background token refresh — counts once toward the bill. Clerk bills per Monthly Retained User (MRU) under a "First Day Free" model, so users who sign up and never return the next day are not billed. For an app with trial or bounce traffic, the MRU count is structurally lower than the MAU count for the same population of sign-ups.
Is AWS Cognito cheaper than Clerk?
It depends on scale and tier. Assuming one MRU equals one MAU, Clerk Pro is cheaper than Cognito Essentials below about 208,000 users; above that, Essentials runs roughly 11-14% cheaper through 1,000,000 users. Cognito Lite has the lowest per-user price at extreme scale but is feature-limited. Because Clerk's MRU count excludes first-day bounces, its real-world bill is usually lower than a strict 1:1 comparison implies, and below roughly 100,000 users engineering time — not subscription — dominates total cost.
Does AWS Cognito lock you into AWS?
To a meaningful degree. Many Cognito user pool settings — the sign-in identifier, username case-sensitivity, and required and custom attributes — are immutable after the pool is created, its tokens are pinned to your AWS account and region, and AWS does not export password hashes. Leaving usually means standing up a new pool or forcing a password reset. Clerk, by contrast, exports hashed passwords and issues standards-based JWTs, so migrating off it is a supported path rather than a one-way door.
Can I migrate from AWS Cognito to Clerk without forcing password resets?
Yes. AWS Cognito never exports password hashes, so a naive migration forces a mass password reset. Clerk's Cognito password migrator avoids that: you bulk-create users with passwordHasher: 'awscognito' and a passwordDigest of awscognito#<POOL_ID>#<CLIENT_ID>#<identifier>, and on each user's first sign-in Clerk validates the entered password against Cognito's ALLOW_USER_PASSWORD_AUTH flow and then re-hashes it. You need a public Cognito app client with password auth enabled, and no user has to reset a password.
When is AWS Cognito the better choice?
Cognito is a strong choice if your architecture is deeply AWS-native, you want identity to live inside your AWS account and bill on your AWS invoice, or you operate at a very high MAU volume and are willing to trade features and engineering time for the lowest per-MAU pricing on the Lite tier.
In this series
- Clerk vs AWS Cognito: Developer Experience vs Scale Economics
- Clerk vs AWS Cognito: Developer Experience vs Scale Economics - Part 2
- Clerk vs AWS Cognito: Developer Experience vs Scale Economics - Part 3 (you are here)