A developer who implemented AWS Cognito for a startup has detailed why they would not use the service again, citing documentation quality, breaking changes, and configuration rigidity as major pain points.
According to the blog post, the core issue began early in implementation. Despite following AWS documentation, watching tutorials, and possessing prior authentication experience with Auth0, Firebase Auth, and custom JWT systems, the developer encountered persistent problems—including a password reset flow that redirected to the wrong location.
The developer identified several recurring problems. The Cognito documentation attempts to serve multiple audiences simultaneously—enterprise architects, frontend developers, and mobile developers—resulting in unclear navigation and outdated code examples. Some examples reference older JavaScript SDK versions, Amplify v1 APIs, or raw AWS SDK approaches without clear version labeling, forcing developers to infer correct implementations.
A significant issue emerged during a library upgrade. When Amplify moved from version 5 to version 6, the update fundamentally rearchitected how developers interact with Cognito. Functions that formed the basis of authentication flows were removed entirely, requiring a complete rewrite rather than a simple refactor. The migration guide was incomplete, described as “a treasure map with half the landmarks missing.”
Local development presented another challenge. Because Cognito is cloud-based, developers cannot run local instances for offline testing—all work requires hitting actual AWS endpoints. Community tools like serverless-offline plugins exist but lack official support and vary in maintenance quality. This forced iteration cycles to depend on network round trips rather than local testing, allowing bugs to slip through to staging environments.
The hosted UI customization options proved limited. While the interface functions, substantial branding changes require building a custom UI with the SDK, eliminating the time savings the hosted solution supposedly provides.
The most frustrating experience involved user pool attribute configuration. The developer initially created an attribute as custom rather than standard. AWS Cognito does not allow changing an attribute’s classification after creation. For production applications with active users, the only options were deleting the entire user pool or scripting a complex user migration to a new pool—both significantly disruptive approaches.
Despite these issues, the developer remains using Cognito due to project maturity, but describes experiencing “a small, quiet resentment” when accessing the service. They recommend potential users build a substantial proof of concept, including custom attributes, email verification, and password reset flows, to assess the experience before committing to production deployment.
Key facts
- Cognito documentation serves multiple audiences simultaneously, resulting in unclear navigation and outdated code examples
- Amplify v6 made breaking changes that required complete rewrites of existing authentication logic
- Developers cannot test Cognito locally—all development requires hitting actual AWS cloud endpoints
- User pool attributes cannot be reclassified after creation, forcing either pool deletion or complex user migrations for fixes
- The developer remains on Cognito despite frustrations because the project is too mature to switch implementations