AWS Cognito Alternative: India Data Residency

Run Amazon Cognito for an Indian user base and you've probably hit the wall already: there's no Cognito user pool you can pin to an Indian Region, so your identity data lives somewhere across an ocean. For years, fine. But the Digital Personal Data Protection Act 2023 enforces from 13 May 2027, and "somewhere across an ocean" is exactly the question your legal team will start asking. So let's get specific. What Cognito's residency limits really are, what DPDP actually demands, and how to move identity data back inside the country without rebuilding your login stack from scratch.

This is general information, not legal advice. Confirm specifics with your own counsel.

Cognito's residency and region limits

Amazon Cognito is a Regional service. Your user pool lives in one AWS Region, and the user records, attributes, and tokens for that pool stay tied to it. The list of Regions where Cognito is available is published by AWS, and you should check the current AWS Regional Services List before you plan anything.

The practical issue for India is straightforward. AWS operates the Asia Pacific (Mumbai) and Asia Pacific (Hyderabad) Regions, but service availability per Region varies, and your existing pool was almost certainly created in whatever Region your account defaulted to years ago. Cognito does not move a user pool between Regions for you. There is no "change Region" button. If your pool is in us-east-1, your Indian users' identity data is in Northern Virginia, full stop.

A few specific limits matter when you think about Cognito data residency and Cognito region control:

• A user pool is single-Region. You cannot spread one pool across two Regions for residency. Cross-Region replication of a pool is not a native feature.
• Migration is a rebuild. Moving to a different Region means standing up a new pool and migrating users into it, usually with the Migrate-User Lambda trigger or a bulk import. Passwords cannot be exported in plaintext, so most teams re-trigger a credential flow on first login.
• Managed means opaque. You do not control the underlying storage, the backup location, or the exact processing boundaries. You get the Region as your only residency lever.
• Federated and social data flows out by design. If you federate Google or a SAML IdP, parts of that flow touch endpoints outside your chosen Region regardless of pool placement.

None of this makes Cognito a bad product. It makes it a product whose residency model is "pick a Region and trust us," which is a different posture from "prove the data stayed in India."

What DPDP residency demands

The DPDP Act 2023 does not impose a blanket data-localization mandate the way some earlier drafts and the RBI payments circular did. The Act's cross-border mechanism is Section 16, which lets the Central Government restrict transfer of personal data to specified countries by notification. The Act is published by MeitY, and the official gazette text is the primary source you should cite internally.

The detail that changes architecture decisions sits in the Draft DPDP Rules, specifically the residency provision often discussed as Rule 15, which contemplates that certain classes of personal data handled by Significant Data Fiduciaries may be subject to localization requirements set by a government-appointed committee. The Rules were placed for public consultation by MeitY, and the DPDP Rules consultation is the authority to track because the final text governs what you actually have to do. We wrote up the residency angle in more depth in data residency under DPDP Rule 15.

For most CIAM teams the working conclusion is this. You may not be legally forced to keep every byte in India today, but the direction of travel is clear, sectoral regulators already require it, and "our login provider physically cannot place data in India" is a weak position to be defending when the Rules finalize. Building so India data can stay in India is the conservative, future-proof choice. That is the design intent behind NamoID: a per-organization data residency hint, built to keep India data in India.

DPDP also brings obligations that are not about geography but show up in the same conversation:

• A real audit trail. You need to show who consented to what, when, and through which channel. Cognito's CloudTrail logs are operational, not consent-grade. See DPDP audit trail for engineers for what regulator-readable actually means.
• Data Subject Access Requests. A Data Principal can ask for their data and ask for erasure. You need an export path and a deletion path that you can defend.
• Breach notification timelines. DPDP expects prompt reporting, and your identity layer is a common breach surface.

So "residency" in the DPDP sense is residency plus auditability plus subject rights, not just a Region dropdown.

Self-hosted vs managed

Once residency matters, the build-versus-buy question narrows to a more specific one: who runs the thing, and where does it run? There are three honest options.

Stay on managed Cognito, accept the Region you can get. Lowest effort. You are betting that DPDP's final Rules will not force your data class into India, or that AWS will offer what you need in a Mumbai or Hyderabad pool in time. For some non-sensitive consumer apps this bet is reasonable. For anything touching Aadhaar, DigiLocker, or financial KYC, it is risky.

Self-hosted CIAM in India. You run an identity provider on infrastructure you control, in an Indian Region or an Indian data center. You get full Cognito region control because you chose the Region. The cost is operational: you patch it, you scale it, you carry the on-call. Open-source identity servers can do this, but most were not built for India's rails and you end up bolting DigiLocker, Aadhaar offline-XML, WhatsApp OTP, and DLT-compliant SMS onto them yourself.

A managed-but-India-resident provider. A vendor runs the CIAM control plane, but the deployment and data path are designed to keep Indian data in Indian infrastructure, with the India verification rails built in rather than bolted on. This is the lane NamoID is built for. You get a single OIDC issuer URL with PKCE, refresh-token rotation, RS256-signed JWTs, and a JWKS endpoint that only ever exposes the public key, plus the India rails behind the same issuer.

The trade-off across the three is the usual one. Managed-elsewhere is cheapest to operate and weakest on residency. Self-hosted is strongest on control and heaviest on operations. The India-resident managed option aims for the middle: you keep the residency story and the India rails without owning the patch cycle. For the broader framing, build vs buy auth in India walks through the decision with cost in mind.

A comparison table

The table below compares the three approaches on the dimensions that decide a DPDP-era CIAM choice. Read it as a positioning map, not a benchmark, since the right answer depends on your data class and risk appetite.

The pattern is that Cognito is strong on operations and standards but gives you one residency lever, the self-hosted route gives you control at the cost of building every India rail yourself, and an India-first provider tries to hand you both the residency posture and the rails.

If you are also weighing the non-AWS managed incumbents, the same residency logic applies, and we cover it in Auth0 alternative for India.

Migrating off Cognito

Moving identity providers sounds scary because login is load-bearing. It is very doable if you sequence it. Because Cognito speaks standard OIDC and OAuth 2.1, and any serious alternative does too, the integration surface in your app is small.

1. Inventory what you actually use. List your Cognito user pool attributes, your app clients, your OAuth scopes, your social and SAML identity providers, and any Lambda triggers. Most teams use a fraction of Cognito's surface, which makes the move smaller than feared.

2. Stand up the new issuer and read its discovery document. Any compliant provider publishes an OIDC discovery document. Point your client library at it and you get the endpoints automatically.

curl https://issuer.example.com/.well-known/openid-configuration

{
  "issuer": "https://issuer.example.com",
  "authorization_endpoint": "https://issuer.example.com/v1/oauth/authorize",
  "token_endpoint": "https://issuer.example.com/v1/oauth/token",
  "jwks_uri": "https://issuer.example.com/v1/oauth/jwks.json",
  "response_types_supported": ["code"],
  "grant_types_supported": ["authorization_code", "refresh_token"],
  "code_challenge_methods_supported": ["S256"]
}

Notice there is no token or id_token in response_types_supported. That is OAuth 2.1 behaving correctly: authorization-code with PKCE only, no implicit grant. If you are fuzzy on why that matters, OAuth 2.1 vs 2.0 and PKCE explained cover it.

3. Switch your app to the authorization-code-plus-PKCE flow. Your client generates a code verifier and challenge, sends the challenge on the authorize request, and exchanges the code for tokens. A standard token exchange looks like this:

curl -X POST https://issuer.example.com/v1/oauth/token \
  -d grant_type=authorization_code \
  -d client_id=your_client_id \
  -d code=AUTH_CODE_FROM_REDIRECT \
  -d redirect_uri=https://yourapp.example.com/callback \
  -d code_verifier=ORIGINAL_PKCE_VERIFIER

4. Migrate users without exporting passwords. You cannot pull plaintext passwords out of Cognito, so use a just-in-time migration. On a user's first login against the new issuer, verify them through a fresh credential moment (an OTP, a passkey enrollment, or a social re-link) and create the local record then. This is the same pattern Cognito's own Migrate-User trigger uses, just in reverse, and it doubles as a clean point to capture DPDP consent.

5. Run both in parallel, then cut over. Keep Cognito live while you migrate active users on login. Set a cutover date for the long tail, then send a re-authentication prompt. Because both sides are standard OIDC, your relying-party code does not fork.

6. Verify token validation against the new JWKS. Your APIs validate RS256-signed JWTs against the issuer's public keys. Make sure your resource servers fetch the new jwks_uri, respect key rotation, and only trust the public key. The private signing key should never leave the identity service, which is exactly how NamoID is built.

The migration is mostly a config and rollout exercise, not a rewrite, precisely because everyone is speaking the same standards.

A recommendation

Here is the honest read. If you serve Indian users and your data class is sensitive, or you handle Aadhaar, DigiLocker, or KYC at all, plan to keep that identity data in India and plan for a regulator-readable audit trail. Cognito can be excellent at standards and operations, but its one residency lever and its lack of native India rails make it a weak fit for that specific requirement.

If residency is not yet a hard constraint for your data class, staying on Cognito and watching the DPDP Rules is a defensible position. The moment Aadhaar, DigiLocker, financial KYC, or a Significant Data Fiduciary designation enters the picture, the calculus flips toward an India-resident provider with the rails and the audit trail built in.

NamoID is built for exactly that flip: one OIDC issuer URL, PKCE on every flow, rotating refresh tokens, the India verification rails behind the same issuer, an append-only event trail with DSAR export, and a residency design meant to keep India data in India. It is pre-launch, so treat this as how the product is built rather than a shipped claim, and bring your own counsel to the legal questions.

For the wider picture of running one issuer for auth, India rails, and DPDP together, see one issuer URL for auth, India rails, and DPDP.

FAQ

Can Amazon Cognito store data in India?

Cognito is a Regional service, so its data lives in whichever AWS Region your user pool was created in. AWS does run Mumbai and Hyderabad Regions, but service availability varies per Region and Cognito does not move an existing pool between Regions. If your pool was created elsewhere, the data is there until you migrate to a new pool. Check the current AWS Regional Services List for what is available.

Does DPDP require me to keep identity data in India?

The DPDP Act 2023 uses a Section 16 mechanism that lets the government restrict transfers to specified countries, and the Draft DPDP Rules contemplate localization for certain data classes handled by Significant Data Fiduciaries. There is no blanket localization mandate in the Act itself today, but the direction favors keeping sensitive India data local. This is general information, not legal advice.

How hard is it to migrate from Cognito to another OIDC provider?

The app-side change is small because both sides speak standard OIDC and OAuth 2.1, so you mostly repoint at a new discovery document and switch to authorization-code with PKCE. The real work is user migration, since Cognito will not export plaintext passwords. Most teams use just-in-time migration on first login, which also gives a clean point to capture fresh consent.

Is self-hosted CIAM in India worth the operational cost?

Self-hosting gives you full region control and a strong residency story, but you carry patching, scaling, and on-call, and you usually have to build India rails like DigiLocker and Aadhaar yourself. A managed-but-India-resident provider aims to give you the residency posture and the rails without the operational burden, which is the middle path many teams prefer.

See it for your stack

Weighing a move off Cognito to something you can defend under DPDP? We're happy to walk through your current pool and what a residency-first migration would look like. The product is pre-launch, so this is a conversation, not a signup.

Book a 30-minute demo at calendly.com/polymindslabs/30min, or reach the team at hello@namoid.in.