When Amazon Cognito vs Ory points to a hosted login or an API-first build
Amazon Cognito fits when you want AWS to run the user pool, the sign-in pages and the token endpoints, and your team would rather configure a hosted login page than write one. Ory fits when identity is a service your engineers call through APIs, you want to build the login UI yourself, and the user data and the components that handle it must sit on your own servers. Neither answer is wrong by default. The decision turns on the work your team is prepared to own after go-live.
Start with three questions. First, who builds and patches the login flows? Ory Kratos handles identities, passwords, passkeys, social sign-in and TOTP through APIs, but your team writes the screens, the recovery journeys and the error handling. Cognito's hosted UI and managed pool take much of that work off your plate, with the trade-off that customization is bounded by what the service exposes. Second, do you need SAML, SCIM, organization login or multi-tenant organizations? The Ory Kratos README lists SCIM, SAML, organization login and CAPTCHAs as enterprise features outside the open source version, and Ory Polis covers SAML, OIDC and SCIM directory sync as a separate Apache-2.0 project. Confirm which of these your identity providers and customers require before you price either path.
Third, how much patch timing risk can you accept? Ory states that open source is a good fit for evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. If a security team needs guaranteed CVE patches and support SLAs, ask Ory about the Ory Enterprise License, which it describes as optimized builds of the same servers with 24/7 support and timely CVE patches. Ask your own security and compliance leads whether a self-run stack meets their patch and evidence expectations, and whether a managed service such as Ory Network, which Ory offers alongside the self-hosted components, is an acceptable middle option for data location.
Which option fits which scenario
This table matches common buyer situations to the option that fits best, with the reason tied to the condition that makes each advantage matter. Read each row against your own constraints, and check the last column for where Ory Enterprise License features would change the answer.
| Scenario | Better fit | Why and where the answer changes |
|---|---|---|
| AWS-only footprint with a hosted login page is acceptable | Amazon Cognito | Cognito removes the need to run identity servers, and the hosted UI covers standard sign-in. The answer changes if you later need login in another cloud or on premises, or if you must own the login screens. |
| Product team must own every login screen and flow | Ory Kratos with Hydra | Kratos is API-first, so your team builds the UI and flows while Hydra handles OAuth 2.0 and OpenID Connect. This fits only if you have front-end and security engineers to maintain those flows. |
| Identity data must stay on your own servers for regulatory reasons | Ory Kratos with Hydra (self-hosted) | Self-hosting keeps user records in your database and your network boundary. Confirm with your assessor how Kratos, Hydra and their database are documented in your control evidence. |
| Multi-tenant SaaS needs SAML and SCIM from the first customer | Evaluate Ory Enterprise License or another option | SAML, SCIM and organization login are listed as Kratos enterprise features in open source. If you need them at launch, price the Enterprise License against Keycloak, ZITADEL or authentik before committing. |
| Team has no spare identity engineers | Amazon Cognito or a managed Ory offering | Open-source Ory means your team owns upgrades, backups, patching and incident response. Ask a managed provider or DeployOpen to scope ongoing support before choosing self-hosting. |
| Compliance needs CVE patches on a guaranteed timeline | Ory Enterprise License | Ory states that open-source deployments do not guarantee CVE patching and may accept upgrade downtime. Enterprise License builds add timely CVE patches and support SLAs, so confirm the terms in the license agreement. |
| Need a complete login, SSO and admin console out of the box | Keycloak or ZITADEL | Ory gives components, not a finished admin console. Keycloak and ZITADEL ship admin consoles and SAML and SCIM support in their core projects, which can shorten the build. |
| Authorization must be fine-grained across many resources | Ory Keto alongside Kratos or Hydra | Keto implements Zanzibar-style ACL and RBAC models. Cognito groups and scopes cover simpler role checks, so model your permissions before choosing Keto. |
Where identity data lives and who controls the login path
Cognito and self-hosted Ory differ less in features than in where user records, credentials and the login experience sit. Each card below covers one decision that follows from that split, and what to confirm before you commit.
Where user records and credentials sit
Cognito keeps user pools, attributes and password data inside the AWS Region you choose, managed by AWS. With self-hosted Kratos, identities and credential data go into a database you run, such as PostgreSQL, MySQL, CockroachDB or SQLite for evaluation. Ask who holds backups, encryption keys and database access, and whether the store must stay in a specific country or data center.
Region and deployment boundary
A Cognito user pool is tied to one AWS Region, so moving it across regions or onto premises is a rebuild rather than a setting change. A self-hosted Ory stack runs wherever you place it: your cloud accounts, a data center or an air-gapped network. Confirm which regions and jurisdictions your data processing agreements cover before you pick the boundary.
Trust boundary you take on
Self-hosting Kratos and Hydra places the identity store, token signing keys and client secrets inside your trust boundary. Your team becomes responsible for key rotation, network isolation of admin APIs and access to the database. Map which staff can reach the admin endpoints of each service, since those endpoints should never be exposed to the public internet.
Login UI and security headers
Cognito provides a hosted login page, and many teams accept its behavior as is. With Ory you build the login, registration and recovery screens yourself against the Kratos flow APIs. Session handling, CSRF protection, content security policy, clickjacking defenses and rate limiting on login then become your code to test and maintain.
Audit logs and compliance evidence
Cognito logs authentication events through AWS services, and you retrieve them from your AWS account. With Ory you decide what is logged, where it is shipped and how long it is kept. DeployOpen can prepare these controls and collect evidence for a compliance assessment, but independent auditors issue any report or attestation. Ask each vendor which events are logged by default.
What Ory Network changes
Ory Network is the managed cloud option offered alongside the self-hosted components. It moves database operation, upgrades and hosting to Ory, so the data boundary becomes Ory's hosted environment rather than yours. Confirm where Ory Network stores data, which regions it offers and how its controls map to your obligations before treating it as a middle option between Cognito and self-hosting.
How Cognito and Ory compare on capabilities
This table sets Amazon Cognito against the self-hosted Ory components, Kratos for identities and Hydra for OAuth 2.0 and OpenID Connect, on the capabilities that usually drive the decision. Where a Cognito cell depends on current AWS behavior, the table tells you to confirm it in AWS documentation rather than assuming it. Read the Ory column with the license split in mind, because several enterprise features sit outside the open source build.
| Capability | Amazon Cognito | Ory (self-hosted open source) |
|---|---|---|
| Login methods | Confirm current password, passwordless and passkey options in AWS documentation for your user pool tier | Passwords, passwordless codes, passkeys, social sign-in and TOTP-based MFA, with your own login UI |
| OAuth 2.0 and OpenID Connect | Confirm current hosted UI and token behavior in AWS documentation before relying on it | Hydra is an OpenID Certified OAuth 2.0 server and OpenID Connect provider, integrated through headless APIs |
| SAML and enterprise SSO | Confirm SAML and OIDC federation availability and pricing for your pool in AWS documentation | SAML is an enterprise feature in the Ory Enterprise License, not in the open source build |
| SCIM directory sync | Confirm SCIM support in AWS documentation for your target setup | Available through Ory Polis, which covers SAML and OIDC single sign-on with SCIM directory sync, and is a separate Apache-2.0 repository |
| Organizations and multi-tenancy | Confirm current tenant modeling options in AWS documentation | Organization login (SSO) and Kratos multi-tenancy with organizations are enterprise features in the Ory Enterprise License |
| Permissions and authorization | Confirm current authorization options in AWS documentation | Ory Keto is a permission server based on Google's Zanzibar approach, supporting ACL, RBAC and more |
| Database for identities | Managed by AWS, not selectable by the customer | SQLite, PostgreSQL, MySQL and CockroachDB for Kratos, so the database is yours to choose and operate |
| Licensing | Proprietary managed service under AWS terms | Apache-2.0 for Kratos, Hydra, Keto, Oathkeeper and Polis, with enterprise features under the Ory Enterprise License |
| Current release reference | Confirm current service changes in AWS release notes | Kratos and Hydra v26.2.0 were both published on March 20, 2026, per the GitHub releases pages |
What stays open source and what the Ory Enterprise License adds
The Ory open source servers, including Kratos for identities and Hydra for OAuth 2.0 and OpenID Connect, are licensed under Apache-2.0 and can be self-hosted in your own infrastructure at no license fee. The Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features that are not part of the open source version, so a team that needs those must plan for them separately. Ory states that open source suits evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required.
- Apache-2.0 licensing: You can run, modify and redistribute Kratos and Hydra under the license terms without a license fee from Ory.
- Enterprise-only features: SCIM, SAML, organization login and CAPTCHAs are listed as outside the open source version, so confirm whether your directory sync or federation needs fall into that group.
- Upgrade downtime: Ory accepts occasional downtime during upgrades in this model, so your maintenance window must be planned around it.
- CVE response: Patching timing is your responsibility, since guaranteed CVE patching is not part of this option.
- Operating work: Your team owns hosting, database backups, monitoring, upgrades and the login UI you build on the headless APIs.
Confirm with Ory which open source components you would use and whether a particular enterprise feature is needed before you commit to this path.
The Ory Enterprise License (OEL) is Ory's commercially supported way to self-host the same servers. Ory describes OEL builds as optimized builds of the open source servers that add enterprise features, including Kratos multi-tenancy and organizations and the Hydra ROPC grant, along with 24/7 support SLAs and timely CVE patches. Ory also states that OEL builds are drop-in replacements for open source installations, which means the move is about the build and the agreement rather than a new architecture.
- Optimized builds: The servers are compiled as enterprise builds of the same open source components, which Ory says can replace open source installations.
- Multi-tenancy and organizations: Kratos gains multi-tenancy and organization features that the open source version does not provide.
- Hydra ROPC grant: The resource owner password credentials grant is available in the enterprise build only.
- Support and patching: Ory offers 24/7 support SLAs and timely CVE patches under the license.
- License cost: The license is a recurring commercial agreement on top of your own hosting costs, so request the written terms and pricing from Ory.
Ask Ory for the current SLA terms, the list of enterprise features in your target versions and the license scope before comparing it with a self-hosted open source operating model.
Ory Network is Ory's managed cloud service, offered alongside the self-hosted open source components and the Ory Enterprise License. It is a different deployment model from running the servers in your own infrastructure, so it changes where identity data is hosted and who operates the service. Teams that need the self-hosted control described in this page should treat it as a separate option to evaluate, not as a default.
- Managed hosting: Ory operates the service in its cloud rather than in your data center or cloud account.
- Alongside self-hosting: It is offered next to the self-hosted components, so the two options can be compared directly.
- Data location: Confirm where identity data is stored and processed before you assess residency or sovereignty requirements.
- Commercial terms: Pricing and service terms are set by Ory, so request them in writing from Ory's pricing page or sales team.
Confirm the hosting location, data processing terms and exit options with Ory before choosing a managed deployment for regulated identity data.
What you pay for on each side and what recurs
Cognito bills on monthly active users (MAU), with tiers that AWS sets per Region, and federated users (those who sign in through SAML or OIDC identity providers) can carry a separate rate. Exact rates change, so pull current figures from the AWS pricing page for your Region and tier before you compare anything. On the Ory side there is no per-user license fee for the open-source servers, but that does not make the stack free. Your costs are the application servers for Kratos and Hydra, a PostgreSQL or MySQL database with its own backups, load balancing across at least two instances, monitoring, and the engineering time to build the login UI and flows that Cognito's hosted pages provide out of the box. The UI build and the migration of users are one-time costs. Hosting, patching, upgrades, on-call and any support contract recur every year.
Ory's commercial options change the cost mix. The Ory Enterprise License (OEL) adds features such as multi-tenancy and organizations in Kratos, and 24/7 support SLAs with timely CVE patches. Its price is not published, so ask Ory for a quote against your written scope, and confirm whether the license covers Kratos only or also Hydra and any other components you run. Ory Network, the managed service, has its own pricing, so check the Ory pricing page for current terms before assuming the self-hosted route is cheaper. Ask every vendor for a three-year view that separates one-time integration from recurring licensing, hosting, support and staff time. Also ask what drives the price up: user volume, number of environments, SLA tier and the features you need, such as SCIM or SAML, which the Kratos README lists as enterprise features.
What moving from Cognito to Ory involves at a high level
This sequence moves application login from a hosted Cognito user pool to self-hosted Ory components while keeping user identifiers stable, so dependent applications keep working through the cutover. Each phase ends with a check your team can verify before the next one starts.
Inventory app clients, scopes and user attributes
Your identity and application teams list every Cognito app client, the OAuth scopes and callback URLs each one uses, the custom and standard user attributes stored in the pool, and the Lambda triggers attached to sign-up, sign-in and token events. Each application owner confirms which claims their code reads, including the sub claim, because that value must survive the move. The step is done when the team has a written inventory that maps every client and claim to an owning application. Ask Ory and your own architects to review the attribute schema before any Kratos identity schema is drafted.
Decide how credentials will move
Cognito does not export password hashes in its user export, so your security and product owners must choose between two paths: forced password resets for all users, or a migration where a user's first successful sign-in in the new system is verified against the old pool and then stored in Kratos. A hybrid, where dormant accounts are reset and active users migrate on sign-in, is also common. The decision should be recorded with its effect on users, support load and any compliance obligations you hold. It is done when the chosen path, its communication plan and its owner are approved in writing.
Stand up Kratos and Hydra in a test environment
Platform engineers deploy Ory Kratos and Ory Hydra in a non-production environment in your own cloud account or data center, each backed by PostgreSQL, which both components support. They configure issuer URLs, TLS, secrets and the identity schema that mirrors the attribute inventory. Hydra's login and consent endpoints are pointed at a placeholder service for now. The step is done when both services start, health endpoints respond, and a test identity can be created and an OAuth 2.0 authorization code flow completes against a sample client. Confirm with Ory which Kratos and Hydra releases your team will pin and how upgrades will be tested.
Build the login experience on Kratos and Hydra
Front-end and back-end developers build the login, registration, recovery, verification and MFA screens against Kratos flows, which means your team owns the UI, copy and accessibility work that a hosted Cognito page provided. They then implement Hydra's login and consent endpoints so that Hydra asks your service to authenticate the user and to record consent before issuing tokens. The step is done when a test user can sign in, complete enrollment for at least one second factor, and receive tokens whose claims match the inventory from the first step.
Map Lambda trigger logic to application or webhook code
Developers take each Cognito Lambda trigger from the inventory, such as pre sign-up checks, post confirmation actions and token customization, and reimplement its behavior either in your login service or in a Kratos webhook that runs at the matching flow stage. Security reviewers confirm that any validation or access rule the trigger enforced still applies, and that the new code has no hidden dependency on Cognito behavior. The step is done when each trigger has a documented replacement, a test case that reproduces its original outcome, and a reviewer sign-off.
Run parallel sign-in tests and keep sub stable
QA and application teams run the same test scripts against Cognito and the Ory stack, comparing token contents, session lengths, refresh behavior, error messages and the sub value returned for each test account. Where dependent apps store the Cognito sub, the team sets the new identifier to the same value or maps the old one in a lookup table, so records and permissions do not break. The step is done when the comparison shows no unexplained differences in claims that applications read, and every known difference has an owner and a fix or an accepted impact.
Cut over with a documented rollback plan
Operations and application owners agree on a cutover window, switch application configuration from the Cognito issuer to the Hydra issuer, and keep the Cognito pool active until the rollback criteria are no longer relevant. The rollback plan states which signals trigger a return to Cognito, who makes that call, and how any users who signed in during the change window are reconciled. The step is done when production sign-in succeeds for a monitored sample of users, support has the runbook, and the team has confirmed that the rollback path was tested in staging.
Who operates and patches each option
On Cognito, AWS runs the identity service itself: the hosted login pages, the user store, the token endpoints and the patching of the platform underneath them. Your team still owns the work around it: app clients and their callback URLs, user pool settings, Lambda triggers, the IAM roles and policies those triggers and your backend use, and the monitoring of sign-in failures and throttling. Most of that work is configuration and code review rather than running servers. With Ory open source, the picture reverses. Your team owns the upgrade path for Kratos and Hydra, including the downtime Ory describes for upgrades, along with database backups and restore tests for PostgreSQL, high availability for each component, security monitoring, CVE tracking across Kratos, Hydra and their dependencies, and an on-call rotation for login outages. Before choosing, ask your team who will hold each of those duties and whether that person is on call at 2 a.m.
The Ory Enterprise License changes the commercial side of that list, not the division of responsibility. According to Ory, the OEL adds 24/7 support SLAs and timely CVE patches for builds that you still run in your own infrastructure, and the builds are described as drop-in replacements for open source installations. Confirm in the written contract which versions are covered, how quickly patches are delivered for your supported releases, and whether upgrade assistance is included. Under either tier, the customer keeps the login UI and its security, including session handling, password reset flows, rate limiting, CAPTCHA placement where you use it, and the security of your own frontend code. The customer also keeps the hosting, database operations, network controls, key and secret management, and the decision about when to upgrade. Those items do not move to a vendor because a support contract exists.
The skills required are of three kinds. The first is identity protocol knowledge: OAuth 2.0 and OpenID Connect flows, token lifetimes, and how Hydra and Kratos hand off between login and consent. The second is frontend work for the login and recovery screens, which Cognito's hosted pages otherwise handle for you. The third is database operations for PostgreSQL or another supported store, because identity data is the system of record for every application that signs in. Teams without these skills in house should price that gap as part of the decision, either by hiring, training or a fixed-scope implementation and handover agreed in writing before work starts.
Questions buyers ask before choosing Ory or staying on Cognito
How much effort does a self-built Ory login take?
The effort comes from building the login experience yourself, not from installing the server. Ory Kratos is API-first and handles identities, passwords, passkeys, social sign-in and TOTP multi-factor authentication, but your team designs and builds the sign-in, registration, recovery and MFA screens, the error handling and the account settings flows. Ory Hydra adds the OAuth 2.0 and OpenID Connect layer, so your applications still need correct token, consent and logout handling. Ask any vendor or partner to list each flow you need, which screens they will build, and which of those flows you must test with real users before go-live.
Can our own team run the Ory work, or do we need outside help?
Your team can do it if it already runs production identity or has strong backend and security engineering experience. The work usually includes database setup on PostgreSQL, MySQL, CockroachDB or SQLite, high availability, secrets and key handling, upgrades, monitoring and incident response. Consider outside help for the design review, the login UI and the security testing, while your staff keep day-to-day operation. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted open-source platforms in your own infrastructure, typically under a fixed-scope agreement with a written scope before work starts. Ask for the written scope, the named deliverables and the handover plan.
How long does a migration from Cognito to Ory take?
The length depends on the number of user pools and applications, how many users need a password reset or sign-in-time migration, how much custom Lambda trigger logic must be rebuilt, the login UI you choose to build, and how many integration tests and security tests you run before cutover. No single duration applies to every estate, so ask for a timeline built from your inventory of pools, app clients, triggers and identity sources. A migration plan should show a parallel run period and a rollback path for each application.
Does Ory support SAML and SCIM without the enterprise license?
Not in the open source version. The Ory Kratos README lists SCIM, SAML, organization login (SSO) and CAPTCHAs as enterprise features that are not available in the open source version. The Ory Enterprise License offers optimized builds of the same servers with enterprise features such as Kratos multi-tenancy and organizations, plus 24/7 support SLAs and timely CVE patches. Ory Polis, which is Apache-2.0 licensed, provides SAML and OIDC single sign-on with SCIM directory sync, so check with Ory how it fits your architecture and licensing before you plan. Confirm the current feature split on the license page before you sign.
Does the Cognito export include password hashes?
No. A Cognito user export gives you profiles, attributes, status and MFA options through ListUsers, but not password hashes, so users cannot sign in to Ory with their existing passwords after a move. Plan one of two paths: a forced password reset for every user, or a sign-in-time migration in which your application or a migration service verifies the old password against Cognito once and then stores the new credential. Choose the path based on user count, your tolerance for reset friction, and whether you can keep Cognito running during the transition.
What does the work need from our staff?
Expect a few roles to stay involved from start to finish. An identity or platform engineer owns the Ory deployment and its upgrades. An application owner confirms each client's redirect URIs, scopes, token lifetimes and claims, and checks that the sub claim your apps depend on is preserved. A security lead reviews MFA policy, recovery flows and logging. Someone from compliance should map the evidence you need for your assessments, although DeployOpen prepares systems and evidence and does not issue audit reports or certifications. Ask each vendor which of these roles they expect you to fill.
Does Ory Network remove the operating work?
It reduces some of it, but it changes who operates the service and where your data sits. Ory Network is Ory's managed cloud service, offered alongside the self-hosted open source components and the Ory Enterprise License. Self-hosting keeps identity data in your own infrastructure and gives you control over upgrades and data residency, while Ory Network moves hosting and much of the operations to Ory. Compare the two against your residency requirements, your upgrade tolerance and your cost model, and confirm the current service terms on Ory's pricing page before you decide.
How DeployOpen helps evaluate, implement or migrate Ory
DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For identity, we start with the login flows and claims your applications depend on, then decide with you whether Ory fits, and what the operating model around it needs to look like.
How we scope
- We inventory the Cognito app clients, token claims, MFA settings and Lambda triggers your applications rely on today.
- We confirm which Ory components you need: Kratos for identities, Hydra for OAuth 2.0 and OpenID Connect, or both.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Kratos and Hydra in your environment and build the login, registration and recovery UI on their headless APIs.
- We design a password strategy for migrated users, since Cognito exports do not include password hashes.
- We test token issuance, the stable subject identifier, MFA enrollment and session behavior against your applications.
How we hand over
- We document configuration, database layout, backup and restore procedures, and the upgrade path for each Ory release.
- We prepare the evidence a compliance assessor will ask for, such as access logs and change records. Assessors and auditors make the determinations.
- We walk your platform and security teams through runbooks for key rotation, incident response and enterprise feature decisions.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- We can run security testing of the login flows and APIs, including OAuth and MFA paths, before go-live and on a schedule.
- Ask us to quote upgrade support against the Ory Enterprise License options, including CVE patching, so your team can compare with open-source operation.
