What is Amazon Cognito in AWS - login without building login

Amazon Cognito is AWS’s identity platform for web and mobile apps — a user directory, an authentication server, and an authorization service that gives you sign-up, sign-in, password reset, MFA, and Google login without building any of it yourself. But here is the counterintuitive part that trips up almost every beginner: Cognito is two different products wearing one name. A user pool is your app’s login system — it hands out JSON Web Tokens to your website. An identity pool is a credentials vending machine — it exchanges those tokens for temporary AWS access to things like S3 and DynamoDB. They work independently or together, and treating them as one thing is the number-one source of Cognito confusion on the internet.

Authentication is the part of every app that looks trivial from the outside and hides an iceberg underneath: password hashing that keeps pace with current guidance, reset flows that lock out attackers without stranding your real users, MFA that people actually complete, Google and Apple sign-in wired to standards that evolve yearly, and the quiet liability of holding a password database at all. Every one of those sentences is a project. Amazon Cognito’s pitch is that you delete the entire iceberg from your to-do list and rent it instead — and the free tier is generous enough that most small apps never see a bill.

Jake’s phone shop has a problem a login would solve. Customers drop off phones for repair, then call — sometimes three times a day, sometimes at closing time — to ask “is it ready yet?” His staff answers the same question forty times a week, and every answer interrupts an actual repair. Jake wants a simple customer portal: sign in, see your repair status, done. He asked a developer friend what the login part alone would take — sign-up, password reset, forgot-password emails, maybe Google login so customers don’t invent yet another password — and the friend quoted weeks of work before any repair-status page existed. Jake’s question to Ethan was simple: “Why is logging in so expensive to build?” Ethan’s answer is the whole reason this post exists: it doesn’t have to be.

What Amazon Cognito Actually Is

Strip the marketing away and Cognito is the sign-up and sign-in box for your app, delivered as a service. It is a user directory (the list of who your users are), an authentication server (the machinery that proves a person is who they claim to be), and an authorization service (the part that decides what they may touch), all speaking OAuth 2.0 and handing out AWS credentials when you need them. Users register, log in, reset passwords, and sign in with Google or Apple or a corporate directory — and your app receives standardized tokens that prove who they are. You write the app; Cognito handles the identity plumbing.

The platform accepts identities from three sources: the built-in user directory (people who sign up directly in your app), your enterprise directory (workforce identities via SAML 2.0 or OIDC), and consumer identity providers like Google and Facebook. That last one is the feature Jake cares about — his customers already have Google accounts, and “log in with Google” removes the entire forgotten-password phone call from the shop’s weekly queue.

And then there is the one fact that should be printed on every Cognito tutorial: the service is two components that operate independently or in tandem, based on your access needs. Two products, one name. That is the reveal from the first paragraph, and the rest of this guide is organized around it because nearly every beginner question — “do I need both?” is the most common — dissolves once you see them separately.

One compliance note for the “is it safe?” conversation: the AWS-managed side of Cognito is compliant with SOC 1–3, PCI DSS, ISO 27001, and is HIPAA-BAA eligible — your application-side configuration determines the rest. For Jake’s repair-shop portal, that compliance posture is more than any system he could hand-build in a month of weekends.

User Pools: Your Login System

A user pool is the half of Cognito you reach for when you want users to log in to your app or API. It is a full user directory — think of your phone’s contact list, but with machinery to prove each person is who they claim to be — supporting both self-service sign-up and administrator-driven account creation. Users register themselves, or you create them; both end up as a profile in the pool.

What the pool hands your app is a set of JSON Web Tokens — JWTs, which are signed chunks of data your app can verify to learn who just logged in. There are three: an ID token (who the user is — profile information), an access token (what they may do — OIDC scopes for authorizing API calls), and a refresh token (how they stay logged in without re-entering a password). And here is the sentence that saves the most confusion: a user pool does not require an identity pool. You can issue JWTs straight to an app, a web server, or an API and be finished. For Jake’s portal — a repair-status page behind a login — a user pool alone is the complete answer.

The pool also does the login-page work. Cognito serves the sign-in, sign-up, and password-reset pages for you — the feature goes by managed login now, though half the internet still says “hosted UI” — and you can customize it with CSS or a visual editor depending on your tier. Prefer your own design? The same flows run through the authentication APIs in the AWS SDKs. Either way, the forgot-password flow, the email verification codes, and the “your password must be at least this strong” rules are Cognito’s problem, not yours.

Federation lives here too. A user pool plays a dual role — service provider to your identity providers, and identity provider to your app — connecting to consumer IdPs like Facebook and Google, or workforce IdPs like Okta and Active Directory Federation Services. It is a genuinely clever arrangement: your app only ever learns Cognito’s token language, while Cognito translates Google’s, Apple’s, and your company’s SAML assertions into that one format. Single sign-on works in both directions: workforce SSO through SAML 2.0 and OIDC identity providers, and customer SSO through the public OAuth 2.0 stores Amazon, Google, Apple, and Facebook.

Identity Pools: The AWS Credential Vending Machine

An identity pool is the other half, and it exists for a different job entirely: authorizing authenticated — or anonymous — users to touch your AWS resources. Where a user pool answers “who is this person?” to your app, an identity pool answers “what may this person touch in my AWS account?” — and it answers by vending temporary AWS credentials.

Here is the mechanism. An identity pool is a collection of unique identifiers — identities — that you assign to users or guests and authorize to receive temporary AWS credentials. You present proof of authentication (claims from a SAML 2.0, OIDC, or social identity provider), the pool associates your user with an identity, and the resulting token retrieves temporary session credentials from AWS Security Token Service — STS, AWS’s credential-issuing service. The identity pool is the front desk deciding which IAM role to request on your user’s behalf.

Identity pools are also where guest access lives: you can grant temporary AWS credentials to unauthenticated users. That is the pattern behind apps that let anonymous users browse or download public files, then unlock more after signing in — guests retrieving assets first, signing in with a third-party identity provider to unlock registered-member access. The credentials land on services like Amazon S3 for storage and DynamoDB for data — both have their own plain-English guides on this site if the identity-pool route is the one you’re taking.

Access control comes in two flavors, and they compose. Role-based access control: Cognito chooses which IAM role to request based on your user’s claims — a marketing-department user receives a marketing-scoped role, tuned with IAM policies. Attribute-based access control: claims become principal tags on the STS session — a Department: marketing tag permitting read access to an S3 bucket via an aws:PrincipalTag condition. Neither requires a user pool; an identity pool accepts authenticated claims directly from workforce and consumer identity providers alike.

“Wait — my customers are going to touch S3?” Jake asked. “I just want them to see a repair status.”

“They won’t,” Ethan said. “Your portal talks to your app, and your app checks the repair status. Identity pools exist for the other architecture — when the app hands AWS credentials straight to the user’s device so it can read S3 or DynamoDB directly, without your server in the middle. That’s the mobile-app pattern. For a web portal behind your own API? You never touch an identity pool. This is why the two-products framing matters: you can buy half of Cognito and be done.”

User Pool vs Identity Pool: The Table That Ends the Confusion

This is the question every Cognito searcher eventually types — “user pool vs identity pool” — so here is the comparison, reorganized around the decisions you actually make:

When both halves team up, the flow is three steps — worth reading once even if you never need it, because it explains what the tokens are:

1. Your app user signs in through a user pool and receives OAuth 2.0 tokens.
2. Your app exchanges a user pool token with an identity pool for temporary AWS credentials, usable with AWS APIs and the AWS CLI.
3. Your app assigns the credentials session to the user and delivers authorized access to AWS services like S3 and DynamoDB.

The rule of thumb Ethan gave Jake: if your app talks to your users, you need a user pool. If your users’ devices talk to AWS directly, add the identity pool. Most web apps stop at the first sentence.

How Much Amazon Cognito Costs (and the Free Tier Nobody Believes)

Here is the small surprise promised earlier: the free tier is 10,000 monthly active users, indefinitely, and it is not attached to the 12-month AWS Free Tier. It does not expire when the free-term ends, and it is available to existing and new AWS customers alike. Jake’s repair shop could serve every customer it has ever had, logging in daily, before paying a cent — and on a new account’s free plan, the billing behavior is friendlier than most beginners fear.

Cognito bills by MAU — monthly active users: a user counts once per month if they authenticate at least once, not per login. Above the free tier, the price depends on which of the three feature tiers your user pool uses:

To make those numbers concrete: at 950,000 MAUs on Essentials, you bill 940,000 after the free 10,000, at $0.015 each — $14,100 per month. The same population on Lite splits into tiers, 90,000 MAUs at $0.0055 plus 850,000 at $0.0046, landing at $4,405. Volume pricing on Lite is the bargain path if you don’t need Essentials’ extras; Plus is the security upgrade for apps where suspicious-login detection earns its keep.

Three more facts complete the honest bill. SMS messages for MFA and verification bill separately through Amazon SNS, and email messages through Amazon SES — so a password-reset email storm has its own line item. Identity pools are free for authentication and generating unique identifiers — the credential-vending half carries no MAU charge. And there is no free tier for machine-to-machine token requests, which bill as an add-on alongside options like multi-Region replication (priced at $0.0045 per MAU on the Essentials tier).

One grandfather clause: pools created on or before November 22, 2024 keep the original 50,000-MAU free tier, and ASF-enabled pools continue on legacy ASF pricing. Everyone starting fresh gets the numbers above.

How the Login Actually Works: OAuth 2.0, OIDC, and JWTs

You can use Cognito without knowing these terms, but you cannot debug it without them, so each gets one plain sentence. OAuth 2.0 is the standard that lets a user prove their identity to one service (Google) and receive permission from another (your app) without handing over their password. OpenID Connect (OIDC) is the layer on top that says “and here is a token telling you exactly who they are.” A JWT (JSON Web Token) is the signed envelope those claims travel in — tamper-evident, because the signature breaks if anyone edits the contents.

A Cognito user pool is a full OIDC identity provider, generating JWTs for authentication and authorization from the OIDC standard. That means standard endpoints with standard behavior: an authorize endpoint, a token endpoint, a userInfo endpoint, a revoke endpoint, and a login/logout pair. Your app redirects the user to authorize; the user signs in (with a password, a passkey, or Google); Cognito redirects back with a code; your app exchanges the code at the token endpoint for the ID, access, and refresh tokens. If that sequence sounds familiar, it is — the OAuth 2.0 authorization-code flow every modern login uses. Cognito also supports PKCE (Proof Key for Code Exchange), the extension that makes the flow safe for apps that can’t keep a secret, like mobile apps and single-page apps.

Verifying a JWT — the step where your API checks a token before letting a request through — works locally: the pool publishes the public keys your API checks signatures against, so tokens are verified without a round-trip to AWS on every request. There is built-in support for caching tokens, revoking them, and for M2M — machine-to-machine — where a backend service, not a human, authenticates with its own scopes.

The cleanest place to consume those JWTs in AWS land is API Gateway with a JWT authorizer — the front door that checks the token before your Lambda or backend runs. If you are building the full serverless pattern, our API Gateway guide walks that door in plain English, including the pricing trap that catches people who pick the wrong API type.

The Features That Matter: MFA, Social Login, SSO, and Threat Protection

MFA. Multi-factor authentication supports three factors: SMS one-time codes, TOTP authenticator-app codes, and the user’s device itself. Email one-time codes arrive at the Essentials tier and above. For Jake’s repair portal, TOTP with an authenticator app is the free, non-SMS-billing option; for most customer apps, MFA is opt-in rather than forced, so the login stays friendly.

Social and federated login. Google, Apple, Facebook, and Amazon sign-in are the consumer providers at the user-pool level; SAML 2.0 and OIDC cover the enterprise side, with Okta and ADFS as the classic examples. Identity pools accept an even longer list — adding Twitter and developer-authenticated custom identities. The practical effect: your user pool normalizes every provider into one set of tokens, so your app code never branches on “is this a Google user?”

SSO. Single sign-on works in two directions: workforce SSO (your app accepts employees from a corporate SAML/OIDC identity provider) and customer SSO (your app accepts public OAuth 2.0 identities from Amazon, Google, Apple, Facebook). Both are user-pool features; neither requires the identity pool.

Passwordless. Essentials and above add sign-in with passkeys (biometrics and hardware keys) and one-time codes by email or SMS — no password stored at all. For a repair-status portal whose users will log in twice a year, “we email you a code” is arguably the friendliest login on earth, and it is a checkbox, not a project.

Threat protection (Plus tier). Adaptive, risk-based authentication; compromised-credentials detection; and exportable authentication-event logs for analysis. Plus replaces the old Advanced Security Features with up to 60% savings for comparable pools. If you are not running a bank, this is the tier you skip — which is fine, because Essentials is the default.

Customization. Lambda triggers let you inject custom logic at specific points — before token generation (add or modify claims), during user migration, on custom messages, even custom email and SMS senders. Token claims themselves are customizable at the Essentials tier and above. The pattern: Cognito handles the plumbing; you hook the joints.

Cognito vs IAM (and IAM Identity Center): Three Doors, Three Jobs

This comparison causes genuine confusion because all three services answer “who can do what,” but for entirely different doors. IAM — AWS Identity and Access Management — controls access to your AWS account: users, groups, roles, and policies deciding who may touch your S3 buckets, Lambda functions, and EC2 instances. Its audience is your team and your infrastructure. Cognito controls access to your application for people who will never see the AWS console — your customers, your app’s users. IAM Identity Center sits between them: AWS’s service for workforce single sign-on across AWS accounts and cloud applications.

Ethan’s one-liner, which Jake repeated to his developer friend: “IAM is who may touch your AWS stuff. Cognito is who may touch your app. Identity Center is how your employees get into the AWS stuff.” The three meet in exactly one place — the identity pool’s credential exchange, where a Cognito-authenticated user receives an IAM role’s temporary credentials. That junction is the whole reason the services get conflated. For the deeper tour of the permissions side, our IAM guide covers root users, policies, and roles in the same plain English.

The decision is therefore not “Cognito or IAM” — you already have IAM the moment you have an AWS account, and your app’s users will never be IAM users. The decision is whether your app needs its own login (Cognito user pool), whether your app’s users need direct AWS access (add the identity pool), and whether your team needs centralized AWS sign-in (IAM Identity Center). Three doors; walk through the one you actually need.

Cognito vs Okta, Auth0, and Keycloak: An Honest Comparison

Okta, Auth0 (owned by Okta), and Keycloak are full standalone identity platforms — customer identity and workforce SSO products that run on any cloud or on your own servers. Microsoft has its own external-identity answer on the Azure side. Each is a real, capable alternative; none of them is a line item on an AWS invoice.

What Cognito brings is the AWS-native path: an identity platform integrated with the AWS ecosystem, billed per monthly active user against your AWS account, with the free tier and tier structure this page already covered. The user-pool feature list — OIDC identity provider, SAML service provider, social federation, managed login, MFA, Lambda-trigger customization — is the baseline against which you compare anyone else’s feature sheet.

One connection worth knowing: Cognito user pools can federate to Okta as the corporate directory. So “Cognito vs Okta” is not always either/or; a common enterprise pattern is Okta for the workforce with Cognito in front of the customer app. Ethan’s verdict for Jake: “You have zero identity experts on staff and your app lives in AWS. The comparison ended before it started.”

Your First User Pool: A Console Walkthrough

The Cognito console lives in the AWS Management Console under Security, Identity, & Compliance → Cognito. The guided experience is the starting path, and the flow is short:

1. Sign in to the AWS Management Console and open Amazon Cognito. You need an AWS account — and on a new account’s free plan, Cognito’s 10,000-MAU free tier means this walkthrough costs nothing.
2. Choose Create user pool. The guided setup walks sign-in options (password, passkeys, federated providers), attribute requirements, and delivery settings. For Jake’s portal: email sign-in, Google as a social provider, and repair-ticket number as a custom attribute.
3. Pick the Essentials tier unless you know you need Lite’s price floor or Plus’s threat protection — it is the default for new pools, and you can switch tiers later.
4. Configure the app client — the representation of your application inside the pool, holding the callback URLs and allowed OAuth scopes. This is the step where the redirect_mismatch error later gets its fix, so the URL you register must match the URL your app will actually send.
5. Review and create. The pool gets a region-scoped ID and a domain; your app gets a client ID and, depending on flow, a client secret. From there, the managed login pages are live, and the sample app shows the sign-in flow end to end.

The deeper tutorial territory — wiring the hosted login into a web framework, verifying JWTs in your API, adding Google step by step — is exactly what the getting-started section and the SDK code examples cover. When you are ready to put the login in front of a real application instead of a sample, our first end-to-end AWS project wires S3, Lambda, API Gateway, and DynamoDB into a working app — the stack a login usually guards — and the full series lives at the free AWS learning hub.

When It Breaks: the Honest Failure Modes

Cognito failure modes cluster into a small set, and each has a known cause:

The two deprecations deserve their own paragraph because they generate most of the “why is Cognito not working” search traffic from people following older guides. Amazon Cognito Sync — the old dataset-synchronization feature — is closed to new customers: the service continues for existing users only, with no new feature development. If a tutorial tells you to create a Cognito Sync dataset, it is walking you toward a closed door; AWS points to alternatives for data sync in the deprecation notice. And amazon-cognito-identity-js — the standalone JavaScript SDK many older tutorials use — now greets you on its own package page with the recommendation to use the Amplify JavaScript library’s Auth features instead. Neither is a Cognito outage; both are the ecosystem moving, and the fix is reading current material rather than older blog posts — this page included, come the next AWS re:Invent.

When nothing in the table matches: AWS re:Post is the community for Cognito troubleshooting, a support case is the escalation path if you have a plan, and CloudWatch’s user-pool metrics plus CloudTrail’s Cognito event logs are the observability path for seeing what your pool actually did during the failure. The order that saves the most time: logs first, then the table, then the community — because a CloudTrail entry that says exactly which endpoint rejected the call turns a two-hour guessing session into a five-minute lookup.

Frequently Asked Questions

What is Amazon Cognito used for?

It gives web and mobile apps sign-up, sign-in, password reset, MFA, and social login without building any of it. It is a user directory, an authentication server, and an authorization service for OAuth 2.0 tokens and AWS credentials, all in one place. Typical uses: customer portals, app logins, and APIs that need to know who is calling.

Is Amazon Cognito free?

Mostly, for small apps: the Lite and Essentials tiers include 10,000 monthly active users free, indefinitely, for users who sign in directly or through social providers. Federated SAML/OIDC users get only 50 free MAUs per month, the Plus tier has no free tier, and SMS/email verification messages bill separately through SNS and SES. Identity pools are free for authentication.

What's the difference between a user pool and an identity pool?

A user pool is your app’s login system — a user directory that issues JWTs to authenticate users to your app or API. An identity pool exchanges tokens for temporary AWS credentials so users can access AWS resources like S3 directly, with optional guest access. They operate independently; most web apps need only the user pool.

How much does Amazon Cognito cost?

Essentials is $0.015 per monthly active user above 10,000 free; Plus is $0.020 per MAU with no free tier; Lite is tiered volume pricing starting at $0.0055. A 950,000-MAU pool on Essentials runs about $14,100 per month; the same pool on Lite is about $4,405. SMS and email messages bill separately.

Does Amazon Cognito support Google login?

Yes. User pools federate to consumer identity providers including Google, Apple, Facebook, and Amazon, plus enterprise SAML 2.0 and OIDC providers like Okta and ADFS. Your app receives the same Cognito-issued tokens regardless of which provider the user chose, so your code never branches per provider.

What is the hosted UI in Amazon Cognito?

It is the sign-in, sign-up, and password-reset pages that Cognito serves for you — now called managed login. It is customizable with CSS (Lite and up) or a visual editor (Essentials and up), and if you prefer your own design, the same flows are available through the authentication APIs in the AWS SDKs.

Does Amazon Cognito support MFA?

Yes. Options include SMS one-time codes, TOTP authenticator-app codes, and the user’s device as a factor. Email one-time codes arrive with the Essentials tier and above. SMS messages bill separately through Amazon SNS, which is why TOTP is the cost-free choice.

What is Amazon Cognito Sync — should I use it?

No. Amazon Cognito Sync — the feature that synchronized user dataset data across devices — is closed to new customers: the service continues for existing users only, with no new feature development. For data synchronization, use the alternatives AWS points to in the deprecation notice.

Is Amazon Cognito the same as IAM?

No. IAM controls access to your AWS account — who on your team may touch which AWS resources. Cognito handles identity for your application’s users — people who will never see the AWS console. The one meeting point: identity pools can exchange a Cognito token for an IAM role’s temporary AWS credentials.

Amazon Cognito vs Okta vs Auth0 — which should I pick?

If your app is on AWS and you have no identity team, Cognito’s integration and 10,000-user free tier are hard to beat. Okta/Auth0 suit products where customer identity is a core feature needing deep customization and multi-cloud reach, at vendor list pricing. Keycloak suits teams that want open source and can operate their own server. Cognito can also federate to Okta, so both can coexist.

What is the redirect_mismatch error and how do I fix it?

It means the callback URL your application sent during login does not exactly match a URL registered in your Cognito app client — scheme, host, and path must match character for character. Register the exact URL in the app client settings. HTTPS is required for redirect URIs, with http://localhost explicitly allowed for testing.

What are JWTs in Amazon Cognito?

JSON Web Tokens — the signed envelopes your app receives after login. Cognito’s user pool issues three: an ID token (who the user is), an access token (what they may do, with OIDC scopes), and a refresh token (how they stay signed in). Your API verifies them using the pool’s published public keys.

Does Amazon Cognito support SSO?

Yes, in two directions: your app can accept workforce identities through SAML 2.0/OIDC identity providers, and customer identities through the public OAuth 2.0 stores Amazon, Google, Apple, and Facebook. Both are user-pool features.

What is amazon-cognito-identity-js — should I still use it?

It is the standalone JavaScript SDK for Cognito that many older tutorials use. The package now recommends the Amplify JavaScript library’s Auth features in its place, so start new projects with Amplify — or call the Cognito APIs directly through the AWS SDK.

Does Amazon Cognito have an incognito mode?

No — and this is the search query that reveals a genuine mix-up. Amazon Cognito is an AWS service for application logins. “Incognito mode” is your browser’s private-browsing feature (and “browsing Amazon incognito” means opening Amazon.com in a private browser window). The two share nothing but a Latin root meaning “to know.”

What are Amazon Cognito's quotas and limits?

The quota that bites first is operations per second per Region on user-pool and identity-pool APIs — adjustable through Service Quotas, with higher request rates available as a paid add-on. The quotas page in the developer guide is the reference; the other practical ceiling is the tier-based MAU pricing covered earlier in this guide.

Where to Next..👇

💡 Recommended AWS Foundations Reading (Optional)

Master the core building blocks of AWS infrastructure, networking, and security:

• 🗺️ Regions vs. Availability Zones — The physical map that fixes half of your latency and redundancy bugs.
• 📍 Decoding AWS ARNs — How to read the exact address syntax for any resource across accounts and regions.
• 🛡️ Shared Responsibility Model — Who fixes what when an AWS service fails or leaks.
• 🌐 Public vs. Private Subnets — Visualizing traffic flow and network isolation in a VPC.
• 🚪 Internet Gateway vs. NAT Gateway — Outbound internet routing without hidden cost surprises.
• 🧱 AWS Security Groups — Stateful firewall rules explained in plain English.
• 🔑 Service-Linked Roles — The permissions AWS automatically creates and manages for you.
• 🖥️ EC2 Instance Profiles — How EC2 instances access services without hardcoded access keys.
• 🚨 Root User vs. IAM User — Why you should lock away root credentials immediately.
• 🔐 AWS MFA Setup Guide — Clear the console nagging banner and secure your account in 3 minutes.

Revision note. Written September 2026, covering Amazon Cognito’s Lite/Essentials/Plus tier structure introduced November 22, 2024, current per-MAU pricing and free-tier figures, and the Cognito Sync and amazon-cognito-identity-js status as of this writing. AWS adjusts MAU rates and feature-tier contents periodically — the pricing page and developer guide are the live truth, and the next announcement cycle will move them again. If you have been putting off building the login your project deserves because the auth part sounded like a month of weekends, take heart: the managed half of Cognito turns that month into an afternoon — and your first ten thousand users are on the house.