Cargando...
Cargando...
Fully managed customer identity and access management (CIAM) — authenticate millions of users without building auth infrastructure
Amazon Cognito provides scalable user authentication, authorization, and user management for web and mobile applications. It supports two core components: User Pools (a managed user directory with sign-up/sign-in) and Identity Pools (federated identities that exchange tokens for temporary AWS credentials via STS). Together, they solve the problem of authenticating end-users AND granting them controlled access to AWS resources — without managing servers or writing custom auth code.
Authenticate and authorize end-users (customers, consumers, app users) at scale — enabling them to securely access your application and, optionally, AWS resources directly — without using IAM users or managing your own identity infrastructure.
Use When
Avoid When
User Pools — Managed User Directory
Sign-up, sign-in, MFA, password policies, email/phone verification, account recovery, hosted UI
Identity Pools — Federated Identities
Exchange any supported token (User Pool, Google, Facebook, SAML, OIDC, custom developer-authenticated) for temporary AWS credentials via STS AssumeRoleWithWebIdentity
Hosted UI (Cognito-hosted pages)
Out-of-the-box OAuth 2.0 / OIDC login UI — customizable with CSS and logo. Enables social login without writing a single line of auth code.
OAuth 2.0 / OIDC / SAML 2.0 Support
User Pools act as both an OIDC IdP (issuing JWTs) and an OAuth 2.0 Authorization Server — integrates with any OIDC-compliant service
Multi-Factor Authentication (MFA)
TOTP (time-based OTP via authenticator apps) and SMS MFA. Can be required, optional, or off per pool. Adaptive MFA available with Advanced Security.
Advanced Security Features (ASF)
Account takeover protection, compromised credential detection, adaptive authentication risk scoring — additional cost
Lambda Triggers
Pre-sign-up, post-confirmation, pre-authentication, post-authentication, pre-token-generation, custom message, define/create/verify auth challenge, migrate user, custom email/SMS sender
User Migration Lambda Trigger
Transparently migrate users from a legacy system on first successful login — no forced password reset required
Groups and Role Mapping
Assign users to groups; groups can map to IAM roles for fine-grained access control via Identity Pools
Unauthenticated (Guest) Access
Identity Pools can issue limited AWS credentials to unauthenticated users — useful for anonymous analytics or pre-login app features
Developer Authenticated Identities
Your own backend authenticates users; you call Cognito to get credentials — for legacy auth systems
Token Customization (Pre-token-generation trigger)
Add, override, or suppress claims in ID and access tokens using Lambda — critical for RBAC and multi-tenancy
Passwordless Authentication
Implement via custom auth challenge Lambda triggers — supports magic links, biometrics, passkeys (newer pool types)
Managed Login (newer feature)
Enhanced hosted UI with more customization options, branding, and passkey support — available for newer user pool types
CloudWatch Metrics & Logging
Sign-in, sign-up, token refresh events available. Advanced Security events logged to CloudWatch.
WAF Integration
Associate AWS WAF Web ACL directly with a User Pool to protect against bots, credential stuffing, and DDoS at the Cognito endpoint
Cross-Region Replication
User Pools are regional — no native cross-region sync. For DR, you must export/import users or use a custom solution. Passwords cannot be exported (hashed).
Password Export
Passwords are stored as one-way hashes — you can export user data but NOT passwords. Migration requires the User Migration trigger or forced password reset.
Cognito User Pool Authorizer
high freqAPI Gateway natively validates Cognito User Pool JWT tokens as a built-in authorizer — no Lambda needed. Configure the Cognito User Pool authorizer in API Gateway; it verifies the token signature and expiry automatically. This is the standard pattern for securing REST APIs with Cognito.
Identity Pool → STS AssumeRoleWithWebIdentity
high freqIdentity Pools call STS AssumeRoleWithWebIdentity behind the scenes to exchange a validated token (from User Pool, Google, etc.) for temporary IAM credentials. The app then uses these credentials to directly call AWS services (S3, DynamoDB, etc.) — this is the core Identity Pool flow. Exam questions often ask which service issues the temporary credentials (answer: STS, orchestrated by Cognito).
Lambda Triggers for Auth Customization
high freqLambda triggers extend Cognito's auth flow — pre-sign-up validation, custom auth challenges (passwordless), pre-token-generation (add custom claims for multi-tenancy/RBAC), user migration from legacy systems. Critical for production apps needing custom logic without a custom auth server.
WAF Web ACL on User Pool Endpoint
high freqAttach an AWS WAF Web ACL directly to a Cognito User Pool to protect the /oauth2/token, /login, and other endpoints from credential stuffing, bot attacks, and rate-based abuse. This is the recommended approach for protecting Cognito at scale without Advanced Security Features.
Per-User S3 Access with IAM Policy Variables
high freqIdentity Pools issue temporary credentials scoped to an IAM role. Use IAM policy condition variables like ${cognito-identity.amazonaws.com:sub} to restrict each user to their own S3 prefix (e.g., s3://bucket/users/${cognito-identity.amazonaws.com:sub}/*). This enables secure, per-user data isolation without a backend proxy.
CIAM (Cognito) vs. Workforce IAM (Identity Center)
high freqCognito handles customer/consumer identity (external users of your app). IAM Identity Center handles workforce identity (employees accessing AWS accounts and business apps). These are complementary, not competing — a company can use both: Cognito for their SaaS app users, Identity Center for their developers accessing AWS accounts.
Cognito User Pool Authorization for GraphQL APIs
medium freqAWS AppSync natively supports Cognito User Pools as an authorization mode for GraphQL APIs — similar to API Gateway integration but for GraphQL. Supports fine-grained authorization using @auth directives in the schema.
ALB Built-in OIDC / Cognito Authentication
medium freqApplication Load Balancer has native support for authenticating users via Cognito User Pools or any OIDC provider before forwarding requests to targets. This offloads auth from your application entirely — no SDK integration needed in the app. Great for protecting internal web apps or adding auth to legacy apps.
SAML Federation from AD to Cognito
medium freqFor enterprise B2B apps, federate corporate Active Directory (via AD FS or AWS Managed Microsoft AD with SAML) into a Cognito User Pool as a SAML IdP. Users authenticate with their corporate credentials; Cognito issues JWTs. Distinguish this from IAM Identity Center which does AD federation for AWS console/CLI access.
Protecting CloudFront Origins with Cognito (via Lambda@Edge)
medium freqCloudFront does not natively support Cognito authorization. Use Lambda@Edge (viewer request) to validate Cognito JWTs before forwarding to the origin. This pattern protects S3-backed static sites or API origins behind CloudFront with Cognito auth.
User Pools = Authentication (who are you? → JWT tokens). Identity Pools = Authorization (what can you access? → temporary AWS credentials via STS). These are separate services that are commonly used together but serve different purposes. A question asking 'how do app users get AWS credentials' → Identity Pools. A question asking 'how do users sign in to your app' → User Pools.
When a question involves end-users (customers, consumers, app users) needing to authenticate to a web/mobile app → Cognito User Pools. When a question involves employees or developers accessing AWS accounts or internal tools → IAM Identity Center. NEVER use Cognito for workforce access management and NEVER use IAM Identity Center for consumer-scale CIAM.
API Gateway + Cognito User Pool Authorizer requires NO Lambda — it's a built-in authorizer type. The token is validated automatically. A Lambda Authorizer is needed when you need custom logic (e.g., validate a non-Cognito JWT, check a database). Don't over-engineer: if the question says 'Cognito User Pool' + 'API Gateway', the answer is the Cognito authorizer, not a Lambda authorizer.
The Pre-Token-Generation Lambda trigger is the ONLY way to add custom claims to Cognito JWTs. If a question asks how to include tenant_id, user_role, or custom attributes in the token without modifying the app, the answer is the Pre-Token-Generation trigger. This is essential for multi-tenant SaaS and RBAC implementations.
You CANNOT export user passwords from Cognito — they are stored as one-way hashes. To migrate users to Cognito from a legacy system without forcing password resets, use the User Migration Lambda trigger. On first login, the trigger calls your old system to verify credentials, then creates the user in Cognito transparently.
User Pools = Authentication → JWT tokens. Identity Pools = AWS Authorization → Temporary IAM credentials via STS. Never confuse the two — 'temporary AWS credentials' always means Identity Pools + STS.
Cognito is for CUSTOMER identity (CIAM). IAM Identity Center is for WORKFORCE identity. If the question says 'employees', 'workforce', or 'AWS Console access' → IAM Identity Center, NOT Cognito.
API Gateway has a BUILT-IN Cognito User Pool Authorizer — no Lambda required. Use Lambda Authorizer only for custom/non-Cognito token logic. The simplest answer is usually correct here.
Cognito Identity Pools support UNAUTHENTICATED (guest) access — you can issue limited AWS credentials to users who haven't logged in. This is useful for pre-login app features like anonymous analytics. Questions may describe a scenario where 'users should access some AWS resources before signing in' — the answer is Identity Pools with unauthenticated identities enabled.
ALB can authenticate users via Cognito User Pools natively — no application code changes needed. This is a great pattern for protecting legacy apps or internal dashboards. The ALB handles the OAuth 2.0 redirect flow and passes user info to the backend via HTTP headers (x-amzn-oidc-data, x-amzn-oidc-identity).
Cognito User Pools are REGIONAL — there is no built-in cross-region replication or active-active multi-region setup. For disaster recovery, you need a custom solution. If a question asks about global user authentication with high availability across regions, consider a custom solution or note this limitation.
Advanced Security Features (ASF) — account takeover protection, adaptive authentication, compromised credential detection — are an ADD-ON cost. For many use cases, AWS WAF attached to the User Pool endpoint provides sufficient protection at lower cost. Exam questions about 'protecting Cognito from credential stuffing attacks' can be answered with either WAF (cheaper) or ASF (built-in, more automated).
Cognito User Pool Groups can be mapped to IAM roles in Identity Pools. This is the standard pattern for role-based access control: user in 'admin' group → gets admin IAM role credentials; user in 'viewer' group → gets viewer IAM role credentials. The 'Choose role from token' setting in Identity Pools reads the cognito:roles claim from the JWT.
Cognito custom attributes (prefixed with 'custom:') are IMMUTABLE once created — you cannot delete, rename, or change their type. This is a critical architectural decision. Plan your user schema before creating a production pool. If you make a mistake, you must create a new pool.
SMS MFA and verification messages are sent via Amazon SNS — this is a SEPARATE cost from Cognito MAU pricing. At scale, SMS costs can exceed Cognito costs. Consider TOTP (authenticator apps) as a cost-effective MFA alternative — it's free (no SNS charges).
Common Mistake
Cognito can be used to manage employee/workforce access to AWS accounts and internal business applications
Correct
Cognito is a Customer Identity and Access Management (CIAM) service designed for external app users (customers, consumers). For workforce access — employees logging into AWS Console, CLI, or business apps — use AWS IAM Identity Center (formerly SSO). These are fundamentally different use cases.
This is the #1 Cognito misconception on certification exams. The exam frequently presents scenarios with employees needing access to AWS accounts and lists Cognito as a distractor. Remember: Cognito = Customer Identity (your app's end-users). IAM Identity Center = Workforce Identity (your company's employees). The word 'workforce' in a question is a red flag — it's NOT Cognito.
Common Mistake
IAM users and groups should be used to authenticate end-users of a web or mobile application
Correct
IAM is for AWS resource access management — not for authenticating your application's end-users. Creating IAM users for app users is an anti-pattern that creates security risks (long-lived credentials), scaling problems, and management nightmares. Use Cognito User Pools for end-user authentication. IAM is for AWS API/service access.
Exam questions often describe a scenario like 'authenticate 100,000 customers to a mobile app' and list IAM users as an option. IAM has no concept of consumer-scale authentication, social login, MFA for end-users, or self-service sign-up. Cognito was built precisely to replace this anti-pattern.
Common Mistake
Cognito Identity Pools and User Pools are the same thing / can be used interchangeably
Correct
They are distinct services with different purposes. User Pools: user directory, authentication, JWTs. Identity Pools: exchange ANY identity token (including User Pool tokens, Google, Facebook, SAML) for temporary AWS credentials (IAM). You often use BOTH together: User Pool authenticates the user → Identity Pool grants AWS access. But you can use each independently.
Many candidates see 'Cognito' and don't distinguish the two components. Exam questions exploit this by asking specifically about 'temporary AWS credentials' (Identity Pools + STS) vs. 'user sign-in tokens' (User Pools). The word 'credentials' or 'AWS access' → Identity Pools. The word 'authentication' or 'sign-in' → User Pools.
Common Mistake
AWS Directory Service (Managed Microsoft AD) is the right choice for authenticating millions of consumer app users
Correct
AWS Directory Service is designed for enterprise/corporate directory use cases — managing Windows workloads, joining EC2 instances to a domain, integrating with AD-aware applications. It is NOT designed for consumer-scale authentication. Cognito handles millions of MAUs with a pay-per-active-user model. Directory Service is priced per domain controller hour and has practical limits for consumer scale.
Questions describing 'consumer-scale authentication' or 'mobile app with millions of users' that list Directory Service as an option are testing this exact misconception. Directory Service = enterprise IT. Cognito = consumer apps.
Common Mistake
Temporary AWS credentials for mobile app users come directly from Cognito
Correct
Cognito Identity Pools orchestrate the credential exchange, but the credentials are issued by AWS STS via the AssumeRoleWithWebIdentity API call. Cognito acts as a trusted intermediary — it validates the token and calls STS on behalf of the app. The actual credential issuer is STS. This distinction matters for understanding trust policies and troubleshooting.
Exam questions ask 'which service issues temporary credentials' — the answer is STS (not Cognito). Cognito Identity Pools are the mechanism that triggers the STS call. Understanding this flow is critical for designing secure mobile app architectures and for IAM trust policy configuration.
Common Mistake
You need a Lambda Authorizer to secure API Gateway with Cognito
Correct
API Gateway has a built-in 'Cognito User Pool Authorizer' that natively validates Cognito JWTs with zero custom code. A Lambda Authorizer is only needed for custom token validation logic (non-Cognito tokens, additional database checks, etc.). Using a Lambda Authorizer when a Cognito authorizer suffices adds latency, cost, and complexity unnecessarily.
This misconception leads to over-engineered solutions on the exam. If you see 'Cognito User Pool' + 'API Gateway' in a question, the simplest and correct answer is the Cognito User Pool Authorizer — not a Lambda Authorizer.
Common Mistake
Cognito User Pools can be used as a multi-region active-active solution natively
Correct
Cognito User Pools are strictly regional. There is no native cross-region replication, active-active multi-region, or global user pool. If you need multi-region resilience, you must architect a custom solution (e.g., replicate user data, use Route 53 failover, accept eventual consistency). This is a known limitation.
High-availability architecture questions may test this. If a question asks for a 'globally available authentication solution with automatic failover' and lists Cognito alone as the answer, it's a trap — Cognito alone cannot achieve this natively.
UP = User Pools = Users log in, get a Passport (JWT token). IP = Identity Pools = Identity gets AWS Permission (temporary credentials from STS). 'UP for login, IP for AWS access.'
CIAM vs WIAM: Cognito = Customer IAM (your app's users). IAM Identity Center = Workforce IAM (your employees). C for Customer, W for Workforce.
Lambda Triggers order: Pre → Post → Pre-Token. Think 'PPP': Pre-signup, Post-confirmation, Pre-token-generation. Each fires at a different lifecycle stage.
Cognito + API Gateway = No Lambda needed (built-in authorizer). Cognito + CloudFront = Lambda@Edge needed (CloudFront has no native Cognito support). 'Gateway is native, Front needs a function.'
CertAI Tutor · SAA-C03, DVA-C02, SAP-C02, DOP-C02, CLF-C02 · 2026-02-21
In the Same Category
Comparisons
Guides & Patterns