What Is Amazon Cognito? User Pools vs Identity Pools

Definition

Amazon Cognito is AWS's managed identity platform for web and mobile apps — a user directory, an authentication server, and an authorization service in one. It handles sign-up, sign-in, social and enterprise federation, multi-factor authentication, and the exchange of a user's identity for temporary AWS credentials.

The thing to understand first is that Cognito is really two independent products that are frequently used together and constantly confused with each other:

| | User pool | Identity pool | | --- | --- | --- | | What it is | A user directory and OIDC identity provider | A credential broker in front of AWS STS | | What it gives you | JWTs: an ID token, an access token, a refresh token | Temporary AWS credentials (access key, secret, session token) | | Answers the question | Who is this user, and are they who they say they are? | What AWS resources may this identity touch? | | Typical consumer | Your app, your API, API Gateway, an ALB | The AWS SDK calling S3, DynamoDB, etc. directly | | Guest / anonymous users | No | Yes — unauthenticated identities are supported | | Needs the other one? | No | No |

If your app calls your own backend API, you almost certainly want a user pool and nothing else. If your mobile app calls AWS services directly — uploading to an S3 bucket from the device, say — you need an identity pool to turn the user's proof of identity into IAM credentials. Used together, the flow is: sign in against the user pool → receive JWTs → exchange a JWT at the identity pool → receive AWS credentials scoped to an IAM role.

Cognito scales to tens of millions of monthly active users (MAUs) and plugs into API Gateway, Application Load Balancer, AppSync, and anything else that accepts a JWT.

How It Works

User Pools

A User Pool is a user directory. It stores usernames, passwords, custom attributes, verified email/phone, and MFA settings. It offers:

• Sign-up and sign-in via email, phone, username, or custom aliases; password policies are configurable.
• Hosted UI — an AWS-hosted OAuth 2.0 / OpenID Connect authorization server with customizable branding.
• Federation — SAML 2.0 (for corporate IdPs) and OIDC (Google, Facebook, Apple, Amazon, or any OIDC provider), mapped into the User Pool's user directory.
• MFA — SMS, TOTP, or passkeys (WebAuthn); can be required, optional, or adaptive (risk-based).
• JWT tokens — on successful sign-in, Cognito issues an ID token, an access token, and a refresh token. Tokens are signed with the pool's RS256 keys (published at /.well-known/jwks.json).
• Lambda triggers — hooks at pre-signup, post-confirmation, pre-authentication, post-authentication, pre-token-generation, and more, enabling custom flows (SSO to legacy systems, adding custom claims, custom email/SMS via SES/SNS).
• Advanced security features — compromised-credential detection (checking against known-breached password lists), adaptive authentication (step-up MFA on risky sign-ins), and rich audit events.

Identity Pools

An Identity Pool (federated identities) converts an authenticated identity — from a User Pool, a SAML/OIDC IdP, Login with Amazon/Apple/Google/Facebook, or even a guest — into temporary AWS credentials via sts:AssumeRoleWithWebIdentity. You map identity provider + user attributes to IAM roles, enabling fine-grained per-user access to S3 buckets, DynamoDB tables, or any AWS API — without ever deploying a backend.

User Pools and Identity Pools are independent and often used together: the User Pool authenticates the user and returns a JWT; the Identity Pool trades that JWT for AWS credentials scoped to an IAM role.

Key Features and Limits

• Up to 40 million users per User Pool (soft quota, raisable).
• Token lifetimes — ID and access tokens: 5 minutes to 24 hours (default 1 hour). Refresh tokens: 60 minutes to 10 years (default 30 days).
• Lambda triggers — 12+ hook points covering the full auth lifecycle.
• MFA options — SMS text messages, Time-based One-Time Passwords (TOTP), passkeys (WebAuthn / FIDO2).
• Federation — SAML 2.0, OIDC, and built-in social providers (Google, Facebook, Amazon, Apple).
• User pool domains — either a custom domain (auth.example.com with an ACM certificate) or a Cognito-provided <prefix>.auth.<region>.amazoncognito.com.
• Advanced security features (ASF) — priced per MAU separately; includes compromised credentials detection and adaptive auth.
• Rate limits — category-based (e.g., UserAuthentication category 120 req/s per account per Region; raisable).
• Integration points — API Gateway JWT authorizers, ALB authenticate-cognito action, AppSync authentication, Verified Permissions (AVP) for policy-based authorization.

Common Use Cases

1. Web and mobile app user auth — sign-up/sign-in, social logins, password reset, email verification, MFA — without rolling your own auth service.
2. B2B SaaS with SSO — SAML/OIDC federation from customer IdPs (Okta, Azure AD) so enterprise users sign in with their corporate accounts.
3. API authorization — API Gateway REST and HTTP APIs validate Cognito-issued JWTs via a built-in authorizer.
4. Direct-to-AWS mobile apps — Identity Pool trades the JWT for scoped IAM credentials so a mobile client can upload to S3 or write to DynamoDB directly.
5. Serverless web apps — Amplify Auth uses Cognito under the hood for Next.js / React / Vue / iOS / Android apps.
6. ALB-protected internal apps — Application Load Balancer's authenticate-cognito action gates any downstream app (ECS, EC2) behind Cognito sign-in.

Cognito Identity Providers

A user pool can act as a service provider to external identity providers (IdPs) while remaining a single OIDC identity provider to your app. That indirection is the main reason to use Cognito at all: your application standardises on one set of JWTs, and Cognito absorbs the differences between everything upstream.

Supported identity providers:

• Social / OAuth 2.0 — Amazon, Google, Apple, and Facebook, out of the box.
• SAML 2.0 — any corporate IdP: Okta, Entra ID (Azure AD), ADFS, Ping, OneLogin. Cognito consumes the SAML assertion and reissues it as an OIDC token.
• OpenID Connect (OIDC) — any standards-compliant OIDC provider.
• The user pool itself — "local" users who signed up directly, stored in Cognito's own directory.
• Developer-authenticated identities (identity pools only) — bring your own custom authentication and hand Cognito the resulting claims.

Attribute mapping is where this usually goes wrong. Each IdP sends claims with its own names, and you map them onto user pool attributes; if a required attribute has no mapping, sign-in fails at the point of user creation rather than at the IdP, which makes it look like a federation problem when it is a configuration problem.

Two limits worth knowing before designing around federation. Federated users are not local users — several user pool features, including MFA, custom authentication flows, and security monitoring, are unavailable to them, because the upstream IdP owns authentication. And SAML/OIDC federation is billed separately from ordinary MAUs (see pricing below), with a much smaller free tier.

Passkeys and Passwordless Sign-In

Cognito supports passkeys (WebAuthn), email one-time codes, and SMS one-time codes as first-class sign-in methods — not merely as a second factor. Passkeys use FIDO public-key cryptography, so there is no shared secret to phish, replay, or leak in a breach.

The catch is tiering: passkeys, passwordless sign-in, managed login, and email MFA are Essentials-tier features and are not available on the Lite tier. New user pools default to Essentials, but pools created before the tiered pricing model may sit on Lite, where the passkey options simply do not appear in the console. If you are looking for passkey configuration and cannot find it, check the pool's feature plan first.

Amazon Cognito Pricing

Cognito bills per monthly active user (MAU) — a user who performs an identity operation in a given calendar month — across three feature tiers:

| Tier | Free tier | Price per MAU | Includes | | --- | --- | --- | --- | | Lite | 10,000 MAU | $0.0055 (next 90,000), then $0.0046 | Basic registration, authentication, user management. No passkeys, managed login, or passwordless | | Essentials (default for new pools) | 10,000 MAU | $0.015 | Everything in Lite plus passkeys, managed login, passwordless sign-in, email MFA | | Plus | None | $0.020 | Everything in Essentials plus threat protection: risk-based adaptive authentication, compromised-credential detection |

Billed separately from the tiers above:

• SAML / OIDC federated users — 50 MAU free per month, then $0.015 per MAU, on every tier.
• Machine-to-machine (M2M) authorization — $0.00225 per token request ($0.002925 with multi-Region replication). Registering app clients is free.
• Identity pools — free. You pay only for the AWS services the issued credentials go on to use.
• SMS — MFA and verification messages are billed through Amazon SNS at destination-country rates. Email verification via SES is far cheaper.

The tier is a property of the user pool and can be changed, so the most common cost mistake is leaving a pool on Plus for an app that never needed threat protection — nearly 4× the Lite rate for features you are not using.

Pros and Cons

Pros

• Turnkey CIAM — sign-up, sign-in, MFA, password reset, and hosted UI in days, not months.
• Native AWS integration: API Gateway JWT authorizer, ALB, AppSync, Amplify, Verified Permissions.
• Identity Pools make direct-to-AWS mobile apps possible without a backend.
• Lambda triggers offer deep customization without leaving the managed service.

Cons

• Hosted UI customization is limited compared with Auth0 / Okta CIC.
• Error messages from failed sign-ins are sometimes vague; debugging OIDC/SAML federation typically requires reading CloudTrail + CloudWatch carefully.
• Historically has had feature gaps (e.g., no passwordless by default until the 2024 passkey release).
• Advanced security features and SMS can meaningfully increase the bill at scale.

Comparison with Alternatives

| Feature | Amazon Cognito | Auth0 / Okta CIC | Firebase Authentication | | --- | --- | --- | --- | | Cloud tie-in | AWS-native | Multi-cloud | Google Cloud | | Direct-to-cloud credentials | Identity Pools → STS | Needs custom broker | Firebase rules | | Pricing model | MAU tiered | MAU tiered | MAU tiered | | Customization | Lambda triggers | Rules / Actions engine | Cloud Functions triggers | | Best for | AWS-heavy apps, serverless, Amplify | Cross-cloud, rich branding, B2B CIAM | Mobile + Google Cloud apps |

Exam Relevance

Cognito is commonly tested on:

• Solutions Architect Associate (SAA-C03) — choosing User Pool vs Identity Pool; gating APIs with Cognito; federating SAML IdPs.
• Developer Associate (DVA-C02) — JWT authorizers on API Gateway, Amplify Auth, Lambda triggers, refresh token flows.
• Security Specialty (SCS-C02) — federated identity patterns, advanced security features, MFA choices, mapping JWT claims to IAM roles via Identity Pools.
• Machine Learning and Data Engineer tracks occasionally reference Cognito for securing APIs in front of ML endpoints.

Classic exam trap: candidates conflate User Pools (authentication → JWTs) with Identity Pools (federated identities → AWS credentials). A question about letting a mobile app call DynamoDB directly with per-user row-level access is answered by Identity Pool + IAM role with condition keys like cognito-identity.amazonaws.com:sub — not a User Pool alone. Conversely, a question about securing an API Gateway endpoint with sign-in is answered by a User Pool with a JWT authorizer.

Common Pitfalls

• User Pool vs Identity Pool confusion. A User Pool is the directory that authenticates users and issues JWTs; an Identity Pool exchanges a token for temporary AWS IAM credentials. Many teams wire up the wrong one — you usually need the User Pool for sign-in and only add an Identity Pool if the app must call AWS services directly.
• Vendor lock-in on user export. You can import users but cannot export their password hashes. Plan a migration path (JIT migration via a pre-auth Lambda trigger) before you have a million users.
• Lambda trigger loops and failures. A pre-token-generation or pre-sign-up trigger that errors blocks all sign-ups; one that re-invokes Cognito can loop. Keep triggers fast, defensive, and idempotent.
• Token lifetimes and refresh. Access/ID tokens default to 1 hour; mishandling refresh tokens (or setting them too long) causes either constant re-logins or lingering sessions after a user is disabled.
• Case sensitivity and aliases. By default usernames are case-sensitive and immutable. Enable email/phone aliases up front — you can't retrofit case-insensitivity onto an existing pool.

Cost Model (What Actually Drives the Bill)

Cognito User Pools are priced per Monthly Active User (MAU) — a user who performs an identity operation in the month — with a free tier and higher per-MAU rates once you enable threat protection / advanced security (the Plus tier) or use SAML/OIDC federated identities, which are priced separately. The practical implications:

• Cost scales with active users, not total registered users — a dormant account costs nothing that month.
• Crossing the free-tier MAU threshold, or turning on advanced security across your whole user base, are the two events that create a sudden jump. Enable threat protection selectively.
• Machine-to-machine (client-credentials) flows are billed differently from human MAUs — verify against the current Cognito pricing page before modeling a large deployment.

Frequently Asked Questions

Q: What is the difference between a Cognito User Pool and an Identity Pool?

A: A User Pool is a user directory that handles sign-up, sign-in, MFA, password reset, and federation, and issues OIDC-compliant JWTs (ID token, access token, refresh token). An Identity Pool is a credential broker that exchanges a token from a User Pool — or any supported IdP, including SAML, OIDC, Facebook, Google, Apple, or guest — for temporary AWS credentials via sts:AssumeRoleWithWebIdentity. Use a User Pool for app sign-in and API authorization; use an Identity Pool when clients must call AWS APIs directly with scoped IAM roles.

Q: Which identity providers does Amazon Cognito support?

A: A user pool can federate to the social providers Amazon, Google, Apple, and Facebook out of the box; to any SAML 2.0 enterprise IdP such as Okta, Entra ID (Azure AD), ADFS, Ping, or OneLogin; and to any standards-compliant OpenID Connect provider. It can also hold "local" users who signed up directly in Cognito's own directory. Identity pools additionally accept developer-authenticated identities, letting you plug in a custom authentication system entirely. Whichever you use, Cognito normalises the result into one set of JWTs so your application only implements one token format. Be aware that federated users are not local users: MFA, custom authentication flows, and security monitoring do not apply to them, because the upstream IdP owns authentication.

Q: Does Amazon Cognito support passkeys?

A: Yes — Cognito supports passkeys (WebAuthn) as a first-class sign-in method, along with passwordless email and SMS one-time codes. The important caveat is tiering: passkeys, passwordless sign-in, managed login, and email MFA are Essentials-tier features and are unavailable on the Lite tier. New user pools default to Essentials, but pools created before AWS introduced tiered pricing may still be on Lite, where the passkey options do not appear in the console at all. If you cannot find passkey configuration, check the pool's feature plan before assuming it is a bug.

Q: How does Cognito compare to Auth0 and Firebase Authentication?

A: Cognito excels when your app lives on AWS: it ships with hosted UI, Lambda triggers, API Gateway/ALB/AppSync integrations, and Identity Pools for direct-to-AWS credentials. Auth0 / Okta Customer Identity Cloud is multi-cloud-friendly with a richer rules/actions engine, deeper extensibility, and more polished branding — but costs more per MAU and lacks a native IAM role broker. Firebase Authentication is best when you're already on Google Cloud / Firebase; it integrates tightly with Firestore security rules but doesn't federate to AWS. For AWS-heavy workloads, Cognito almost always wins on cost and integration; Auth0 often wins for complex B2B CIAM across multiple clouds.

Q: Can I customize Cognito's sign-in flow?

A: Yes, via Lambda triggers. You can hook pre-signup (e.g., whitelist email domains), post-confirmation (create a row in your DB), pre-authentication (block certain conditions), pre-token-generation (inject custom claims), custom message (override verification emails), and custom auth challenges (build passwordless or MFA flows). For client-side look-and-feel, the Hosted UI supports a custom domain, CSS, and logo; for deeper UI control, skip the Hosted UI and call the Cognito APIs directly from your frontend or use the Amplify Auth libraries.

Q: How is Amazon Cognito priced?

A: Cognito User Pools bill per Monthly Active User (MAU) — a user who signs in or performs an identity action that month — with a free tier for standard authentication. Enabling advanced security / threat protection (the Plus tier) and using SAML/OIDC federated identities carry separate, higher per-MAU rates. Because billing is by active users, dormant accounts cost nothing; the cost jumps come from crossing the free tier or enabling advanced features fleet-wide.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official Amazon Cognito documentation before making production decisions.