Skip to main content

AWS Identity Service Comparison

IAM Identity Center vs Cognito: Workforce SSO vs Customer Auth on AWS

Most SaaS platforms run both — Identity Center for staff and admins, Cognito for tenants. Why they are not interchangeable, the federation patterns, and the SaaS multi-tenant authorization architecture with Verified Permissions.

Ask AI: ChatGPT Claude Perplexity Gemini

Quick Answer: IAM Identity Center is for your workforce — staff, admins, support engineers — federating to AWS accounts, Q Business, Redshift, QuickSight. Cognito is for your customers — end users of your SaaS, sign-up and sign-in, JWT issuance. They are not interchangeable; most platforms run both.

The single most common identity question on AWS is “do we use Identity Center or Cognito?” — and the answer is usually “both, for different audiences.” Confusing them leads to one of two wrong calls: trying to put customer end users in Identity Center (it does not scale that way), or trying to use Cognito for AWS console access (it does not federate IAM that way).

This comparison is written for SaaS architects designing identity for multi-tenant platforms.

The Core Distinction: Audience

IAM Identity Center (formerly AWS Single Sign-On) is the AWS-native workforce identity service. Audience: your employees, contractors, support engineers, and admins who need access to AWS accounts and identity-aware AWS services. It federates from your corporate IdP (Okta, Microsoft Entra ID, Google Workspace, Ping, JumpCloud) via SAML 2.0 + SCIM, and propagates the human identity into Q Business, Q Developer, Redshift, QuickSight, S3 Access Grants, and Athena.

Amazon Cognito is a customer-facing user directory. Audience: the end users of your SaaS — your tenants, your application’s signups, the people who pay for your product. Cognito provides hosted sign-up and sign-in flows, MFA, social and SAML federation (so your enterprise customers can SSO into your product), JWT issuance for API authentication, and customizable Lambda triggers for auth event logic.

The right way to think about it: Identity Center is for the people who work on your product; Cognito is for the people who use your product.

What Each Service Does

IAM Identity Center:

Amazon Cognito:

Cost Comparison (2026)

IAM Identity Center is free. AWS does not charge for Identity Center itself; you pay only for the AWS services your workforce uses (the credentials Identity Center issues are normal IAM credentials with normal CloudTrail billing). The cost is on the IdP side (Okta, Entra ID seat licenses) and the engineering time to wire SCIM and permission sets correctly.

Cognito (2024 reprice):

50K MAU on Essentials: ~$750/month. 500K MAU on Essentials: ~$7,500/month. Federation (SAML, OIDC, social) is included; SMS MFA bills separately at SNS rates (typically $0.01–$0.10 per SMS depending on region).

Combined typical SaaS spend: Identity Center is free for your 50–500 staff; Cognito scales with your customer count. A 100K-MAU SaaS on Essentials sits at ~$1,500/month for customer auth.

Decision Framework

Use IAM Identity Center when:

Use Cognito when:

Use both when (the common case for B2B SaaS):

Multi-Tenant SaaS Architecture We Use

For typical B2B SaaS with hundreds of tenants:

  1. One Cognito user pool, with tenant_id as a custom attribute on every user
  2. Per-tenant SAML federation via Cognito identity providers — your enterprise tenants bring their Okta / Entra and SSO into your product without touching their users
  3. JWT claims include tenant_id — your application enforces tenant scoping on every API call
  4. Verified Permissions for authorization — Cedar policies define role-based and ABAC access; AppSync BatchIsAuthorized for graph queries
  5. API Gateway / AppSync authorizer integrates Cognito for authentication + Verified Permissions for authorization
  6. CloudWatch and Cognito user-event logs feed Security Hub for audit evidence

For workforce access into AWS (operating the SaaS):

  1. IAM Identity Center connected to Okta / Entra via SAML + SCIM
  2. Permission sets per role (Engineer, SRE, Support, Read-Only-Auditor) assigned via groups
  3. Identity-aware Q Business workspace for internal data Q&A — propagates the human identity into the LLM context
  4. CloudTrail logs the human — auditors see “user@yourcompany.com performed s3:GetObject” instead of an anonymous role ARN

When You Outgrow Native AWS Identity

For Identity Center: most workforces stay on it indefinitely — it integrates well with major IdPs and AWS-side services. You leave only if your IdP demands a feature Identity Center cannot mediate (rare).

For Cognito: you outgrow it when:

For most regulated SaaS, healthtech, and fintech building on AWS, the Identity Center + Cognito + Verified Permissions trio is the right call.

Frequently Asked Questions

When do I use IAM Identity Center vs Amazon Cognito?
They solve different problems. IAM Identity Center is the AWS-native workforce identity service: it federates your employees (from Okta, Microsoft Entra ID, Google Workspace, or its own directory) into AWS accounts, applications, and identity-aware services like Q Business, Redshift, QuickSight, and S3 Access Grants — propagating the human identity end-to-end so audit logs show who, not which IAM role. Cognito is a customer-facing user pool for your SaaS application end users — sign-up, sign-in, MFA, social/SAML federation, and JWT issuance. Most platforms run both: Identity Center for staff and admins, Cognito for tenants. They are not interchangeable.
How do I federate AWS Console + CLI access from Okta or Entra ID?
Connect your IdP to IAM Identity Center via SAML 2.0 or SCIM (for automatic group/user provisioning). Define permission sets (managed-policy collections plus inline policies and a session duration up to 12 hours) and assign them to AWS accounts via groups. Users get the AWS access portal — a single landing page that issues short-lived credentials for the console and the AWS CLI v2 (`aws configure sso`). Avoid the legacy pattern of long-lived IAM users; the IAM Access Analyzer external-access findings will surface them and most auditors will flag them too. ABAC works on top of permission sets when you tag both the principal (via SCIM attribute mapping) and the resource.
What is identity propagation in IAM Identity Center?
Identity propagation (formerly "trusted identity propagation") lets the human identity from Identity Center flow end-to-end into identity-aware AWS services — Q Business, Q Developer, Redshift, QuickSight, S3 Access Grants, Athena (in preview as of 2026). Instead of CloudTrail showing "AWS role assumed by anonymous principal," you see the actual user. This matters for HIPAA §164.308(a)(1)(ii)(D) (information system activity review), SOC 2 CC6.1 (logical access — must identify the human), and PCI DSS Req 10 (logging by user). It is the single biggest reason to adopt Identity Center over legacy IAM patterns for workforce access.
How is Cognito priced in 2026?
Cognito moved to tiered pricing in late 2024. The tiers: Cognito User Pools Lite ($0.005 per MAU, no advanced features), Essentials ($0.015 per MAU, includes adaptive auth, compromised credentials check, MFA), Plus ($0.020 per MAU, includes feature-rich token customization, advanced security, custom auth challenges). MAU = monthly active user (anyone who triggered an auth event in the billing month). 50K MAU on Essentials = ~$750/month. Federation (SAML, OIDC, social) is included; SMS MFA bills separately at SNS rates. Custom domains, Lambda triggers, and identity propagation are included on all tiers.
Can Cognito handle multi-tenant SaaS authentication?
Yes — multiple patterns work. (1) Single user pool with custom attributes: every user has a `tenant_id` custom attribute; your application reads the JWT claim and scopes data accordingly. Simplest, cheapest, scales to thousands of tenants. (2) User pool per tenant: each tenant gets its own user pool — full isolation, but operational complexity grows linearly with tenants and you hit account-level service limits past ~1,000 user pools. (3) Federated identity model: each tenant brings their own IdP via SAML; Cognito acts as broker. Pattern (1) wins for ≤1,000 small-to-mid tenants; pattern (3) wins for enterprise B2B SaaS where customers demand SSO with their own IdP. We rarely recommend pattern (2).
How does Verified Permissions (Cedar) fit alongside Cognito?
Cognito handles authentication (who you are); Verified Permissions handles authorization (what you can do). After Cognito issues a JWT, your application calls Verified Permissions with the principal, action, and resource — Verified Permissions evaluates the request against Cedar policies and returns Allow / Deny. Cedar 4.x is type-safe, audit-friendly, and supports relational and hierarchical authorization. Use cases: SaaS row-level security, role-based access control with delegation, and fine-grained permissions that would otherwise live in application code. AppSync and API Gateway have native authorizers for Verified Permissions; AppSync also supports `BatchIsAuthorized` for graph traversals.
What about Cognito Identity Pools — are they deprecated?
No — Identity Pools remain part of the platform. They serve a different role: federated AWS credential vending. An Identity Pool exchanges a Cognito User Pool token (or a Google / Apple / Facebook token) for short-lived AWS IAM credentials, letting a mobile or web client call AWS services directly (S3, DynamoDB) with scoped permissions. Modern usage is narrower than it was in 2018 — most apps now talk to a backend API that holds AWS credentials, rather than vending credentials directly to clients. But for IoT, mobile apps that need direct S3 uploads, or unauthenticated access patterns, Identity Pools still fit.

Not Sure Which AWS Service Is Right?

Our AWS-certified architects help engineering teams choose the right architecture for their workload, scale, and budget — before they build the wrong thing.

Talk to AWS Architects