A Thorough Guide to Amazon Cognito: Building a “Practical Authentication Foundation” with User Pools and Identity Pools | Comparison with GCP Identity Platform and Azure AD B2C (Microsoft Entra External ID)
Introduction: Cognito Is Not a “Login Feature” but an Operable Authentication Foundation
Amazon Cognito (hereafter, Cognito) is a service that provides user authentication and authorization for web and mobile applications. The first important point in understanding Cognito is that it is not merely about “storing users and letting them log in.” Rather, it enables you to design an authentication foundation that includes social/external IdP integration, token issuance (OIDC/OAuth 2.0), and even the issuance of permissions that allow applications to securely access AWS resources.
It is explicitly stated that User Pools act as an OpenID Connect (OIDC) IdP from the application’s perspective, meaning Cognito provides the “standards-based protocol foundation” required for modern authentication platforms.
On the other hand, authentication is not something you “build once and you’re done.” Operational load accumulates daily: MFA, password resets, anomalous logins, account takeover prevention, how costs grow as users increase, and even handling support inquiries “when things fail.” That’s why this article carefully explains how to make Cognito operable in practice—using User Pools and Identity Pools as the core—covering the design order, where to make trade-offs, and what you should decide first.
In addition, we place Cognito alongside GCP Identity Platform and Azure AD B2C (including the Microsoft Entra External ID context), which are often compared in the CIAM (Customer Identity and Access Management) space. Official sources state that GCP Identity Platform provides authentication backends/SDKs/UI libraries for applications and that its pricing is primarily MAU (Monthly Active Users)-based.
On the Azure side, official documentation notes that Azure AD B2C is a CIAM offering and that it cannot be purchased by new customers after May 1, 2025. At the same time, it states that existing customers can continue using it, and the FAQ indicates a policy of supporting it at least through May 2030.
Who This Article Helps: The More “Authentication Problems” Your Team Has, the More It Pays Off
First, this is aimed at application development teams (backend/frontend). Login and sign-up are the entrance to a product, so requirements often change frequently: you want to add social login, require email verification, improve account deletion/recovery, or align authentication UI with your brand. If you build a structure that can be “grown later” in line with standard protocols from the start, development becomes far less painful. Cognito User Pools act as an OIDC IdP and provide organized endpoints for integrating with external IdPs (SAML/OIDC, etc.).
Next, it’s for SRE/operations teams. Authentication issues have a large blast radius, and support inquiries tend to spike when something goes wrong. That’s why it’s important to design a system that can isolate where “I can’t log in” is coming from—user attributes, IdP integration, tokens, expiration, rate limits, email delivery, and so on. In the Cognito world, components such as Managed Login/Hosted UI, external IdP integration, and the issuance of temporary AWS credentials via Identity Pools are well separated, making it easier to build a diagnostic map.
It’s also recommended for architects who are considering multi-cloud or future migration. GCP Identity Platform and Azure AD B2C share commonalities—pricing centered on MAU, integration via standard protocols (OIDC/OAuth, SAML, etc.)—but lock-in often shows up most strongly in “how you build UI,” “operational habits,” and “changes in support/sales policies.” Since Azure AD B2C’s purchase eligibility conditions have changed, future new-adoption decisions especially need to be designed with “institutional constraints” as a premise.
1. The Overall Picture of Cognito: Understand User Pools and Identity Pools by Separating Their Roles
Cognito is easier to understand when you view it as two main pillars:
- User Pools: An application’s user directory + authentication (OIDC IdP)
- Identity Pools: A mechanism that issues temporary AWS credentials to federated users
It is explicitly stated in official documentation that User Pools function as an OIDC IdP from the application’s perspective. In other words, it’s easy to adopt a modern structure where the app verifies the ID/access tokens issued by the User Pool and then creates a session.
Identity Pools, meanwhile, are described as a “directory of federated identities” that can generate temporary AWS credentials in exchange for tokens. They can start with guest (unauthenticated) users and later expand permissions after sign-in.
A practical tip is not to try to use everything from the start. For many apps, it’s most stable to first establish “login and tokens” with User Pools, and add Identity Pools only when there’s a requirement to allow direct access to AWS resources.
2. User Pools: Use Them as an OIDC IdP for Your Application
2-1. What User Pools Provide: Turning Login into a “Standard Protocol”
User Pools are a user directory and are officially described as acting as an OIDC IdP for applications. This is important because it allows you to implement login not as a “custom proprietary mechanism,” but on top of “standard protocols.”
User Pool endpoints (managed login, SAML, OIDC, OAuth 2.0, etc.) are organized as a server contract. It clearly states that accessing the authorization endpoint initiates authentication, and that the Authorize endpoint redirects to the managed login page or an IdP’s sign-in.
With this “explicitly documented behavior,” the application can focus on minimum responsibilities: “obtain tokens,” “verify them,” and “refresh them.” Fine-grained login behavior (screens/flows) can be delegated to Cognito as much as possible—or, even if you build your own, you can design it along standard flows.
2-2. Managed Login / Hosted UI: Start by Having a “Manageable Login Screen”
Cognito is organized such that you can implement login along OIDC/OAuth 2.0 flows using Hosted UI/Managed Login, and materials also explain perspectives like Authorization Code Flow (including PKCE).
In practice, especially early on, it often matters more to “run the full experience safely” (including password resets and email verification) than to “beautifully design a custom login screen.” A phased approach tends to fail less: get it working with Managed Login first, then deeply customize the UI after brand requirements solidify.
2-3. External IdP Integration: Expand to “Company SSO” and “Social Login” via OIDC/SAML
Documentation describes procedures for adding OIDC as an external IdP to a User Pool, allowing you to gradually add social/external providers.
The design challenge here is that “application UX” and “enterprise ID governance” often collide:
- In B2C (general consumers), you tend to favor email/password, social login, passwordless, etc., to reduce drop-off.
- In B2B (enterprise customers), you tend to favor customer SSO via SAML/OIDC and emphasize access control aligned with offboarding/transfers.
Cognito has the protocol building blocks to support both. However, the hard part is the integration policy—cases like “the same email exists in multiple IdPs” or “corporate SSO and personal login coexist.” This requires operational rules before technical implementation.
3. Identity Pools: Secure Access to AWS Resources via “Token → Temporary Credentials”
Identity Pools are described as a directory that can exchange federated identities for AWS credentials, generating temporary AWS credentials for users whether they are signed in or not. It also explicitly states that you can choose the level of permissions assigned to users via IAM roles and policies.
Typical cases where this helps:
- A mobile app wants to access AWS services directly (but you don’t want it to hold long-lived keys)
- You want to allow guest (not logged in) usage for some functionality, then expand permissions after login
- You want to use User Pool or external IdP tokens as the “entry point” and issue least-privilege AWS access rights
A key design tip is: “grant only what you truly need” in Identity Pool permissions. Direct AWS access is convenient, but overly broad permissions can cause large damage if abused. Since Identity Pools let you tune permissions via IAM roles, least-privilege design is a foundational requirement.
4. Practical Samples: Turn Cognito Design into Reusable “Patterns” for the Team
Here are three representative patterns you can use immediately in discussions—think of them as patterns of thought rather than code.
Sample A: Consumer Web App (Start with User Pool Only)
- Goal: Stabilize sign-up, login, and password reset first
- Architecture: User Pool + Managed Login (Hosted UI) to establish OIDC/OAuth flow
- Operational key: Document email verification and reset flows for “can’t log in” support inquiries
At the beginning, it’s recommended to create a thin “login specification” document, even if minimal—support guidance is prone to incidents when it varies by person.
Sample B: Enterprise SaaS (Introduce Customer SSO Gradually)
- Goal: Provide SSO (SAML/OIDC) per customer and make governance aligned with offboarding/transfers easier
- Architecture: Add external IdPs (OIDC/SAML) to User Pool and unify entry via the Authorize endpoint
- Operational key: Template the “IdP settings, attribute mapping, and testing steps” for each customer
SSO is hardest for the “first customer”; templates pay off strongly from the second onward. If you plan for templating early, future onboarding becomes much easier.
Sample C: Mobile / Game (Expand Permissions from Guest → Logged-in)
- Goal: Allow play as a guest, but enable saving/syncing after login
- Architecture: Issue temporary AWS credentials to unauthenticated (guest) users via Identity Pools, then switch to a different role to increase permissions after login
- Operational key: Explicitly define the difference between guest and logged-in permissions and audit to prevent permissions from growing too broad
5. How to Think About Pricing: Cognito Is “MAU Billing,” Making It More Predictable Through Design
Cognito’s pricing page indicates that User Pools are billed based on MAU (Monthly Active Users), and provides examples of tiered billing beyond a free tier (e.g., 10,000 MAU). It also notes that email sending uses SES and is billed separately.
A practical point is that authentication costs tend to scale with user counts, making it easier to update estimates as the product grows. Conversely, if you change authentication specs in a way that “increases login frequency” carelessly, it may affect MAU definitions. It’s safer to discuss business initiatives (like forced re-login) and cost impact in the same meeting.
Also, since Cognito pricing shows multiple tiers (e.g., Lite), it can be easier to make decisions later if you incorporate how much advanced security protection you’ll need into your design thinking early.
6. Comparison with GCP Identity Platform: Implementation Experience Is Easier to Drive via “SDK/Libraries”
GCP Identity Platform is officially described as providing backend services, SDKs, and UI libraries that make it easier to add user authentication to apps and services. In other words, the developer experience naturally flows as: “wire in sign-in via SDK, then manage via console.”
On pricing, it explicitly states that many sign-in methods are MAU-billed, and phone/multi-factor authentication is billed per message sent.
A simple way to compare with Cognito:
- Both are MAU-centered: easier to estimate costs as you scale
- GCP puts SDK/library guidance front and center: less ambiguity in app integration
- AWS naturally integrates AWS permission issuance via User Pools + Identity Pools: the stronger the need for direct AWS resource access, the more natural it feels
Rather than one being strictly superior, the “fit” depends on how much your app directly touches AWS/GCP resources and how much of the auth surface you want to build yourself.
7. Comparison with Azure AD B2C (Microsoft Entra External ID Context): Watch for Changed Institutional Preconditions
Azure AD B2C is officially described as a CIAM solution that enables SSO access to apps and APIs using social/enterprise/local accounts. Overviews also touch on scale (many users/many authentications) and threat monitoring (password spray, brute force, etc.).
The key point, however, is that official Japanese documentation explicitly states: as of May 1, 2025, Azure AD B2C can no longer be purchased by new customers.
Additionally, the FAQ indicates that existing Azure AD B2C customers can continue using it (experiences such as creating new tenants and user flows remain unchanged) and that the policy is to continue support at least through May 2030.
Therefore, comparing against Azure requires not only technical evaluation but also:
- Are you continuing as an existing customer? (institutional prerequisites differ)
- If you are new, you must evaluate including the positioning of Entra External ID (based on official FAQs and guidance)
In that sense, Cognito (based on the official sources referenced here) does not show a similar “new adoption restriction” note, so you may find it easier to proceed with design under comparatively lower institutional uncertainty.
8. A Checklist to Avoid Failure: 7 Items to Decide in the First Two Weeks
Finally, here are “decisions” that become important later, packaged in a team-friendly form. Aligning on these early makes it less likely your authentication will break as it grows.
- Priority of login methods
- Email/password first? Social first? Enterprise SSO as a premise?
- Token and session handling
- Use Authorization Code + PKCE, and define UX for refresh and expiration
- How much user attributes (profile) to store in Cognito
- Keep Cognito “auth only,” or store part of the profile too (affects future migration ease)
- External IdP integration rules
- Handling of same email, linking policy, separation strategy by tenant/customer
- Whether AWS resource access is required (need for Identity Pools)
- If needed, separate unauthenticated/authenticated roles and enforce least privilege
- Frequency of cost estimate updates
- When to update MAU projections, and how to treat email sending as a separate cost factor
- Standard operating procedures for support inquiries
- First-response flows for “can’t log in,” email not received, password reset failure, SSO misconfiguration, etc.
Summary: Cognito Lets You Grow Authentication with “Standard Protocols + Operational Patterns”
Cognito User Pools function as an OIDC IdP from the application’s perspective, and managed login plus OIDC/OAuth 2.0 endpoints are organized. This makes it easier to implement login along standard protocols and to expand later to external IdPs and operations.
Identity Pools issue temporary AWS credentials to federated users and allow permission tuning via IAM roles, making them highly useful when you need secure direct access to AWS resources.
GCP Identity Platform makes it easy to embed app authentication via SDKs/libraries, with clear MAU-centered pricing.
Azure AD B2C has a strong CIAM feature structure, but because institutional constraints like new-purchase eligibility are explicitly documented, adoption decisions should confirm prerequisites along with technical evaluation.
As a first step, it’s recommended to use User Pools with “Authorization Code Flow + Managed Login” as the baseline and to build operational patterns including support inquiry handling. Then, add Identity Pools only when direct AWS resource access is required. This approach helps authentication shift from “something scary” to an “operable foundation.”