After building out a multi-account environment with AWS Organizations, the next thing I set up was AWS IAM Identity Center.
Creating an IAM user used to be the standard way to log in to AWS, but these days AWS recommends using IAM Identity Center whenever a human needs to log in.
This post covers why I adopted IAM Identity Center and walks through the actual setup.
What is IAM Identity Center?
IAM Identity Center (formerly AWS Single Sign-On) is a service that centrally manages authentication and authorization across multiple AWS accounts and AWS applications.
You no longer need to create an IAM user in every single AWS account —
- Log in once and access multiple accounts
- Manage users from a single place
- Simplify permission management
— these are the benefits you get.
Combined with AWS Organizations, it makes running a multi-account environment dramatically easier.
Reference:
Why Identity Center instead of IAM users?
This used to be the typical setup.
AWS Account
├── IAM User（開発者A）
├── IAM User（開発者B）
├── IAM User（管理者）
└── IAM User（監査）
But this approach comes with problems like:
- You have to create an IAM user in every account
- Passwords and MFA have to be managed individually
- Handling people transferring roles or leaving becomes a hassle
these kinds of issues.
With Identity Center, user information is managed centrally, and each AWS account only gets assigned the permissions it actually needs.
IAM Identity Center
│
├── User
├── Group
└── Permission Set
│
▼
AWS Account
The AWS Well-Architected Framework itself recommends using federated authentication for human access, and avoiding long-lived credentials (like IAM user access keys) wherever possible.
Reference:
This setup
I went with a simple setup like this.
Groups
Administrators
Developers
ReadOnly
Administrators
Members who manage the entire AWS environment.
Right now, this is just
- Me
- (Eventually) my co-representative
that I plan to put in this group.
Developers
For members doing application or infrastructure development.
I'm not using this group yet, but it'll come into play once the development team grows.
Down the line, I plan to assign things like
- PowerUserAccess
- A custom Permission Set
to this group.
ReadOnly
A view-only group.
Used for audits, reviews, and external advisors.
In my case, this is meant for granting ReadOnly access to a technical mentor.
What is a Permission Set?
In IAM Identity Center, you don't attach IAM policies to users directly — permissions are managed as a unit called a Permission Set.
Think of a Permission Set as a permissions template that gets applied to each AWS account.
This time I used AWS managed policies and created two of them.
AdministratorAccess
ReadOnlyAccess
Using AWS managed policies lets me use AWS's standard permission sets as-is.
Reference:
Why grant permissions at the group level
In IAM Identity Center, you can also assign a Permission Set directly to a user.
But this time, I went with
Administrators
│
▼
AdministratorAccess
│
▼
Dev Account
this flow, managing things at the group level instead.
This setup has a few advantages.
- Adding a new member just means adding them to a group
- Changing permissions is easy
- Prevents permission management from depending on one person's memory
- Follows AWS's recommended practice
Even as headcount grows down the line, I won't need to change how this is run.
AWS Access Portal
Enabling Identity Center creates an AWS Access Portal.
Its URL looks like this.
https://d-xxxxxxxxxx.awsapps.com/start
Users log in to this portal and select whichever AWS account has been assigned to them.
For example, if it shows
Dev
AdministratorAccess
clicking is all it takes to sign in to the Dev account.
This means there's no need to keep track of separate login URLs or credentials for each account.
What's next
With Identity Center set up, the next step is automating the development environment.
- SSO setup for the AWS CLI
- Infrastructure as Code with Terraform
- Connecting GitHub Actions with OIDC
- Running CI/CD through an IAM role
- Setting up CloudTrail and Security Hub
By making Identity Center the starting point, I'm aiming to build an AWS environment that keeps human authentication separate from CI/CD authentication — secure, and easy to operate.
Wrap-up
IAM Identity Center is, for all practical purposes, the standard authentication foundation for any environment built on AWS Organizations.
In this setup:
- Users are managed centrally in IAM Identity Center
- Permissions are managed through Permission Sets
- Permissions are granted at the group level
- Signing in to each AWS account happens through the AWS Access Portal
That's the structure I landed on.
Designing it this way makes it easy to adapt as I add developers or change permissions, while staying aligned with the security best practices AWS recommends.