IAM Identity Center: what every AWS developer should know

Managing access across multiple AWS accounts used to mean creating and rotating IAM users for every engineer, contractor, and team member—a nightmare at scale. IAM Identity Center flips this on its head: one login, one identity, permissions across all your accounts. If you're running more than a handful of AWS accounts, this service should already be part of your foundation.

The problem it solves

Before IAM Identity Center existed, here's what multi-account sprawl looked like:

• You create an IAM user in Account A with programmatic access
• You create a nearly identical user in Account B, C, D, E
• Each user has different keys, different MFA setup, different expiry policies
• One engineer leaves, and you have five accounts to clean up
• Someone's MFA device breaks at 2 AM, and you're manually resetting access across multiple accounts

It's operationally expensive and breeds security gaps. IAM Identity Center centralizes this entire problem: one identity source, one set of permissions rules, applied consistently everywhere.

Central users and groups

IAM Identity Center is built on the idea of a central identity store. In most setups, this isn't AWS—it's your company's existing identity provider: Google Workspace, Microsoft Entra ID (formerly Azure AD), Okta, or others.

When you enable IAM Identity Center, AWS becomes a consumer of that identity source. You don't create users in IAM Identity Center; you sync them from your directory, or you manage them directly within the service if you're using its built-in identity store. Your users have one password, one MFA device, one profile—full stop.

Groups work the same way. You create a group called platform-engineers in your identity provider, add five people to it, then assign that group to a permission set in Account A and a different permission set in Account B. When someone leaves your company, you remove them from the directory. Thirty seconds later, they can't access any AWS account. No manual cleanup, no orphaned keys.

Real-world example: onboarding an engineer

Let's say you hire a backend engineer tomorrow. In the old world:

1. Create IAM user in dev account, generate keys, send securely
2. Create IAM user in staging account, generate keys, send securely
3. Create IAM user in prod account, generate keys, send securely
4. Set up MFA for each user separately
5. Document which keys go where
6. After three months, upgrade their permissions—modify four IAM users

With IAM Identity Center:

1. Add them to the backend-engineers group in your directory (Google Workspace, Entra ID, etc.)
2. That group is already mapped to permission sets in dev, staging, and prod
3. They log in to the AWS console the next day with their corporate email and existing MFA
4. Done

Permission sets per account

A permission set is a portable IAM policy template. It's not tied to one user or one account; it's a reusable bundle of permissions you apply to a principal (user or group) in a specific account.

The key insight: the same engineer might have different permissions in different accounts. They should have admin access in the dev account but read-only in prod. Permission sets let you define this precisely.

Anatomy of a permission set

When you create a permission set, you specify:

• Name: something descriptive like BackendDeveloper-Dev or DBA-Prod
• Permissions: either AWS managed policies (like AdministratorAccess) or inline custom policies
• Session duration: how long a console session lasts before requiring re-login
• Relay state: where to redirect after login (optional)

Once created, you assign that permission set to a user or group in a specific AWS account. The same group can have different permission sets across different accounts.

Example permission set assignment

Your backend-engineers group might have:

• BackendDeveloper-Dev (AdministratorAccess) in the dev account
• BackendDeveloper-Staging (limited EC2 and RDS permissions) in staging
• BackendDeveloper-Prod (read-only CloudWatch and logs, deploy via CI/CD only) in prod

When a backend engineer logs in, they see tabs for each account with the permissions they actually need for that context.

Integration with Google Workspace and Entra ID

IAM Identity Center isn't a standalone user database—it's a connector. It syncs with your existing identity provider or uses its own managed directory.

If your company uses Google Workspace (G Suite), you can use OIDC federation or SAML to sync users and groups directly into IAM Identity Center. Same with Entra ID, Okta, or any SCIM-compatible provider. This means:

• Users authenticate with their corporate credentials
• MFA is shared; they use the same authenticator app
• When they leave, their directory account disables, and AWS access revokes automatically
• You're not managing passwords in multiple places

Google Workspace example setup

You enable SAML 2.0 federation between Google Workspace and IAM Identity Center. Google Workspace becomes your authoritative identity source. Every morning, users in the developers@yourcompany.com Google Group sync into IAM Identity Center. When someone is removed from that group, their AWS access disappears within minutes.

No API keys, no password resets in AWS, no manual account provisioning. Just one source of truth.

Replaces IAM users for humans

This is the core shift in thinking: IAM users are for applications and services, not humans. If you're still creating IAM users for developers to log into the console, you're doing it the old way.

IAM Identity Center gives every human a federated login experience. Under the hood, when they authenticate, IAM Identity Center creates temporary STS credentials in the target account with the permissions from the assigned permission set. Those credentials have a limited lifetime (default one hour for console sessions). When the session expires, they're gone.

Compare this to IAM users:

• IAM user: long-lived access key, you manage rotation, keys can leak and persist indefinitely
• IAM Identity Center: temporary credentials issued on login, automatic expiry, no long-lived keys for humans to steal or lose

This is better security by default. It's also better operations: you're not managing password policies or access key rotation schedules across dozens of users.

What about programmatic access?

Applications still need long-lived credentials. For that, you use IAM users (traditional) or assume an IAM role via OIDC, service accounts, or other mechanisms. But if a person needs to access AWS, they should be coming through IAM Identity Center. Period.

Common mistakes

• Treating permission sets like IAM users. Permission sets are templates, not accounts. You can reuse the same permission set across dozens of users and groups. Don't overthink it; start with broad permission sets and refine as you grow.
• Not setting a session duration. The default is one hour for console access. This is good, but make sure it matches your security policy. For sensitive accounts, drop it to 15 minutes. For dev, 8 hours is fine.
• Forgetting to provision the account assignment. You create a permission set, but if you don't assign it to a user or group in at least one account, nothing happens. The permission set exists but does nothing. Always complete the assignment step.
• Mixing IAM users and IAM Identity Center for console access. Don't do both. Migrate all human console access to IAM Identity Center, then delete the old IAM users. Running both is confusing and undermines security.
• Creating overly granular permission sets. You don't need 50 permission sets. Start with maybe five to ten: admin for dev, developer for shared environments, read-only for prod, DBA for infrastructure, etc. You can always refine later.

Key takeaways

• IAM Identity Center replaces the need to create IAM users for humans; use federated login instead.
• One identity source (Google Workspace, Entra ID, or IAM Identity Center's managed directory) feeds users and groups to all your AWS accounts.
• Permission sets are reusable bundles of permissions assigned to users or groups per account, letting you enforce different access levels across dev, staging, and prod with minimal redundancy.
• Session duration limits and automatic credential expiry make IAM Identity Center more secure than long-lived IAM user keys.
• Set it up early in your AWS journey, especially if you're managing more than one account. It scales cleanly.