Amazon Cognito vs ZITADEL: when each fits your customer login
Choose Amazon Cognito when your customer login already lives in AWS, your team is comfortable with managed operations, and a single AWS Region meets your data location requirements. Cognito removes the need to run a database, patch a login server or plan high availability for the identity layer itself. Choose self-hosted ZITADEL when you must serve many customer organizations with strong isolation between them, run the identity platform on premises or across more than one cloud, or keep control of where the identity database sits. ZITADEL's model of instances, organizations and projects maps directly to multi-tenant SaaS, and it supports passkeys, OIDC, SAML 2.0 and SCIM 2.0 from one platform.
Four questions should drive the decision. The first is tenancy: if each customer needs its own identity provider, branding or isolated user store, check whether your design maps to ZITADEL organizations or whether a pool per customer would be simpler on Cognito. The second is data residency: confirm in writing which regions and facilities will hold user records, password material and logs under each option. The third is licensing. ZITADEL's core is licensed under AGPL-3.0, and if you modify that core and offer it to users over a network, you need legal review of what source you must publish. Your APIs, SDKs and Helm charts remain Apache 2.0, which may narrow the review. The fourth is operations: someone must own PostgreSQL backups, the ZITADEL upgrade path (PostgreSQL 14 through 18 are supported) and on-call response, and that cost recurs for as long as you self-host.
Before you commit, ask your AWS account team and your ZITADEL implementation partner to quote the same scope: the number of organizations, peak sign-in volume, federated identity providers, and the passkey and MFA policies you need. Then compare the recurring cost of Cognito's per-user pricing at your projected scale against infrastructure, database, high availability and operator time for ZITADEL. Confirm current Cognito pricing and feature availability directly with AWS, since those change over time. If you already run ZITADEL Cloud as a hosted option, it can narrow the operations gap while keeping ZITADEL's data model.
Which option fits which scenario
This table maps common buyer situations to the option that usually fits better and the condition that decides it. Read each row against your own constraints, then confirm the Cognito behavior that matters to you with current AWS documentation, since this page does not restate Cognito limits.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Single-tenant app fully on AWS, small team, no data residency demands | Amazon Cognito | Your users, app and operations already live in AWS, and a managed service with no database or upgrades to run matches your staffing. Confirm current per-MAU pricing directly with AWS. |
| B2B SaaS where each customer brings its own identity provider | ZITADEL | Organizations inside an instance can each use a different identity provider, which fits per-customer SSO without building that routing yourself. Confirm the setup steps against the ZITADEL identity provider guide. |
| Product that must run in a customer's datacenter or air-gapped network | ZITADEL | A self-hosted service on PostgreSQL can be deployed inside the customer's environment, while a Cognito user pool is tied to AWS. Confirm the deployment path with your own networking and security review. |
| Multi-tenant product that needs strict data separation between tenants | ZITADEL | Instances give full data isolation and organizations group users inside them. Map this against your tenancy model before committing. |
| Passwordless login with passkeys and password fallback | Either, verify your requirements | ZITADEL documents FIDO2 and WebAuthn passkeys with password fallback. Confirm how Cognito handles passkeys in your region and SDK version with AWS documentation before deciding. |
| Team with no platform engineers and no appetite for database operations | Amazon Cognito | Running ZITADEL means operating PostgreSQL 14 to 18, upgrades and high availability. If nobody will own that, a managed service or ZITADEL Cloud is the safer starting point. |
| Team that wants self-hosted control but not self-hosted operations | ZITADEL Cloud (middle option) | You keep the ZITADEL model and migration path without running the infrastructure. Check current hosting terms and pricing on the ZITADEL pricing page. |
| Licensing must avoid copyleft obligations on the identity server itself | Amazon Cognito or a commercial agreement | ZITADEL's core is AGPL-3.0, which can carry network-use source obligations if you modify it. Have counsel review how your deployment and modifications are used. |
How ZITADEL's organizations compare with Cognito user pools
The structural question in this comparison is how each platform separates customers, and that answer decides how much of your Cognito setup carries over. ZITADEL organizes tenants as instances (virtual tenants with full data isolation), organizations inside an instance where projects and users live, and projects that group applications, roles and grants. A Cognito user pool is a single directory that you typically partition with groups, custom attributes and separate app clients. Before you design a migration, map each existing pool, group and app client to one of these ZITADEL levels. Confirm with your Cognito configuration whether each B2B customer is a group, an attribute value or a separate pool today, because that mapping determines how many instances and organizations you create and how users are moved.
Per-customer organizations matter most for B2B login. In ZITADEL, each organization can use a different identity provider, so one customer can sign in through its own Entra ID or Okta tenant while another uses a SAML connection and a third uses local passwords. Cognito supports federated identity providers at the pool level, so you should list which customers depend on their own IdP today and whether those connections are scoped to one customer or shared. ZITADEL's passkey support, based on FIDO2 and WebAuthn, can be enabled for passwordless sign-in with password fallback, so plan which user populations will move to passkeys first and whether fallback should remain on for them. For provisioning, ZITADEL offers a SCIM v2 service provider interface, which lets a customer's directory create, update and deactivate users in ZITADEL without your team handling each change. Confirm which of your customers already send SCIM requests or expect them, since that shapes the cutover plan.
Amazon Cognito vs ZITADEL capabilities side by side
This table compares the login capabilities that most often decide a Cognito to ZITADEL move, including protocols, federation, passkeys, tenancy, migration tooling and license. Where Cognito behavior is not covered by the sources used here, the cell tells you what to confirm in AWS documentation before you rely on it.
| Capability | Amazon Cognito | ZITADEL (self-hosted) |
|---|---|---|
| OIDC and OAuth 2.0 | Supported for user pool app clients. Confirm grant types and token options in AWS documentation. | Yes |
| SAML 2.0 | Available for federated sign-in to user pools. Confirm the exact configuration limits with AWS. | Yes |
| SCIM 2.0 provisioning | Confirm whether SCIM provisioning is available in your Region and tier with AWS. | SCIM v2 service provider interface for standardized user provisioning and lifecycle management. |
| LDAP | Not a native directory protocol for user pools. Confirm any LDAP bridge options with AWS. | Supports LDAP and OpenLDAP as an identity provider for federated login. |
| Federation with Google, Entra ID, Okta and other OIDC providers | Confirm the supported social and enterprise providers in AWS documentation. | Google, GitHub, GitLab, Apple, Entra ID, Okta, Keycloak, any OIDC provider. Each customer organization can use a different provider. |
| Passkeys (FIDO2 and WebAuthn) | Confirm passkey support and fallback behavior in AWS documentation. | Passwordless passkey login with fallback to password login. |
| Device authorization grant | Confirm with AWS documentation whether this grant is offered for your app types. | Yes |
| Multi-tenant structure | Typically modeled with separate user pools or app-level design. Confirm pool limits and isolation with AWS. | Instances give full data isolation. Organizations hold users and projects, and projects group apps, roles and grants. |
| Migration guides and tooling | Cognito is not among ZITADEL's documented migration guides, so plan a custom export and import. | Documented guides for Auth0, Keycloak, Firebase and another ZITADEL instance, including just-in-time migration. |
| License | Proprietary managed AWS service, billed by usage and operated by AWS. | AGPL-3.0 core since v3.0. APIs, SDKs, proto definitions and Helm charts stay Apache 2.0. |
Where customer identity data lives and who controls it
Cognito is a managed AWS service tied to a Region, while ZITADEL runs in your own infrastructure on PostgreSQL. The cards below cover the decisions that follow from that difference: where data sits, who runs the database, how backups and audit evidence are produced, and what changes when a customer requires a named country or their own cloud account.
Data location and Region pinning
A Cognito user pool is created in one AWS Region, and the profile data, password material and tokens it stores stay in that Region under AWS operation. ZITADEL places the database and services wherever you deploy them, so the question becomes which country, data center or account hosts the PostgreSQL instance. If a regulated customer requires data in a named country, confirm the Region list and the data flows that leave it, including email and SMS delivery, logs and any identity provider federation calls.
Managed service versus self-hosted binaries
With Cognito, AWS operates the identity service, its patching and its availability, and you configure user pools through the console, API or infrastructure code. With ZITADEL you choose the deployment path: Linux binaries, Docker Compose or Kubernetes with the official Helm chart. Choose the Kubernetes path with the Helm chart when high availability is required, because the project recommends it for that purpose. Each path moves operational ownership to your team or to a partner under a written scope.
PostgreSQL as the system of record
Self-hosted ZITADEL stores its data in PostgreSQL, and the supported versions are 14 through 18. Your team must size, patch, replicate and monitor that database, and must agree on which PostgreSQL version your platform team is allowed to run. Ask whether your existing managed PostgreSQL service or an in-cluster operator will host it, and confirm that the chosen version falls inside the supported range before the first deployment.
Backup and restore responsibility
On Cognito, AWS runs the service but customers still decide how user exports are kept and how a regional failure would be handled. On ZITADEL, backup of PostgreSQL, secrets and configuration becomes your responsibility from day one. Define recovery point and recovery time targets with your risk owner, then test a full restore into a separate environment. Ask your partner to document which items sit in the backup scope, including encryption keys and the signing keys used for tokens.
Audit logs and compliance evidence
Compliance assessments usually ask who changed a configuration, who accessed user records and how access was reviewed. Cognito writes activity to AWS logging services, so evidence depends on the trails you enable in your AWS account. With ZITADEL, evidence comes from the logs and database records of your own deployment, so you must decide where those logs are shipped, how long they are kept and who can read them. DeployOpen prepares these controls and evidence for an assessment, but independent auditors and certification bodies issue any report.
Customer-owned cloud or on-premises deployment
If a product must run inside a customer's own cloud account or data center, a Cognito user pool cannot follow the workload because it belongs to one AWS account and Region. ZITADEL can be deployed into the customer's environment, including air-gapped networks, provided the PostgreSQL database and container images are available there. Confirm with the customer who owns the cluster, who approves upgrades and whether the identity service must keep working during an outbound network outage.
Does the AGPL license on ZITADEL's core affect your product?
When ZITADEL only handles sign-in for your own employees and contractors, you run it inside your organization and nobody outside it uses the console or login pages as a product. ZITADEL moved its core, Console and hosted login from Apache 2.0 to the GNU Affero General Public License 3.0 with v3.0 on 31 March 2025. That change matters most when you alter the core code, because modified versions carry source-sharing duties under the AGPL. Your own unmodified deployment of the released binaries or containers is a different situation from a fork.
- Unmodified deployment: Running the official release for internal sign-in usually creates no new source-disclosure duty, but confirm this with counsel.
- Patched core: Any change to the core, Console or hosted login may trigger AGPL obligations if you distribute or host it for others.
- Configuration and Actions: Settings, custom Actions and identity provider configuration are typically separate from the licensed core, which your counsel should confirm for your setup.
- Staff-only access: Internal use is the lowest-exposure case, since the network-use clause is aimed mainly at users who interact with the modified program remotely.
- Upgrade planning: Keep a record of any local changes so you can reconcile them with each new release.
Ask your legal team whether internal use of an unmodified core and your planned configuration fall within their interpretation of the license.
If your customers sign in through ZITADEL as part of a hosted product, the AGPL's network-use provision becomes central. Under that clause, users who interact with a modified version over a network may be entitled to receive its corresponding source. The exposure is therefore tied to modifications, and ZITADEL's multi-tenant design, with instances, organizations and projects, does not by itself decide the question. Whether your customer-facing login pages, branding or Console changes count as modifications of the covered code is a question for counsel.
- Multi-tenant configuration: Using organizations and projects as designed is a use of the software, but confirm how your counsel views tenant-specific settings.
- Customized login pages: Changes to hosted login may fall within the covered code, so review them before launch.
- Source offer: If modifications are covered, plan how you would make the corresponding source available to users who interact with the service.
- Integration layer: Your application code that calls ZITADEL's APIs is generally separate from the core, which counsel should verify.
- Commercial terms: Check whether your customer contracts already promise source access or restrict open-source disclosure.
Map every change you have made to the core, Console or hosted login before deciding how the network-use clause applies to your product.
If you bundle ZITADEL inside an appliance, a packaged on-premises product or software you distribute to customers, the AGPL applies to what you ship, not only to what you run. Distribution triggers the license's conditions for the covered core, Console and hosted login, and you should expect to provide license texts, notices and, for modified components, corresponding source. The Apache 2.0 parts remain available under their own terms, which can help you separate components in your architecture.
- Covered components: The core, Console and hosted login are under AGPL-3.0, so bundling them triggers its distribution conditions.
- Apache 2.0 components: APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations stay Apache 2.0, which simplifies packaging of deployment tooling.
- Notices and source: Plan license notices and source delivery as part of each release, not as an afterthought.
- Customer agreements: Your end-user license terms must not conflict with rights the AGPL gives recipients.
- Replacement path: Some teams keep the core separate and integrate through the Apache 2.0 APIs, which your counsel must assess for your architecture.
Before you ship, have counsel review the exact components, your modifications and your end-user terms, and confirm the license texts for each release.
What a self-hosted ZITADEL costs compared with Cognito fees
Cognito bills by usage in a single AWS line item, while self-hosted ZITADEL moves the cost into infrastructure, database operation and people. The cards below separate what you pay once from what recurs, and what moves each number up or down.
Cognito usage-based fees
Cognito charges by usage under the AWS pricing model, and the charge depends on the pricing tier, the number of monthly active users and whether federated or SAML and OIDC users are billed separately. Your bill also grows with tier features you enable, such as advanced security settings. Check the current AWS pricing page for your Region and tier, then model growth in active users rather than total registered accounts. This is the recurring line item that self-hosting replaces.
Infrastructure and high availability
Self-hosted ZITADEL runs on Linux or Kubernetes, and the official documentation recommends a Kubernetes cluster with the Helm chart for high availability. Your recurring cost is the compute, load balancing, storage and network for at least two replicas across zones, plus any non-production environments. Costs rise with the number of instances you run, the traffic at peak login times and the redundancy your availability target requires. Ask your platform team to price these in your own cloud account or data center.
PostgreSQL operation
ZITADEL stores its data in PostgreSQL, with versions 14 through 18 supported, so you run a database service you must back up, patch and tune. You can use a managed PostgreSQL service in your cloud or operate it yourself, and the first choice usually carries a recurring service fee while the second adds staff time. Costs rise with data volume, replication and backup retention. Confirm the supported versions against the database page before you choose a version.
Upgrades, monitoring and patching
Recurring work includes applying ZITADEL releases, monitoring login availability and certificate expiry, and patching the operating system, Kubernetes and the database. ZITADEL publishes releases on GitHub, so your team needs a regular upgrade routine and a test environment that matches production. Costs rise with the number of environments, the frequency of changes and the strictness of your change control. Ask whether your vendor or partner covers this work in a retainer, and what it excludes.
One-time migration and integration
Migration is a one-time cost that covers exporting Cognito users, deciding between bulk import and migrating users as they sign in, mapping app clients to ZITADEL projects and rebuilding Lambda trigger logic as Actions. Integration includes configuring your applications, identity providers and any SAML or SCIM connections, plus hardening and documentation. The effort rises with the number of app clients, custom attributes and custom authentication flows. Request a written scope listing which applications are in and out before work starts.
Staff time and support model
Self-hosting shifts accountability to your team or a partner, so staff time is the largest cost that many organizations underestimate. Community support covers the open-source project, while paid support, retainers and a managed operations contract are separate purchases. Costs rise with the depth of skills your team lacks, the hours needed for on-call and the number of compliance evidence requests. Ask any partner to state in writing who responds to incidents, what hours are covered and what happens after the initial project.
What a move from Cognito to ZITADEL involves
The sequence turns Cognito app clients, user pools and Lambda logic into ZITADEL organizations, projects and Actions, while keeping existing users able to sign in and their subject identifiers stable through cutover.
Inventory user pools, app clients and triggers
Your platform or identity team lists every Cognito user pool, app client, custom domain, identity provider connection, resource server and Lambda trigger, along with the apps that call each one. Record which settings are fixed at pool creation, such as sign-in attributes, because they shape what you can carry over. The step is done when you have a written inventory that each application owner has checked against their own code and configuration. Confirm every item with your own app list, since the inventory is the basis for every later step.
Design the ZITADEL structure
Architects decide how instances, organizations, projects and applications will map to your tenants and products, and which roles and grants each application needs. They also choose the self-hosting deployment on PostgreSQL 14 or later, with Docker Compose, Kubernetes or a Linux binary, and confirm the database version against ZITADEL's supported range. The output is a mapping document approved by the application owners and a test environment built from it. Confirm the chosen deployment model against ZITADEL's self-hosting documentation before procurement.
Export users and attributes from Cognito
The identity team pulls profiles, attributes, group memberships and status from each user pool using the Cognito APIs or tooling your team already uses. Cognito exports do not include password hashes, so these files carry identity data but not credentials. The step is complete when record counts match the pool and a sample of profiles has been checked attribute by attribute. Plan the credential path now: either force a password reset for every user, or rely on just-in-time migration so users prove their password at their next sign-in.
Import users or set up just-in-time migration
Engineers load the exported profiles into ZITADEL, or configure a just-in-time path that checks a user against Cognito on first sign-in and then stores the account in ZITADEL. The choice depends on whether your users can tolerate a reset and whether Cognito remains reachable during the migration window. ZITADEL documents migration guides for other platforms, and you should review the Cognito-specific steps against your pool settings before running anything. The step is done when a test user from each population can sign in and their attributes match.
Rebuild Lambda trigger logic as Actions
Developers take each Cognito Lambda trigger, such as pre sign-up, post confirmation or token generation, and reimplement its business rules as ZITADEL Actions. Each rule is tested against the sign-in and token flows it previously affected, including claims added to tokens and any blocking checks. The output is a list of triggers with their ZITADEL equivalents and test results showing matching behavior. Confirm each Action against the ZITADEL documentation for your version, because trigger behavior is the part most likely to differ from what your apps expect.
Preserve the subject identifier applications rely on
Applications often store the OIDC sub claim as a foreign key, so a new identifier would orphan existing records. The team decides whether ZITADEL can issue the same identifier for each migrated user or whether the applications need a mapping table from the old Cognito value to the new one. Engineers verify this in a test environment by comparing stored subjects with tokens issued after migration. The step is done when every application can resolve an existing user record from a token issued by ZITADEL, and the mapping approach is documented.
Run parallel logins and cut over
Teams point a limited group of users or a staging application at ZITADEL while the Cognito pool stays live, and compare sign-in success, token contents and session behavior. Security staff confirm that passkeys, MFA and password fallback behave as your policy requires. Cutover switches each application's issuer and client configuration in turn, with a documented rollback path to the Cognito app client until the last application is confirmed. The step is complete when every application signs in through ZITADEL and monitoring shows no unexpected authentication failures.
Questions buyers ask before choosing ZITADEL over Cognito
How much effort does a self-hosted ZITADEL need from our team?
Running ZITADEL yourself means operating a PostgreSQL database, the ZITADEL service itself, and the network, TLS, backup and upgrade work around them. The supported self-hosting paths are Linux or macOS binaries, Docker Compose and Kubernetes, and ZITADEL recommends a Kubernetes cluster with the official Helm chart for high availability. Effort rises with the number of environments, the availability target and the depth of your existing Kubernetes and PostgreSQL skills. Cognito removes all of that infrastructure work, so the trade is your staff time against AWS charges. Ask for the operational runbook, the upgrade approach and the backup design in any written scope before you commit.
Can our team run ZITADEL without outside help?
Your team can run ZITADEL alone if it already operates Kubernetes or Docker-based services, PostgreSQL and certificate management, and has someone who can read the ZITADEL documentation closely. Gaps usually appear in the first upgrade, in high availability design and in incident response at night. Many organizations keep internal ownership and bring in an outside team for the initial build, hardening or a support retainer. DeployOpen plans, implements, hardens, backs up, upgrades and supports self-hosted platforms in your own infrastructure, and ongoing support and upgrades are available as retainers. Decide which tasks your team will own before choosing the split.
How long does a migration from Cognito to ZITADEL take?
No supplied figure gives a duration, so treat any number you hear as a guess until it is written into a scope. The main drivers are the number of user pools and app clients, how much Lambda trigger logic must be rebuilt as ZITADEL Actions, whether you migrate users in bulk or just in time as they sign in, and how many customer organizations need their own identity provider. Cognito does not export password hashes in its user listing, so the password strategy also affects timing. Fixed-scope engagements agree deliverables and timelines in writing before work starts, which is the place to ask for a schedule tied to these drivers. Ask for the sequence of cutover and rollback steps as well.
Does ZITADEL cover passkeys and SAML for our applications?
ZITADEL supports passwordless login with passkeys based on FIDO2 and WebAuthn, with fallback to password login. It also implements SAML 2.0 alongside OpenID Connect and OAuth 2.0, and it can federate with external SAML or OIDC providers such as Entra ID and Okta. Confirm the exact passkey policies, enrollment flows and SAML service provider settings your applications need against the current documentation, and test them with your own clients before cutover. Cognito's feature set for these areas differs, so map each requirement you have to a specific test in your scope rather than assuming parity.
What does the AGPL license on ZITADEL mean for us?
ZITADEL's core, Console and hosted login are licensed under AGPL-3.0 since version 3.0, while APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0. The AGPL's network clause can require you to offer source code to users who interact with a modified version over a network, so the answer depends on whether you modify ZITADEL itself. Running an unmodified release for internal or customer logins typically raises different obligations than shipping a changed version. Have your legal counsel review the terms for your specific deployment, and do not treat this summary as legal advice.
When is ZITADEL Cloud the middle option?
ZITADEL Cloud fits when you want ZITADEL's features and data model without operating PostgreSQL, the service and upgrades yourself, but still want to avoid a fully AWS-managed pool. It is the middle option between Cognito and self-hosting, and it suits teams whose data residency and contractual needs allow a hosted vendor. Compare it on hosting location, support terms, and how the price scales with your users and organizations. Check current pricing on ZITADEL's pricing page, and check Cognito pricing with AWS, since both change over time and vary by feature tier.
What drives the total cost of self-hosted ZITADEL compared with Cognito?
Cognito bills by usage through AWS, while self-hosted ZITADEL moves the cost into infrastructure, database, staff time, support and migration. Recurring costs include compute for the ZITADEL service, a highly available PostgreSQL service, backups, monitoring, and the people who patch and upgrade the platform. One-time costs include the initial migration, rebuilding Lambda trigger logic as Actions, and hardening. Costs rise with availability targets, the number of environments and the depth of your identity integrations. Ask any provider for a written breakdown of each component, its owner and what it depends on, so you can compare it with your current AWS bill.
How DeployOpen helps you evaluate or move to ZITADEL
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For Amazon Cognito vs ZITADEL, we start with a written scope that tests your login requirements against ZITADEL in your environment before any migration work begins.
How we scope
- Inventory the Cognito user pools, app clients, custom attributes, federated identity providers and Lambda triggers that the written scope must cover.
- Define which tenancy model fits, comparing ZITADEL instances, organizations and projects against your current pool layout.
- Agree in writing whether passkeys, SAML, SCIM and the AGPL license terms on ZITADEL's core match your requirements.
How we build
- Deploy ZITADEL on PostgreSQL 14 or later with Docker Compose or the official Helm chart, sized to your availability needs.
- Configure organizations, projects, applications, identity provider federation and passkey policies with fallback to password login.
- Test sign-in, token claims and app integrations in a non-production environment before any user moves.
How we hand over
- Document the deployed architecture, configuration, runbooks for backup and upgrades, and the decisions taken during the engagement.
- Deliver migration plans for bulk import versus sign-in-time migration, including how Cognito password hashes are or are not available.
- Train your operations and security staff on administration, access policies and incident steps for the new identity service.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing support, upgrades and continuous security testing of the login flows are available as a retainer.
- Ask any quote to itemize implementation, migration, hosting, support and retainer effort so each cost component is visible.
