IAM Identity Center - Why It Replaces IAM Users

IAM users were the original way to grant human access to AWS. You create a user, attach policies, and hand out credentials. For a single account with two people, that's fine. Once you have multiple accounts and a team, it falls apart.

IAM Identity Center (formerly AWS SSO) is the modern replacement. It provides centralised access management across all accounts in your organization, with temporary credentials and single sign-on.

Why Not IAM Users?

IAM users have fundamental problems for human access:

Long-lived credentials: Access keys don't expire. If leaked, they're valid until someone revokes them.

Per-account management: Each account needs its own IAM users. Ten accounts means ten sets of credentials per person.

No central directory: There's no organisation-wide view of who has access to what.

Password fatigue: Users manage separate passwords for each account.

AWS is clear on this: "IAM Identity Center is our recommended front door into AWS." IAM users still exist for programmatic access that can't use OIDC, but human users should use Identity Center.

How Identity Center Works

Identity Center provides a central identity store that grants access across all your AWS accounts:

Click to expand

1038 × 421px

Identity Store: Where users and groups live. Can be the built-in store or connected to an external identity provider (Microsoft Entra ID, Okta, etc.).

Permission Sets: Define what users can do. Similar to IAM policies but assigned across accounts.

Account Assignments: Link users/groups to permission sets in specific accounts.

When a user logs in, Identity Center creates temporary credentials scoped to the account and permission set they selected. No long-lived credentials anywhere.

Setting Up Identity Center

We use the official AWS IA Terraform module, which simplifies the configuration significantly:

module "aws_iam_identity_center" {
  source  = "aws-ia/iam-identity-center/aws"
  version = "~> 1.0"

  # Users
  sso_users = {
    "jane.doe" = {
      user_name        = "jane.doe"
      given_name       = "Jane"
      family_name      = "Doe"
      email            = "jane.doe@example.com"
      display_name     = "Jane Doe"
      group_membership = ["PlatformAdministrators"]
    }
  }

  # Groups
  sso_groups = {
    "PlatformAdministrators" = {
      group_name        = "PlatformAdministrators"
      group_description = "Platform team with full administrative access"
    }
  }

  # Permission sets and assignments covered in next post
}

Getting the Instance ARN

Identity Center has a single instance per organization. The module needs its ARN:

data "aws_ssoadmin_instances" "main" {}

locals {
  identity_center_instance_arn = tolist(data.aws_ssoadmin_instances.main.arns)[0]
  identity_center_instance_id  = tolist(data.aws_ssoadmin_instances.main.identity_store_ids)[0]
}

Note: You need to enable Identity Center in the AWS Console before this data source works. Like Organizations, initial enablement is a manual step.

The Identity Store

The identity store is where users and groups are defined. We use the built-in store rather than connecting to an external identity provider - the team is small, there's no existing corporate IdP, and the built-in store is fully manageable through Terraform.

The module handles user and group creation:

sso_users = {
  "developer.one" = {
    given_name       = "Developer"
    family_name      = "One"
    email            = "dev1@example.com"
    group_membership = ["Developers"]
  }
  "developer.two" = {
    given_name       = "Developer"
    family_name      = "Two"
    email            = "dev2@example.com"
    group_membership = ["Developers"]
  }
}

Each user gets credentials managed by Identity Center. No IAM users, no access keys.

Group-Based Access

AWS recommends managing access at the group level. Every user should belong to at least one group:

sso_groups = {
  "PlatformAdministrators" = {
    group_description = "Platform team with full administrative access"
  }
  "Developers" = {
    group_description = "Development team with limited access"
  }
  "Auditors" = {
    group_description = "Audit team with read-only access"
  }
}

Benefits of group-based access:

• Easier onboarding: Add user to group, they get appropriate permissions
• Consistent access: Everyone in a group has the same permissions
• Audit trail: Review group membership rather than individual assignments
• Scalability: Adding a new account means assigning groups, not individual users

The User Experience

When users access AWS through Identity Center, they:

1. Navigate to the Identity Center portal URL (something like https://d-xxxxxxxxxx.awsapps.com/start)
2. Authenticate (password, MFA, or federated through IdP)
3. See a list of accounts and permission sets they can access
4. Click to get console access or CLI credentials

For CLI access, users can configure the AWS CLI with SSO:

aws configure sso
# Follow the prompts to set up SSO profile

aws sso login --profile my-profile
# Opens browser for authentication

Temporary credentials are cached locally. While the SSO session is valid, the CLI can fetch new role credentials without re-authentication. Once the session expires, you run aws sso login again. No more managing access keys.

First User Bootstrap Problem

There's a chicken-and-egg problem: you need Identity Center access to deploy the identity management infrastructure, but Identity Center doesn't exist until you deploy it.

The solution:

1. Initial deployment: Use root account credentials or an IAM user in the management account
2. Create first Identity Center user: Terraform creates the user/group/permissions
3. Subsequent changes: Use Identity Center credentials

After the first deployment, root credentials should never be used for day-to-day work.

MFA Enforcement

Identity Center supports MFA out of the box. Users can configure:

• TOTP apps (Google Authenticator, Authy)
• Hardware security keys (YubiKey)
• Built-in authenticators

MFA settings are configured in the Identity Center console, not through Terraform (there's no Terraform resource for this yet). We require MFA for all users - enable it under Identity Center > Settings > Authentication.

What About Service Accounts?

Identity Center is for humans. For automated access (CI/CD, applications), use:

If you must create an IAM user for a service account, scope it narrowly and rotate keys regularly.

Common Mistakes

Skipping groups: Assigning permissions directly to users doesn't scale. Always use groups.

Too many groups: Start simple. You can add groups as access patterns emerge.

Not enabling MFA: Identity Center without MFA is barely better than IAM users.

Forgetting the console step: Identity Center must be enabled in the console before Terraform can manage it.

What's Next

With users and groups defined, the next step is permission sets - the policies that determine what each group can actually do in each account. Part 7 covers the permission sets we use and why.