In May 2024, AWS announced it would start charging for machine-to-machine (M2M) authentication in Cognito. In June 2025, we wrote about it when the bills started landing in The AWS Cognito Bill Has Come Due: What You Need to Know. In November 2025, AWS quietly walked the most painful part back.
Here’s the complete story — what happened, what AWS changed, what Cognito M2M actually costs today, and what it means if your team made architecture decisions based on the original pricing.
What AWS Originally Announced
The May 2024 pricing change introduced two new cost dimensions for Cognito M2M (the OAuth 2.0 client credentials flow that lets backend services authenticate with each other without a human in the loop):
- $6 per month per app client — every service that authenticates gets its own app client, billed monthly regardless of usage
- $0.00225 per 1,000 token requests — every time a service authenticates and gets a token
The per-client fee was the killer. A modest microservices architecture — say, 19 services total — meant $114/month before a single token was issued. Add token requests and you landed at $200–400/month for a setup that cost nothing six months earlier.
For teams running distributed architectures with dozens of services, the math got uncomfortable fast. AWS’s own example showed how certain configurations could add $2,500/month. The community reaction was strong and sustained.
What AWS Changed in November 2025
AWS removed the per-app-client pricing dimension entirely.
No more $6/month per service. No minimum charge for having app clients registered. The only M2M cost that remains is the per-token-request fee: $0.00225 per 1,000 successful token requests.
For the same 19-service architecture in our original example — with each service authenticating 100 times per day — the monthly token request cost is roughly $0.13. That’s not a typo. The cost that was previously $114/month in client fees alone is now effectively zero.
The per-token cost is still real and can compound at scale. But the pricing model is now aligned with actual usage rather than taxing you for architectural decisions you made years ago.
If Your Team Migrated Away
Some teams used the grace period to move off Cognito M2M entirely — switching to IAM roles with SigV4 signing for internal service auth, standing up self-hosted alternatives like Keycloak, or rearchitecting to reduce service count. If that’s you, a few things worth knowing:
The IAM roles migration is worth keeping. For services running entirely within your AWS environment — on EC2, ECS, or Lambda — IAM roles with SigV4 signing are the right architectural pattern regardless of Cognito’s pricing. Service identity through IAM means you get CloudTrail logging of every API call, least-privilege enforcement through IAM policies, and zero per-request auth costs.
Cognito for user auth remains strong. The per-client pricing change never touched user pool MAU pricing. If you split your auth strategy — IAM for internal M2M, Cognito for user-facing flows — that architecture is still sound and the user-auth side hasn’t changed. See our guide to Amazon Cognito user management for the full picture of what Cognito does well.
Coming back is a legitimate option. If you migrated to a self-hosted solution primarily to avoid the per-client fee, it’s worth running the new math. Cognito’s remaining per-token cost is almost certainly lower than the operational overhead of whatever you replaced it with. Whether the migration cost is worth reversing depends on how deep you went — but don’t assume the original decision is permanent.
What Cognito M2M Actually Costs Today
Straightforward: $0.00225 per 1,000 successful token requests. No per-client fee. No minimum.
The per-token cost is where architects need to pay attention, particularly at scale. A service that requests a fresh token on every API call instead of caching and reusing tokens within their validity window can generate orders of magnitude more token requests than necessary.
Cognito M2M tokens are valid for one hour by default. If your services aren’t caching tokens and reusing them across calls within that window, you’re generating token requests — and paying for them — you don’t need. In a Lambda-heavy architecture where functions spin up fresh on every invocation, this isn’t theoretical: each cold start can trigger a new token request unless you implement a caching layer explicitly.
A reasonable token caching implementation brings most architectures’ token request costs to negligible. At Rhythmic, token caching is part of how we implement Cognito M2M in client environments — it’s the difference between an auth cost that scales with business activity and one that scales with infrastructure churn.
The Lesson That Didn’t Change
AWS walked back the per-client fee. They didn’t change the underlying dynamic: cloud provider pricing is a legitimate input to architecture decisions, and it can change.
The teams most resilient to this pricing change — in either direction — were the ones running Infrastructure as Code. When your Cognito configuration lives in Terraform rather than having been clicked together in the console over years, you can see exactly what app clients exist, what they’re doing, and what they cost. You can also migrate, consolidate, or roll back without archaeology. As an AWS Advanced Partner with 214 open-source Terraform modules on GitHub, this is how Rhythmic builds auth infrastructure — because it’s the only approach that keeps you in control when AWS makes decisions like this one.
The teams that scrambled in May 2025 were largely the ones who couldn’t answer basic questions about their own Cognito setup. How many app clients do we have? Which ones are actively used? Which services are caching tokens? If those questions took days to answer, the pricing change wasn’t the real problem.
For the broader question of how to manage cloud supply chain risk — the category this pricing change belongs to — the Authentication Friction is the Productivity Killer You’re Ignoring post covers the decision framework we use with clients who are evaluating auth architecture changes.
Where Things Stand: A Practical Summary
If you’re still on Cognito M2M: Implement token caching if you haven’t. Audit your app clients and remove unused ones. The remaining per-token cost at typical volumes is negligible — this is no longer a bill-watching situation for most teams.
If you migrated off Cognito M2M: Run the math on your current solution’s operational cost against the new per-token pricing. If you’re running something you built or self-host primarily to avoid the old per-client fee, revisit whether that tradeoff still makes sense.
If you’re evaluating Cognito M2M for a new system: The per-token pricing is unlikely to be a significant factor unless you’re at high volume without token caching. The bigger architectural question is whether you need an OAuth flow at all for internal service-to-service communication, or whether IAM roles are the cleaner fit for services living within your AWS environment.
AWS made a pricing decision that didn’t work, heard from the community, and reversed it. That’s worth acknowledging. It’s also worth remembering that it happened once and could happen again in either direction. Build infrastructure that lets you respond to changes like this without a crisis — which mostly means knowing exactly what you’re running and keeping it in code.
Common Questions About AWS Cognito M2M Pricing
Did AWS remove Cognito M2M pricing entirely? No. AWS removed the per-app-client pricing dimension in November 2025, which was the $6/month fee charged per registered app client regardless of usage. The per-token-request fee ($0.00225 per 1,000 successful requests) still applies. For most architectures with reasonable token caching, the remaining cost is minimal.
What’s the cheapest way to handle M2M authentication on AWS today? For services running entirely within your AWS environment on EC2, ECS, or Lambda, IAM roles with SigV4 signing have no per-request auth cost and are the native AWS-first approach. For use cases requiring OAuth 2.0 flows — external partners, cross-organization auth, or multi-cloud scenarios — Cognito M2M is now cost-competitive again. The hybrid approach (IAM for internal, Cognito for external) is what Rhythmic recommends for most architectures.
Should I migrate back to Cognito M2M if I switched providers? Depends on what you switched to and why. If you migrated primarily to avoid the per-client fee, the economic case for Cognito has improved significantly. If you migrated because you needed capabilities your replacement provides, or because the migration improved your architecture in ways that matter operationally, staying put is probably right. Don’t re-migrate based on pricing alone without accounting for the cost of the migration itself.
How can I monitor my Cognito M2M costs going forward? In AWS Cost Explorer, filter by service (Amazon Cognito) and usage type to isolate M2M token request costs. You can also send CloudTrail events to CloudWatch Logs and query for Token_POST events with a client credentials grant to get request counts by app client. In a multi-tenant or multi-service architecture, this lets you allocate costs to specific services and identify which ones aren’t caching tokens properly.
Who should I talk to about evaluating my current auth architecture? If you’re weighing Cognito vs. IAM roles vs. a self-hosted solution and want a perspective from engineers who’ve managed this for production systems, Rhythmic Technologies works with AWS infrastructure as an AWS Advanced Partner. We can review your current setup and give you a straight read on whether your auth architecture is costing you more than it should — in dollars or in operational complexity.
