When Cognito fits and when Keycloak fits
If your renewal or pricing review is driven by per-MAU charges and your applications already run on AWS with a login experience Cognito's hosted pages can serve, keeping Cognito is usually the lower-effort choice. If a data residency rule, an on-premises or multi-cloud deployment, or a need to federate with existing LDAP or Active Directory directories pushes you off AWS, Keycloak is the option to model in detail. Both answers depend on the facts below, so treat this section as the starting point for a written comparison rather than a verdict. The decision turns on four questions. First, where must user records and password-equivalent credentials live: a Cognito user pool is tied to one AWS Region, while a Keycloak realm runs wherever you deploy it. Second, how much custom login and protocol work do you expect, such as bespoke login flows, SAML service providers or LDAP-backed directories. Third, can your team operate a stateful identity service with a production database, high availability and upgrades. Fourth, how deeply are Lambda triggers wired into your sign-up, migration and token logic, because each trigger is code you will need to port. Before you choose, inventory your Cognito configuration. List every app client, identity provider, custom attribute, trigger and the number of users you actually sign in each month, and note which settings were fixed at pool creation. Then confirm with your compliance and platform leads whether residency applies to the identity store itself or only to the applications, since that single answer often settles the question. Ask a Keycloak partner to price the operating model against your current bill, including who patches the server and who answers the on-call page.
Which option fits which scenario
This table matches common Cognito-versus-Keycloak situations to the better fit and the condition that would reverse the answer. Read each row as a starting point, then check it against your own user volumes, federation sources and staffing before deciding.
| Scenario | Better fit | Reason and what would change the answer |
|---|---|---|
| Single-region AWS app with standard OIDC sign-in | Amazon Cognito | Cognito is managed inside your AWS account, so there are no servers, database or upgrades for your team to run. It would change if your MAU-based cost model grows faster than your self-hosting budget, or if you need a non-AWS deployment target. |
| Product must run on-premises or in a customer's datacenter | Keycloak | A Cognito user pool is tied to one AWS Region and cannot run in a customer's network. Keycloak runs on infrastructure you control. It would change only if every target environment is on AWS and the customer accepts the Cognito service model. |
| Heavy SAML, LDAP or Active Directory federation | Keycloak | Keycloak supports SAML 2.0 and has built-in user federation with LDAP and Active Directory servers. Confirm that your specific Cognito federation scenarios, such as attribute mapping and SAML metadata handling, meet your needs before choosing Cognito, because the gap is in federation depth, not in basic support. |
| Custom login flows and deep branding | Keycloak | Keycloak lets you customize themes and extend authentication through its service provider interfaces (SPIs), which fit custom flows in Java. Cognito customizes flows mainly through Lambda triggers and a hosted UI. It would change if your flows are simple and your team prefers serverless functions over Java extensions. |
| Team with no identity operations staff | Amazon Cognito | Cognito removes patching, scaling, backups and high availability work from your team. Keycloak needs a database, clustering, upgrades and monitoring owned by someone. It would change if you contract the operations work to a partner under a written scope, which shifts the burden without removing it. |
| Strict control over data location and upgrade timing | Keycloak | Self-hosting lets you choose the database, region and upgrade windows. The Keycloak Operator documentation recommends manual approval for operator updates. It would change if your compliance team accepts AWS as a sub-processor and the Cognito service terms meet your data residency rules. |
| Need for a full export of password hashes for migration | Neither, confirm first | Cognito does not export password hashes, so moving users off it typically requires a password reset or a sign-in-time migration. Keycloak imports users, but confirm your source's hash format and the import path before planning. The answer depends on the migration method you can accept. |
How Lambda triggers and Keycloak SPIs differ for custom logic
Most Cognito migrations stall on custom logic, not on protocols. Lambda triggers and Keycloak SPIs both hook into the same moments in a login, but they differ in where code runs, who deploys it and who patches it. The cards below walk through the common cases and what each side asks your team to build and maintain.
Sign-up and confirmation rules
A Cognito pre sign-up Lambda trigger can reject or auto-confirm registrations, for example by checking email domains before an account is created. In Keycloak, the equivalent logic usually sits in a custom authenticator or a registration form action built as a provider, because there is no separate function service to call. Your team must write, test and version that code, and it runs inside the Keycloak process, so a bug affects every login. Confirm the exact hook names and signatures in the current Keycloak server developer documentation before you plan the work.
Token claim changes
Cognito's pre token generation trigger lets a Lambda function add, remove or change claims before tokens are issued, and AWS runs that function for you. Keycloak handles this with protocol mappers and, for complex logic, a custom protocol mapper provider packaged as a JAR. Mappers configured in the admin console cover many cases without code, which lowers effort. Whichever path you choose, check that the sub claim stays stable, since applications often key accounts on it.
User migration at sign-in
Cognito's user migration trigger calls a Lambda function when an unknown user signs in, so you can verify credentials against the old system. Keycloak offers a user storage provider SPI that can federate users from an external store and import them on first login. This matters because Cognito does not export password hashes, so the migration design must be settled before cutover. Your team owns the connection to the legacy store, its credentials and its failure handling.
Password policy
Cognito password rules are set on the user pool and enforced by the service, with limited room for custom checks. Keycloak has built-in password policies, and a custom password policy provider can add checks such as screening against breached-password lists or company rules. Custom providers become your code to test on each Keycloak upgrade, so confirm which policy features the built-in set already covers before you write one.
Custom authentication steps
Cognito's define auth challenge, create auth challenge and verify auth challenge triggers build custom sign-in flows, such as a bespoke one-time code step. In Keycloak, custom authentication steps are authenticator providers that you place into a browser flow in the admin console. This gives more control over the flow, but the team must maintain the authenticator code, its UI templates and its interaction with any MFA step. Plan test cases for every path, including account recovery.
Audit hooks and event logging
Cognito publishes sign-in activity through its own logging and lets Lambda functions record events, which you then route to your logging stack. Keycloak exposes an event listener SPI, so a provider can forward login and admin events to a SIEM or database. Built-in events still need to be enabled and retained by your team. Check which event types you need for your audit scope and who receives them, because the event listener runs inside the server and must be tested under load.
Capabilities compared: Cognito user pools and Keycloak
This table compares what Amazon Cognito user pools and self-hosted Keycloak provide for application login and federation. Read each row as a question to answer for your own applications, and treat Cognito cells as areas to verify against current AWS documentation for your Region. The main takeaway is that Keycloak exposes more of the identity stack to your team, which gives control and also adds operating work.
| Capability | Amazon Cognito user pools | Keycloak (self-hosted) |
|---|---|---|
| Protocol support | OIDC and OAuth 2.0 for app login, with SAML 2.0 for federated identity providers. Confirm the current list in AWS documentation. | OpenID Connect, OAuth 2.0 and SAML 2.0 for both applications and federated identity providers. |
| User federation with LDAP and Active Directory | Federation is provided through external identity providers. Confirm whether directory-level LDAP and Active Directory connections match your needs for your Region. | Built-in user federation with existing LDAP and Active Directory servers, configured inside the realm. |
| Login page customization | Hosted UI with branding options. Confirm the limits on layout, custom HTML and CSS in AWS documentation before you commit to the hosted pages. | Themable login pages through the server's theme system, so you can change templates and styles and host them on your own domain. |
| Admin console | Managed through the AWS console, CLI and APIs. No server to administer. | Web admin console for realms, clients, users, roles and identity providers, plus the same settings through the admin API. |
| Multi-realm or tenant structure | User pools are separate resources, each tied to one AWS account and Region. Confirm quota and isolation limits in AWS documentation. | Realms isolate users, clients and settings. You decide how many realms to run and where they live. |
| Authorization services | Group and role claims are available in tokens. Fine-grained policy evaluation is not the core of the service, so confirm needs with AWS. | Fine-grained authorization services for resource and policy modeling, built into the server. |
| Metrics and observability | Metrics flow to Amazon CloudWatch. Confirm which metrics and log fields apply to your pool. | Metrics can be exposed for Prometheus-style collection, with configuration you own and monitor. |
| Backup and export | Export user data through the ListUsers API and the console. Password hashes are not part of the standard export. | Realms export and import as JSON with kc.sh. The docs note limits for backup and restore and require all nodes to be stopped during the process. |
| License and code access | Proprietary managed service. You cannot inspect or modify the code. | Apache License 2.0 and a Cloud Native Computing Foundation incubating project, so the code is open for review and modification. |
Which Cognito settings cannot change after the pool exists
Some Cognito user pool choices are fixed at creation, and that changes how you plan a move to Keycloak. Required attributes, whether users sign in with a username or an alias, custom attributes and the username itself are the settings to review first. Cognito does not let you remove a custom attribute or change a username once it exists, so a team that later needs one of these values changed has to create a new pool. Verify each of these settings against the current AWS documentation for user pools before you plan, because the list of immutable options is the kind of detail AWS revises over time.
A fixed setting only forces a rebuild if your team needs the changed value. If your existing pool is working, a fixed choice is a constraint on future change rather than a reason to move. If you need a new attribute, a different sign-in model or a renamed identifier, the work is the same as a migration: you export profiles, decide how passwords move (Cognito does not export password hashes), and keep the sub claim stable for your applications. Plan that rebuild with the same steps described on the migration page, and ask any implementation partner to price the rebuild as part of that scope.
Keycloak is more flexible here, but it has its own constraints. Realm settings, user attributes and client configuration can usually be changed in the admin console or through the Admin REST API after a realm exists. The constraint to plan around is backup and move: a realm export with kc.sh export needs all nodes stopped while it runs, and the Keycloak documentation warns that this process has limitations as a backup and restore mechanism. Confirm the exact export behavior and any stored-user details for your Keycloak version against the Keycloak server administration guide before you rely on exports as a rollback plan.
What each option costs to run, by component
Amazon Cognito bills user pools by monthly active users (MAU), with pricing tiers that change the unit cost as volume grows. Federated users, meaning people who sign in through an external SAML or OIDC identity provider rather than a Cognito-managed password, can be priced separately from native users, so a pool that mixes both types needs both counts modeled. Cognito also meters extra features such as advanced security and certain MFA options, which can add to the bill depending on the tier you choose. Take current rates from the AWS pricing page for Cognito, because tiers and free allowances change, and do not rely on figures from older articles.
- Monthly active users: The main driver. Count distinct users who sign in during the billing period, not total registered accounts, and model growth in both sign-ins and new registrations.
- Federated users: Check whether your SAML or OIDC federation is billed at a different rate. Large workforce or partner populations that sign in through federation can change the total more than native users do.
- Tier and feature selection: Confirm which tier includes the security and MFA features you need. Turning on a feature in a higher tier can cost more than the base users.
- AWS-side costs: Lambda triggers, logging, and the AWS services that front your applications are billed separately from the user pool itself.
- Recurring nature: Cognito costs recur every month and scale with use. There is no one-time setup fee in the user pool itself, but migration work on your side is still a one-time project.
Before you compare, build a spreadsheet with current monthly active users, federated users, and projected growth for the next several years, then price each line against the AWS pricing page.
Keycloak is licensed under Apache 2.0, so the software itself carries no license fee. The cost of running it is the infrastructure and people around it: a production database, compute for at least a clustered setup, load balancing, monitoring, backups, and staff time for upgrades and patching. Keycloak's own documentation describes high availability designs that need a synchronously replicated database, so plan the database as a significant component rather than an afterthought. Optional commercial support, such as the Red Hat build of Keycloak, is a separate subscription if your organization requires vendor-backed support or an enterprise distribution.
- Production database: Keycloak supports several production databases, including PostgreSQL, MySQL, MariaDB, Microsoft SQL Server, Oracle Database, Amazon Aurora PostgreSQL and Azure SQL. Your choice affects licensing, support and managed-service fees, so confirm which database your organization already operates and supports.
- Compute and high availability: A clustered deployment needs several nodes, and multi-zone designs add capacity and networking cost. Size nodes against peak login load, not average load.
- Load balancing, monitoring and backups: Plan for a load balancer, metrics collection, log retention and tested backups. Keycloak's realm export is documented with limitations as a backup mechanism, so budget for a backup approach that covers the database.
- Staff time: Upgrades, patching and incident response are the largest recurring cost for many teams. Estimate the hours from your own change process, and factor in how much of this a platform or security team already absorbs.
- Optional support: Commercial support from Red Hat or a partner is a recurring subscription. Ask whether the quote includes the database, the operator and the support window you need.
When you request a written quote from any implementation partner, ask for each component listed separately, the assumed node counts, the database and its licensing, which upgrades and backups are covered, and whether support is one-time or recurring.
What a move from Cognito to Keycloak involves at a high level
The sequence moves users, clients and login flows from a Cognito user pool into Keycloak realms while keeping each application's subject identifier stable, so the cutover is a controlled event rather than a rebuild of every app.
Inventory user pools, apps, groups and triggers
Your team lists every Cognito user pool, app client, group, custom attribute, hosted UI setting and Lambda trigger, and records which applications depend on each one. The platform team or DeployOpen can map this against the application owners' list. Done when each trigger has a written owner and a stated purpose, and each app client has a named application that uses it.
Design the target realm and client model
Architects decide how Cognito pools map to Keycloak realms, how app clients become Keycloak clients, which groups become roles or group hierarchies, and where each Lambda trigger logic will live, such as an identity provider mapper, an authenticator or a custom SPI. Keycloak extension points differ from Lambda triggers, so each trigger needs a written replacement design. Done when a signed-off design document covers every client and trigger in the inventory.
Decide the password migration approach
Standard Cognito user exports do not include password hashes, so the team chooses between a forced password reset for all users and a sign-in-time migration that verifies credentials against Cognito and imports the user on first login. Sign-in-time migration needs Cognito to remain reachable during the transition, and the security and legal teams should approve the chosen path. Done when the decision is recorded with its user communication plan and its end date for the transitional dependency.
Deploy and design high availability
Platform engineers deploy Keycloak in your own cloud account or data center, typically with the Keycloak Operator on Kubernetes or another supported method, and connect it to a supported production database with a synchronously replicated design for high availability. Operators should set manual approval for operator updates. Done when a non-production cluster passes failover and backup tests and the restore procedure has been rehearsed.
Migrate users and preserve the subject identifier
Engineers export profiles from Cognito, import them into Keycloak realms, and apply the chosen password approach. The critical check is the subject claim: applications that store the Cognito sub value need either the same identifier carried into Keycloak or a documented mapping in each app. Done when a sample of migrated users signs in to every application and the sub values match the stored records or the mapping is in place.
Test login flows and application behavior
QA and security testers run sign-in, MFA, password reset, token refresh, logout, group-based authorization and error paths against Keycloak in staging. Security testing should cover the redirect and token configuration of each client. Done when every test case in the design has a recorded pass, and open defects are either fixed or accepted by the application owner.
Cut over applications and monitor
Application teams switch their OIDC or SAML configuration from the Cognito issuer to the Keycloak realm in a planned window, with rollback steps documented. The operations team watches authentication metrics and error rates during the first days of production. Done when all in-scope applications authenticate through Keycloak and the monitoring thresholds show normal behavior.
Decommission Cognito and document operations
Once sign-in-time migration is complete or the reset period has ended, the team removes application references to the Cognito pool, disables triggers, archives the export and configuration records under the retention policy, and deletes the pool. Operators hand over runbooks for upgrades, backups and incident response. Done when the pool is deleted, the archive is verified, and the support owner has signed the runbook.
Questions buyers ask before moving from Cognito to Keycloak
Who does the work of moving from Cognito to Keycloak, and what does it cost in effort?
The migration is paid work for whoever you hire, and your own platform and security staff carry the rest. Effort depends on the number of user pools, app clients, custom attributes, Lambda triggers and downstream applications that rely on token claims. Keycloak has no pricing to compare with Cognito's per-user model, so the cost is the infrastructure, database, staff time and any outside help. Ask any provider for a fixed-scope quote that lists each pool, app client and trigger to be rebuilt, who signs off on the sub claim mapping, and which tasks fall to your team. The quote should also say what is one-time and what recurs, such as patching and support.
How long does a Cognito to Keycloak migration take, and what sets the timeline?
The timeline is set by scope and by how users move, not by Keycloak itself. The biggest drivers are the number of applications that must be re-pointed, whether you force password resets or migrate users at sign-in because Cognito does not export password hashes, and how many Lambda trigger behaviors need a Keycloak equivalent. Environment work such as high availability, backup testing and security review also adds time. No duration is fixed by the supplied sources, so ask for a written timeline with milestones for each application cutover and a rollback plan for each one.
Can our team run Keycloak without outside help after go-live?
Your team can run Keycloak alone if it has people who can operate a Java-based identity server on a database, handle clustering and monitor it. Keycloak exposes metrics and supports production configuration, so a team already running Kubernetes or similar platforms has a head start. The harder parts are database operations, high availability design that needs a synchronously replicated database, and incident response for login outages. Decide early whether you will staff those skills in-house, buy them through a retainer, or split the work. Ask any partner which tasks stay with you after handover.
What skills and staffing does Keycloak need once it is in production?
Plan for people who understand identity protocols, database administration and container or Kubernetes operations. Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0, so someone must own client configuration, token lifetimes and claim mappings for each relying application. Operations also need a backup process that accounts for the limits of realm export and import, which the documentation says requires all nodes to be stopped during the operation. Staffing depends on how many realms and applications you run and how often they change. Ask for a responsibility matrix that names the owner of each run task.
How do Keycloak upgrades work, and why is manual approval mode recommended for the Operator?
Keycloak releases several minor versions a year and plans breaking changes to be opt-in within minor releases, according to the project's 2024 release update. The Keycloak Operator documentation strongly recommends manual approval mode for operator updates so that an upgrade never starts without a review. Database schema migration runs automatically at startup by default, but administrators can apply the SQL manually, which the upgrading guide suggests for large deployments. Ask your provider to test each target version in a staging environment, review the upgrading guide and keep a tested rollback before any production change.
Can Keycloak replace Cognito Lambda triggers, and what is the trade-off?
Keycloak does not run Lambda functions, but it can be extended through Service Provider Interfaces (SPIs) written in Java and deployed into the server. Logic such as custom authenticators, user storage, event listeners or token mappers can usually be rebuilt this way, though the mapping is not one to one. Each trigger must be reviewed for what it does, and some work may move into your application or an external service instead. Ask for a trigger-by-trigger inventory that lists the Keycloak extension point for each one, who maintains the custom code and how it is tested across Keycloak upgrades.
Can an existing Keycloak deployment be placed under a commercial support contract?
Yes, the Red Hat build of Keycloak is Red Hat's supported distribution based on the open source Keycloak project and replaces Red Hat Single Sign-On. Red Hat's product page showed version 26.6 as its latest at the time of the source, so confirm the current version on its page. Support terms, versions covered and whether your existing Keycloak can move to that distribution are questions for Red Hat and your provider. Ask any partner how they would work alongside a vendor support contract, and which party handles upgrades and patches under each.
How DeployOpen helps you evaluate, implement or migrate
DeployOpen plans and implements self-hosted Keycloak inside your own cloud accounts, data centers or air-gapped networks, so the decision between Cognito and Keycloak rests on your requirements. We start with a written scope that fits your user base, federation needs and existing Cognito setup.
How we scope
- We map your Cognito user pools, app clients, triggers and federated identity providers into a written inventory.
- We document which fixed pool settings constrain the move and which can be carried over to Keycloak realms.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
How we build
- We deploy Keycloak on your infrastructure with a supported production database and the high availability design you choose.
- We rebuild Lambda trigger logic as Keycloak extension points and test token claims, including the sub claim your apps use.
- We run security testing of the login flows and APIs, and document the results against the agreed scope.
How we hand over
- We deliver architecture, configuration, runbooks and backup and restore procedures so your team can operate the platform.
- We document the user export and migration approach, including how password handling is addressed for your users.
- We train your operators on upgrades, using manual approval for operator updates and documented schema migration steps.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We prepare systems, controls and evidence for compliance assessments, while independent auditors issue any reports.
- Ask us to confirm support scope, response expectations and upgrade cadence in the written quote before you commit.
