> ## Documentation Index > Fetch the complete documentation index at: https://docs.databunker.org/llms.txt > Use this file to discover all available pages before exploring further. # AWS Cognito vs Databunker Pro — PII Vault & Tokenization > LLM-built auth plus Databunker Pro — the modern replacement for AWS Cognito, with self-hosted PII vaulting and compliance built in. AWS Cognito was built in 2014, when standing up authentication — sign-in, password reset, OAuth, SSO federation, JWT issuance — was genuinely a multi-month project. That world is gone. With LLM-assisted development and modern auth libraries, the auth layer is now an afternoon's work. What's actually hard in 2026 is the part Cognito doesn't solve: **encrypting PII at rest, tokenising sensitive fields, tracking consent, handling DSARs, proving compliance to an auditor, and meeting cross-border data-localisation laws.** **Databunker Pro + LLM-built auth** is the modern replacement for Cognito. You build the auth glue once, in your own codebase, with full control. Databunker Pro handles everything Cognito can't: the PII vault, format-preserving tokenization, consent management, audit, and compliance — self-hosted in any cloud, on-premises, or across jurisdictions. ## Authentication is now an afternoon, not a project LLMs (Claude, Cursor, Copilot, GitHub Codespaces) scaffold a complete auth system from a single prompt: email/password sign-up, Google / Microsoft / Apple SSO, JWT sessions with refresh, password reset, MFA via TOTP or magic links, account recovery. Pair that with a well-maintained library and you have a production-ready auth layer in hours, not months. A non-exhaustive list of mature, well-documented auth libraries that pair cleanly with LLM-driven implementation: | Stack | Library | | -------------- | -------------------------------------------------------------------------------------------------------------------------- | | Node / Next.js | [NextAuth.js / Auth.js](https://authjs.dev/), [Lucia](https://lucia-auth.com/), [Passport.js](https://www.passportjs.org/) | | Python | [Authlib](https://authlib.org/), [FastAPI Users](https://fastapi-users.github.io/fastapi-users/) | | Go | [Ory Kratos](https://www.ory.sh/kratos/), [GoTrue](https://github.com/supabase/gotrue) | | Multi-language | [Keycloak](https://www.keycloak.org/), [Ory](https://www.ory.sh/), [Authelia](https://www.authelia.com/) | Any of these, combined with an LLM that knows your codebase, produces a working auth system the same day you start. The deliverable is yours — no per-MAU bill, no vendor lock-in, no AWS dependency. ## What auth doesn't solve — and Databunker Pro does The auth layer issues identity tokens. It does **not** answer: * **Where do you store your users' PII so it isn't exposed in logs, backups, or a SQL injection?** * **How do you tokenise credit-card numbers to shrink PCI scope?** * **How do you fulfil a GDPR / DPDPA right-to-erasure request across every system that holds the user's data?** * **How do you prove to an auditor that every PII access was authorised and logged?** * **How do you keep Indian users' PII in India, Russian users' PII in Russia, and EU users' PII in the EU — all simultaneously?** These are the hard problems. Databunker Pro is built for them: * **[PII Vault](/pro/get-started/pii-vault)** — AES-256 per-record encryption; the application stores only UUID tokens, never PII. * **[Format-preserving tokenization](/pro/concepts/tokenization)** — Luhn-valid credit-card tokens, integer tokens, timestamp tokens. Real PCI-scope reduction. * **Consent management** — legal-basis tracking, user agreements, processing-activity records aligned with GDPR / DPDPA. * **DPO operations** — DSAR fulfilment, right-to-erasure, data-portability via the separate [Databunker DPO product](https://databunker.org/use-case/dpo-management-portal/). * **Audit trail** — per-record, per-field, with encrypted PII context. See [Access control](/pro/administration/access-control). * **[Multi-tenancy](/pro/administration/multi-tenancy)** — PostgreSQL row-level security; cryptographic per-domain isolation. * **[Record versioning](/pro/concepts/record-versioning)** — immutable history for every user record. * **[Fuzzy search](/pro/concepts/fuzzy-search)** — typo-tolerant search on encrypted data. * **[Shared records](/pro/concepts/shared-records)** — time-limited UUID references for safe cross-system sharing. * **[Shamir secret sharing](/pro/administration/shamir-keys)** — master-key recovery split across multiple custodians. * **BYOK / HYOK** — wrapping key in Kubernetes secret, AWS KMS, HashiCorp Vault, or hardware HSM. * **[Multi-jurisdiction deployment](/pro/concepts/global-deployment)** — one vault per jurisdiction (India, Russia, Turkey, EU, etc.) — a topology Cognito cannot match because Cognito is AWS-bound. * **Self-hosted** — deploy on any cloud, on-premises, in a sovereign region, or inside a customer's tenant. * **[Predictable pricing](/pro/get-started/performance)** — per-instance license, flat regardless of user count. No per-MAU bill. ## Reference architecture ```text theme={null} [ User ] ─── sign-in ───► [ Your auth layer (NextAuth / Lucia / Ory / Keycloak / ...) ] │ Built once with LLM assistance. Issues JWT / session. │ ▼ [ Your application ] │ ▼ [ Databunker Pro ] AES-256 encrypted vault Tokenization · CRBAC · audit Self-hosted, any region ``` The application database only ever stores: a user identifier, a Databunker `user_token`, and any non-PII business data. PII lives in the vault. Auth lives in your own code. ## Comparison table | Capability | AWS Cognito | Databunker Pro + your auth | | ------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------ | | **Primary purpose** | Auth + user directory | PII vault, tokenization, consent, compliance | | **Where auth lives** | Managed AWS service | In your codebase (LLM-built, mature library) | | **Where PII lives** | Cognito user attributes (AWS) | Databunker Pro vault (your infra, any cloud) | | **PII encryption** | AWS-managed KMS at the user-pool level | AES-256 per record, FIPS 140-2, customer-controlled keys | | **Tokenization (UUID + format-preserving)** | ❌ | ✅ Native; shrinks PCI scope | | **Consent management & legal basis** | ❌ | ✅ Native (GDPR / DPDPA aligned) | | **Right-to-erasure** | `AdminDeleteUser` (PII in logs/backups still your problem) | Single API call; audit-bounded; record-versioning aware | | **Audit trail** | CloudTrail (API-level) | Per-record, per-field, with encrypted PII context | | **Fuzzy search on encrypted data** | ❌ | ✅ | | **Record versioning** | ❌ | ✅ | | **Customer-held keys (BYOK / HYOK)** | KMS CMK option, AWS-bound | K8s secret, AWS KMS, HashiCorp Vault, or hardware HSM | | **Multi-tenancy** | Separate user pools | Native PostgreSQL RLS | | **Deployment** | AWS only | Any cloud, on-prem, sovereign region, customer tenant | | **Data residency** | AWS regions | Any region; [multi-jurisdiction topology](/pro/concepts/global-deployment) supported | | **Vendor lock-in** | AWS | None — Docker / Helm artifacts | | **Pricing model** | Per MAU above the free tier | Per-instance license, flat | | **Future flexibility** | Constrained by what AWS adds to Cognito | Your codebase — change auth library, add MFA mode, swap SSO provider any time | ## Migration from Cognito The honest practical answer: **Cognito does not allow exporting password hashes**, so a migration is necessarily a forced-reset event. The standard playbook: 1. **Stand up Databunker Pro** in your target environment (Docker / Helm). 2. **Build the replacement auth layer** in your codebase using an LLM and the library of your choice (NextAuth, Lucia, Ory, Keycloak, etc.). Wire it to Databunker Pro for the user record. 3. **Export the Cognito user list** — emails, attributes, group memberships — via `ListUsers`. 4. **Bulk-import into Databunker Pro** using [`UserCreateBulk`](/pro/get-started/performance) — at \~1,700 records/sec on a single instance, a typical Cognito directory imports in minutes. 5. **Migration window**: switch the auth layer to your replacement and force a one-time password reset email to every user (unavoidable — Cognito does not expose hashes). 6. **Decommission the Cognito user pool** once the population has migrated. For organisations with strict downtime / UX constraints, a **dual-running window** (Cognito for existing users, new auth + Databunker for new ones, slow migration over weeks) is preferred. Databunker Pro's bulk import and multi-tenancy support this naturally. ## Code examples ### Sign-up: auth in your codebase, PII in Databunker ```javascript theme={null} // 1. User signs up via your auth layer (NextAuth / Lucia / Ory / etc.) // Your auth issues a session and gives you the verified email. // 2. Store PII in Databunker — get back a safe UUID token const response = await axios.post('https://your-databunker/v2/UserCreate', { profile: { email: form.email, first: form.firstName, last: form.lastName, phone: form.phone, address: form.address, dob: form.dateOfBirth, } }, { headers: { 'X-Bunker-Token': process.env.DATABUNKER_API_KEY } }); const userToken = response.data.token; // 3. Store only (userId, userToken) in your app DB — zero PII anywhere outside the vault await db.query( 'INSERT INTO users (id, databunker_token) VALUES ($1, $2)', [authUser.id, userToken] ); ``` If your application database gets breached, attackers see only opaque UUIDs — no PII, no contact data, no addresses. ### Format-preserving credit-card tokenization Cognito has no concept of this. Databunker Pro tokenises a real card number into a Luhn-valid token that passes format validation in downstream systems — so legacy fraud / payment / risk systems keep working without ever seeing the real card. ```bash theme={null} curl -X POST https://your-databunker/v2/TokenCreate \ -H "X-Bunker-Token: YOUR_API_KEY" \ -d '{ "record": "4532015112830366", "tokentype": "creditcard", "slidingtime": "30d", "unique": true }' ``` ```json theme={null} { "status": "ok", "tokenuuid": "550e8400-e29b-41d4-a716-446655440000", "tokenbase": "4024007186539112" } ``` `tokenbase` passes Luhn checks and 16-digit format validation, but maps to no real card. PCI audit scope shrinks to the systems that genuinely need detokenisation. ## The bottom line Cognito was the right answer when authentication was a hard build. With LLM-assisted development, auth is an afternoon's work in your own codebase — and **you keep the code, the keys, the deployment, and the data**. Pair that with Databunker Pro and you get the secure user storage, tokenization, consent management, audit, and cross-jurisdiction sovereignty that Cognito was never designed to provide. The result: no per-MAU bill, no AWS lock-in, full control over your users' PII, and a compliance posture that holds up in a regulator review.