HN Debrief

I used AWS cognito for a startup. I wouldn't do it again

  • Infrastructure
  • Security
  • Developer Tools
  • Open Source

The post argues that AWS Cognito looked like the obvious startup choice because it is cheap and already wired into AWS, then turned into a drag on product velocity. The complaints were not about basic uptime. They were about a service that is hard to understand, hard to customize, and surprisingly hard to change once real users exist. Hosted UI limitations, awkward local development, and sprawling documentation were part of it. The deeper complaint was that Cognito makes early setup decisions feel trivial, then turns them into durable constraints that are expensive to unwind.

If you are choosing auth for a startup, price the migration path and day-two operations up front, not just the monthly bill. Cognito may still fit if you need low-cost AWS-native auth, but only if you can live with hard-to-change defaults and have a clear escape plan.

Discussion mood

Strongly negative on Cognito and broadly cynical about higher-level AWS services. The mood came from repeated first-hand stories about bad docs, immutable configuration, ugly migrations, and lock-in that erased the headline cost savings.

Key insights

  1. 01

    Auth threat model changes the build decision

    Authentication looks like ordinary CRUD until you remember the login surface is exposed to attackers by default. That brings DDoS pressure, credential stuffing, malicious input, reset flows, and federation edge cases that many teams underestimate. The useful correction here is not that Cognito is good. It is that frustration with Cognito does not automatically make homegrown auth the right answer, because managed scale and battle scars are real assets in this part of the stack.

    Treat auth as a security and abuse-control system, not just a user table. If you reject Cognito, replace it with another hardened service or mature open source identity stack, not a weekend implementation.

      Attribution:
    • solatic #1
    • ad_fontes #1
    • DarmokTanagra #1
    • vips7L #1 #2
  2. 02

    Immutable user-pool decisions are the real trap

    The worst Cognito problem is not ugly APIs. It is that basic choices made during first setup can become effectively permanent. Case sensitivity, schema fields, and other user-pool settings can force a full new deployment plus migration plumbing later. That means the service front-loads irreversible architecture decisions into the moment when a startup has the least clarity about future requirements.

    During evaluation, ask which auth settings can be changed in place after launch. If the answer is "new tenant, new pool, or migration hook," assume that work will eventually land on your roadmap and cost it now.

      Attribution:
    • patwolf #1
    • oofbey #1
    • leetrout #1
    • mannyv #1
  3. 03

    Password-hash export is a litmus test

    Several people used password-hash export as the easiest way to tell whether an auth vendor respects exits or weaponizes lock-in. Cognito was singled out as especially bad here. Others pointed out that Auth0, Firebase, and Ory have export paths, even if some make you open support tickets or pay for higher tiers. One commenter argued password migration should not be supported because it is abuse-prone, but that view did not move the center of gravity. Teams see exportability as table stakes.

    Add password-hash export and migration mechanics to your vendor checklist before you sign anything. If the path involves support tickets, premium plans, or no path at all, assume future switching costs will be painful for both you and users.

      Attribution:
    • voxic11 #1
    • sandeepkd #1
    • vinckr #1
    • NegativeLatency #1
    • jenius #1
  4. 04

    Day-two features are where Cognito breaks down

    Cognito can survive the happy path, then fall apart when the business needs enterprise federation, disaster recovery, backups, or synchronization with peripheral systems. Comments about SAML pain, missing basic backup expectations, multi-region failover being left to the customer, and a six-month migration that later had to be rolled back all point to the same thing. The service covers basic auth cheaply, but advanced operational requirements are underpowered or awkward enough to become project risks.

    Map your likely year-two auth requirements before adopting a cheap provider. If SAML, backup, multi-region failover, or admin workflows are even plausible, test those first instead of the login demo.

      Attribution:
    • montroser #1
    • cldcntrl #1
    • jonathaneunice #1
  5. 05

    AI-written post hurt credibility, not agreement

    A side conversation fixated on the article sounding LLM-generated, with people calling out stock phrasing and "AI slop." That did not turn into a defense of Cognito. If anything, it highlighted that the substance resonated enough that readers kept separating the weak presentation from the underlying complaint. The trust penalty landed on the author, not on the core claims about Cognito's rough edges.

    If you are publishing engineering critiques, write in a voice people trust. Readers may still accept the facts, but obvious LLM polish makes it easier to dismiss your judgment and harder for your evidence to carry weight.

      Attribution:
    • bklosky #1
    • Eiriksmal #1
    • DarmokTanagra #1

Against the grain

  1. 01

    Cheap and tolerable if you know its quirks

    For teams that already live deep inside AWS, Cognito can be good enough once the setup pain is paid. These comments argue that the service is weak on first contact, not fundamentally broken in production. The cost advantage is real, and if your needs are modest and you avoid the hosted UI, the rough edges may be an acceptable tax rather than a deal-breaker.

    If you are staying with Cognito, standardize the tricky parts instead of rediscovering them on each project. Capture your own template, defaults, and migration playbooks so the initial pain does not repeat.

      Attribution:
    • nater5000 #1
    • TSiege #1
    • skeeter2020 #1
  2. 02

    Build more yourself in the LLM era

    A minority view said the market has overcorrected toward outsourced auth. With strong libraries and LLM help, many ordinary apps can own email-password flows, magic links, and token plumbing without surrendering user identity to a sticky vendor. The point is not to hand-code crypto. It is that third-party auth often forces more product compromises than the underlying engineering actually requires.

    Revisit build-versus-buy with today's tooling, but narrow the scope. If your needs are simple and you skip enterprise federation, a library-backed in-app auth system may now be cheaper than a hosted platform's constraints.

      Attribution:
    • joshstrange #1 #2 #3
    • codegeek #1

In plain english

API Gateway ↩
An AWS service for publishing, securing, and managing APIs.
Auth0 ↩
A commercial identity and authentication platform for handling logins, user accounts, and single sign-on.
AWS ↩
Amazon Web Services, Amazon's cloud computing platform.
Cognito ↩
An AWS service for user authentication, account management, and identity federation.
DDoS ↩
Distributed Denial of Service, an attack that floods a service with traffic to make it unavailable.
Firebase ↩
Google's developer platform that includes authentication, databases, hosting, and other app services.
Keycloak ↩
An open source identity and access management platform that provides login, single sign-on, and user federation features.
Lambda ↩
AWS Lambda, Amazon's serverless function service that runs code on demand.
LLM ↩
Large Language Model, a machine learning model trained to generate and analyze human-like text.
Ory ↩
A company and open source stack that provides identity, authentication, and authorization components.
S3 ↩
Simple Storage Service, AWS's object storage service.
SAML ↩
Security Assertion Markup Language, an older enterprise standard for single sign-on between identity providers and applications.
SQS ↩
Simple Queue Service, AWS's managed message queue service.
Step Functions ↩
An AWS workflow orchestration service for coordinating multiple tasks or services.

Reference links

AWS documentation and references

Auth vendors and products mentioned

  • Ory
    Repeatedly recommended as a more acceptable hosted or self-hosted alternative to Cognito.
  • Keycloak
    Frequently cited as the leading open source alternative for teams that want control or self-hosting.
  • WorkOS
    Mentioned as a commercial option for centralized account management and enterprise features.
  • FusionAuth
    Named as a trusted hosted auth option that people should consider instead of Cognito.
  • Stytch
    Listed as another hosted auth option that commenters saw as more straightforward.
  • Clerk
    Mentioned as a vendor designed around easy user-data export rather than sticky lock-in.