Identity choices

Match the mechanism to who is calling.

People who work for you → IAM Identity Center, with your existing IdP as the identity source.
Code → IAM roles: execution, task and instance roles, or OIDC federation for CI.
Your application's customers → Amazon Cognito, or a third-party customer-identity service.

Long-lived IAM user access keys are the fallback for none of these.

The map

Caller	Mechanism	Works well with	Breaks or hurts when
Employees and contractors, many accounts	IAM Identity Center + external IdP (Okta, Entra ID, Google Workspace, JumpCloud, OneLogin, CyberArk, Ping) over SAML + SCIM	Organizations (organization instance); CLI `sso-session` profiles; permission sets assigned to IdP groups	Users not provisioned (no just-in-time creation); attribute mismatches; policies pinned to `AWSReservedSSO_…` ARNs that change (`reference/identity-center/provisioned-roles-and-sessions.md`)
Employees, one or two accounts, existing IdP	IAM SAML or OIDC identity provider per account (the decision guide's per-account alternative)	Small setups	Each account configured separately; no central portal or assignments
CI/CD (GitHub Actions and similar)	IAM OIDC identity provider + role trusting `token.actions.githubusercontent.com` with `aud` and exact `sub` conditions	Short-lived credentials per job	A `sub` wildcard (`repo:<org>/<repo>:*`) trusts every branch (`guides/iam/ci-oidc-github.md`)
Workloads on AWS	Lambda execution, ECS task and EC2 instance roles	SDK default credential chains	Code that calls `sts:AssumeRole` on its own role; app permissions placed on the ECS execution role
End users of your web or mobile app	Amazon Cognito (customer identity and access management, CIAM)	Social and enterprise sign-in for apps (not collected in this hub)	Using Identity Center for customers: it is built for workforce access to AWS accounts and apps
Fine-grained authorization inside your app	Amazon Verified Permissions (Cedar policies)	Externalizing app authorization	Confusing it with IAM: it decides app-level permissions, not AWS API access
Windows workloads needing AD	AWS Directory Service (Managed Microsoft AD)	Domain join; AD as Identity Center's identity source	The AD Domain Users primary group doesn't sync to Identity Center

Identity Center with an external IdP versus the IdP's own AWS app

Okta and Entra ID can federate straight into IAM roles per account (classic SAML), or act as the identity source for Identity Center. Choose Identity Center when you have several accounts. Assignments, the access portal, CLI SSO and permission sets live in one place, and the IdP only proves who the user is and which groups they belong to (patterns/external-idp-to-identity-center.md). The per-account SAML style puts role mapping in the IdP and is per account (detailed setup not collected).

Things that work well together

IdP groups → SCIM → permission sets on accounts → CLI profiles per account and role. Group changes in the IdP flow through without touching AWS.
Identity Center attributes for access control (AccessControl:<key> SAML attributes) → ABAC conditions on aws:PrincipalTag.
OIDC roles for CI plus SCPs that deny long-lived access-key creation (SCP design in reference/organizations/scps-and-rcps.md).

Things that don't

Combination	Problem
SCIM provisioning and manual edits through the Identity Store API	Drift that SCIM won't correct; possible privilege escalation
KMS key policies or EKS `aws-auth` naming exact permission-set role ARNs	Lockout when the role is recreated with a new suffix
One IdP group used both to assign the Okta app and to push groups	Not supported
Entra ID access granted through nested groups	Those users never reach Identity Center
IAM users with access keys for people who also have SSO	Two identities to audit; keys outlive the person's access
Cognito user pools as the workforce IdP for AWS console access	Not the purpose of either service; use Identity Center (UNVERIFIED that it's impossible, only that it's off-pattern per the decision guide)